Wednesday 21 November 2007

Geneva Case Study

Introduction

Geneva Pharmaceuticals are one of the world's largest generic drug manufacturers with revenues in excess of $300 million in 1998. Until 1996 Geneva's information systems were incompatible across business areas; for example, the accounts department could not be made available to manufacturing without re-keying the data manually. This was a major problem for Geneva because it meant that time was being wasted reproducing data and there was a high incidence of 'dirty data' - factors which lead to inefficiency and inevitably the loss of profits. Management at Geneva realised that such problems existed in their company which led to their belief that they needed a "common, integrated company-wide solution to improve data and reduce costs". Their solution? Deploy SAP's R/3 system.

Enterprise Resource Planning (ERP) systems integrate (or attempt to integrate) all data and processes of an organisation into a unified system (www.wikipedia.org). Due to the desire within Geneva for applications to be compatible across business units it is possible to see the attraction of SAP R/3.


Phase One

The main aim of this phase was to reduce the cost of operations. The SAP R/3 system would require data to be entered only once - thus saving time and money, with efficiency greatly increased.

However, despite such suitable objectives many key problems occurred. There was little communication or co-ordination amongst the team implementing the system which is clearly a recipe for disaster and it was actually necessary to bring in a new CIO in order to provide the project with better leadership. As witnessed in the London Stock Exchange it is very difficult to implement changes if you fail to consider organisational feasibility and fail to communicate effectively (Taurus v Crest) and it is likely that this contributed to these problems.

Another major decision and, ultimately, a problem at this stage is the fact that Accelerated SAP (ASAP) was chosen due to its promise of a short implementation cycle of only 6 months. This appears to be a valid decision because any company would want their systems to be running as quickly as possible in order to reap the maximum benefits however, 4 months down the line very little progress had been made; Geneva was therefore well behind schedule and this could have knock-on effects for future stages. The following quote appears to embody the thought process at Geneva: "some people want to do everything in one or two months and underestimate the time it takes for proper development and employee comprehension"(McCabe, R., 2007). By considering such an attitude it is easy to see why problems occurred because by trying to do things too quickly one can fail to notice areas which are actually struggling.

Finally, at this stage it emerged that the new system provided Geneva with problems that had not existed within the original system. This was a major blow because the system was designed to be better and more efficient than its predecessor, not worse and after so much time and money had been spent on the system it is reasonable to expect it to carry out its function properly.


Phase Two

A key point to note at this phase is the fact that it was far more challenging than the previous phase due to the complex nature that Geneva used in dealing with customer orders, rebates and chargebacks. Due to this, a decision was made to change those managing the project as the first phase had suffered from so many set backs. Whitman-Hart was replaced by Arthur Andersen and Oliver White, consulting firms, due to Arthur Andersen’s knowledge in the technical configuration aspects of SAP implementation and Oliver Whites’ reputation.
On top of this, Anna Bourgeois was assigned the overall responsibility for this phase due to her extensive knowledge in this field.

Another point that was raised at this stage was the conceptual design of the system in which thirteen areas for improvement were highlighted with four emerging repeatedly. This stage was carried out by the key users who were most knowledgeable with the existing processes with help from Oliver White. The use of expertise here was important to ensure that the best design possible was established. To further this point, prototypes were used to test these emerging areas of conceptual design against any emerging problems.

Also, in this phase a lot of attention was paid to the management of change in relation to the staff and training. This process was taken extremely seriously with posters, surveys and even a telephone line implemented for staff to call in relation to their worries. Further, three full weeks were devoted to training. This point of the project was undertaken meticulously possibly, with a little too much emphasis.


Phase Three

A key decision of this phase was the fact that they reinstated the project manager from phase one. This could be seen as a problem as in phase one there were problems relating to communication, co-ordination and time scale.

A key benefit of ERP systems highlighted in this phase is they can save a lot of time. It was estimated that using the R/3 model for sales and operational planning (SOP) would cut this process from 20 to 10 days - an important selling point of these systems. Further, at the time of this case SAP brought out a new module - Advanced Purchase Optimiser which combined with SOP would answer the unique business needs of the company. This will then go on to help meet Geneva's targeted business improvement of having their orders 'ready to promise' which will help improve its customer service levels.


Conclusion

In conclusion, there are a number of things we can learn from this ERP implementation. Firstly, it is necessary to have the correct people on board from the start as Geneva had to implement personnel changes during the project and ERP is as much about people as it is about systems. It is also necessary to have a realistic view of the time frame required as phase 1 ran over schedule which had knock-on effects for the other stages and staff are likely to be demotivated if they are continually told different finishing dates. However, we can also learn from Geneva's successes such as spending a large amount of time and effort making staff receptive to change and training staff to ensure that they are confident in using the system, as one of the main reasons for failure is that staff often feel scared of the technology and fail to make the best use of it in their day-to-day work.


REFERENCES


McCabe, R., How to recover from a failed ERP implementation, http://www.microsoft.com/canada/midsizebusiness/businessvalue/local/failederp.mspx, accessed 14 November 2007

SAP R/3 implementation at Geneva Pharmaceuticals, Case Study

Taurus v Crest, Case Study

This post was created in collaberation with Lynsey Smith

Tuesday 20 November 2007

How will Offshoring Affect UK Accountants?

Offshoring happens when a company relocates internal business processes to a foreign country. The company either manages these processes internally in the new country or contracts an offshoring service provider (www.accountancy.com). The process of globalisation and the increased use of IT have led to offshoring affecting the services industries (Giddens, 2006). In particular, offshoring has the potential to greatly affect the work done by UK accountants.

Giddens, (2006), stated that any service job can be offshored that displays four characteristics: it involves the heavy use of IT; its output is IT transmittable; it compromises tasks that can be codified and it needs little or no face-to-face interaction. Many accounting functions consist of the above characteristics in which can therefore be offshored including: purchasing and sales transaction processing; financial management and project accounting; payroll processing and expenses (www.personneltoday.com) and a number of tax services. An important example of this in relation to UK accountants is the fact that the BBC has outsourced its finance and accounting services saving £200 million over the lifetime of their ten year contract with Indian based Xansa (www.personneltoday.com). As this is a highly publicised company in the UK this could serve as publicity in favour of offshoring to the detriment of UK based accountants.

Further, in a report provided by PWC, it is estimated that the US financial services sector is set to double offshoring by 2008 with approximately 360,000 returns prepared by Indian vendors, garnering $40 million in revenues. The prime reasons stated for offshoring were the shortage in accountants, the gruelling tax season and the fact that there is a saving of 40 – 60% (www.valuenotes.biz). These are all valid reasons in business that favour offshoring and with the US a similar market to the UK, not a lot may be able to be done to prevent tax services being offshored, especially due to the fact that deadlines are often struggled to be met due to the end of year practice associated with tax.

Giddens (2006), states that the consequences of offshoring will depend upon the actual task that is being carried out, not the overall competitiveness of the firm or the industry in which they work or their level of education. The point that tax services may be largely offshored may be counteracted by the fact that auditing services may not be susceptible to this. This is due to the fact that this service line relies on a lot of face-to-face contact between the auditor and the customer and the auditor is often required to visit the premises of the business which is being audited.

One of the ‘pull-factors’ of offshoring is the potential monetary saving. However, if this process is used extensively it is important to consider that as a nation matures economically that the arbitrage between costs in these locations and the US/ UK will tighten. At some point, the differences could narrow to the point where no arbitrage exists at all (www.accountancy.com). While it is unlikely that the gap will close altogether it should pointed out that at a further point in time, the gap may be so small to benefit from the cost savings occurring at present. If this does turn out to be the case, there could be a potential shortage of accountancy based skills in the UK to meet the reinstated demand for services.

Continuing on from this point, the education system in the UK for potential accountants could be dramatically altered to accommodate only the services that will provide employment to graduates therefore; there could be a huge gap in the knowledge of future accountants – if they will even receive this title.

However, there are some constraints that may prevent the offshoring problem. In several countries, there are legal constraints which prevent firms from sending work outside the geographic or national boundary (infosysblog.com). Also, if the UK considers that the potential job losses could be too high, it may be possible to pass a law to make offshoring illegal (www.accountancy.com). However, I find this highly unlikely due to Gordon Brown’s favour of globalisation, Giddens (2006). UK jobs could also be protected through the use of licences to undertake a specific job, as in the US.

Similarly, there may be some reasons in which not to offshore. For example, compared to the UK, the quality of undergraduate education in India is poor and the teaching method and two-tier system have been largely criticised (Giridharadis, 2006). As a result of this, UK businesses may want to weigh up the opportunity to reduce costs with the quality of work that may be produced.

Finally, there are some survival skills that UK accountants can use to their advantage to secure their jobs. One of the most important ones may be loyalty to a company with a proven track record. UK companies are said to look favourably upon this. Also, marketing and renewal of business processes can help businesses or specific jobs being offshored (blog.fastcompany.com). However, with cost reductions a prime reason for offshoring these points may be overlooked.


References

Accountancy Q&A, November 2005, Accessed from:
www.accountancy.com.pk/articles.asp?id=161

Berry, M, BBC to Send Finance and Accounting Services Offshore to India with Xansa, Personnel Today, Assessed From: www.personneltoday.com/articles/2006/10/23/37882/bbc-to-offshore-to-india-with.html

Giddens, A, The New Globalisation – Electronic Offshoring Marks a Distinct and Challenging Phase in the Evolution of Global Economic Independence, Guardian Unlimited, November 2006

Giridharadis, A, A College Education Without Job Prospects, The New York Times – World Business, November 2006

http://blog.fastcompany.com/archives/2003/12/17/surviving_the_offshoring_trend.html

http://infosysblog.com/managing-offshore-it/2006/12/when_a_project_manager_should.html

http://www.valuenotes.biz/bpo/tax.asp

Monday 5 November 2007

Why Did TAURUS Fail and CREST Succeed?

In 1989 the London Stock Exchange (LSE) put forward a proposal for a computerised system to ensure that share certificates and cash changed hands between the interested parties after the trading transaction, implicit in this was the dematerialisation of stock certificates. It was a big project with hundreds of staff contracted in and lots of external pressures from various different stakeholders. The project was scrapped in 1993 at a cost of £75 million to the LSE. However, the LSE still needed a computerised system and took up the project of CREST (Head, 2001). This project learnt from TAURUS’ failures and went ‘live’ in July 1996. There are many differences between the TAURUS and CREST projects that led to the eventual downfall of TAURUS and the success of CREST.

One of these problems was that TAURUS wanted to be “all things to men” and with the pressures from the companies that were members of the LSE, they included 21 Corporate Actions or Events to deal with the different business approaches (Head, 2001). Due to the amount of modification that had to be done to the software, this is one of the reasons the system failed. CREST learned from this and included only 2 business functions. However, these business functions made up 85-90% of the business transactions. It was the Pareto effect that was used here: the two business functions were only 10-15% of the total 21 functions set out by TAURUS however, adding the extra functions the system became overloaded (Head, 2001).

Another problem that TAURUS suffered from was the software package that it chose. It needed heavy modification due to the 21 different business transactions. This software had not previously been tested and resulted in a downfall. This was much the same as the problems that FoxMeyer found when installing an ERP system. It used an untried system that it was ill-equipped to install and failed disastrously (Buss, 1997). CREST did not replicate this problem and opted for a tried and tested method in which the Bank of England had experience in (Head, 2001). By drafting in the IT manager from the Bank of England the CREST project had experience on its side.

A further point that separates the failure of TAURUS and the success of CREST was the project structure. TAURUS was marred by ad-hocracy, fragmentation and mismanagement (Currie, 1997). This was due to the hundreds of contract staff it hired in, the consultations with the member firms, the legal aspects drafted by the government and the pressures of a project team repeatedly crossing the Atlantic (Head, 2001). CREST on the other hand was seen to be highly structured and controlled (Currie, 1997). It had a 20 member strong design team with four or five managers to constantly overlook the project. This highlights that although both the projects were high scale and using sophisticated technology, the management and co-ordination of the project is a key to its success.

Additionally, the budget and time constraints of the projects were seen to be a differentiator to their success. Goulielmos (2003) states that of the four concepts of failure in Information Systems is process failure where the project over runs its budget or time constrictions. TAURUS did both incurring increasing media attention and scrutiny, which led to an increase in pressure on the project team (Head, 2001). CREST again, learnt from this mistake by being highly structured and controlled. It was within its original budget and went ‘live’ at its target date. The CREST team also learnt to establish press relations and brief them about the progress of the project (Head, 2001). Therefore, they did suffer from general scrutiny about the project but, had a reduced amount of pressure compared to the previous project, TAURUS.

In sum, the TAURUS project implemented by the LSE suffered many downfalls and eventually was scrapped however, the success of CREST may be largely down to learning from previous mistakes. As highlighted above, from the downfalls of TAURUS, CREST has implemented a solution or more basically avoided these problems.


References

Buss, D, Nightmare, Context Magazine, 1997

Currie, W, Computerising the Stock Exchange: a Comparison of Two Information Systems, 1997

Goulielmos, M, Outlining Organisational Failure in Information Systems Development, Disaster Prevention and Management, 2003

Head, C, TAURUS and CREST, Failure and Success in Technology Project Management, 2001