Managing ERP Projects

In April 2006 Emirates Bank decided to revamp parts of its core banking system. After 12 months of planning, managers kicked off the project. They had two main objectives: to avoid mission creep and to go live as soon as possible. During the summer of 2007, however, the bank announced a merger with the National Bank of Dubai, forming Emirates NBD. This immediately made the already-complex project much more daunting: The system now needed to work for both banks—and it had to be ready in 18 months. In addition, it was to be rolled out in a “big bang”: All the components—branch computers, ATMs, online banking, and call centers—would be switched to the new system simultaneously. The potential for going way over budget was all too real. But by the time the project was completed, in November 2009, the schedule had slipped by only 7%, and costs had exceeded the initial estimate by only 18%—even though the merger had doubled the project’s size. In a field where massive overruns are common, that’s a spectacular achievement.

• 1 Stuck to the schedule, despite the merger
• 2 Resisted changes to the project’s scope
• 3 Broke the project into discrete modules
• 4 Assembled the right team, including IT experts from both companies, outside experts, and vendors
• 5 Prevented turnover among team members
• 6 Framed the initiative as a business endeavor, not a technical one
• 7 Focused on a single target, “readiness to go live,” measuring every activity against it

Black Swans

Out of control ERP projects that go over budget, time or fail

• Hershey's SAP Project. ERP system did not adequately plan for Halloween
• Levi Strauss' $5m project lead to charge of $192m because they could not take orders
• Kmarts $1.4bn IT project led tp as system so highly customized it could not be maintained. A further $200m revamp of its supply chain led to its filing for bankruptcy

Rolls Royce's Implementation of SAP

Such IT-driven initiatives re- quire change of the organisation’s socio-economic system, which is intertwined with technology, task, people, structure, and culture. Thus organisational resistance to change is identified as a critical success factor for ERP implementation ( Hong and Kim, 2002 )

Many companies that have installed ERP have claimed to be more nimble within the marketplace than their competitors with hard-to-change custom made systems ( Latamore, 1999 ). ERP systems offer companies the following three major benefits:

Business process automation.

Timely access to management information.

Improvement in the supply chain via the use of E-communication and E-commerce

A vital task when implementing an ERP System is to understand the difference between functions and modules. Functions are defined as actual physical tasks that are performed within a company. Whilst modules can be considered as pieces of software that help to provide the functions,

ERP sys- tems run into difficulty because the organisation is not ready for integration and the various depart- ments within it have their own agendas and objectives that conflict with each other ( Langen- walter, 2000 )

ERP implementations

involve, in truth, broad organisational transfor- mation processes, with significant implications to the organisation’s management model, organisa- tion structure, management style and culture, and particularly

One original motive for buying an ERP system was to automate business processes, but the modern view has shifted to the quick access of up-to-date and timely management information The majority of difficulties experienced by ERP implementations have been the costly development of additional software to help ‘bridge’ or retrieve information from legacy systems.

SAP provides some of its customers with acceler- ated SAP (ASAP). ASAP suggests the adoption of a ‘big bang’ implementation. This programme opts for a quick implementation that is specifically designed for small and medium sized companies. ‘Big bang’ implementations offer lower costs and generally use only a few of the software’s inter- faces, however the risks are greatly increased, as less time is spent on development and assessing business needs

SAP R/3 applications are a range of software modules. They can be used either alone or combined to form business solutions. SAP state that their R/3 applications offer comprehensive functionality for all standard business needs within an enterprise. SAP R/3 uses a programming language called advanced business application programming (ABAP)

Rolls-Royce used over 1500 systems before the ERP project was started, many of which were developed internally by Rolls-Royce over the last two decades. These legacy systems were expensive to operate and difficult to maintain and develop. They did not provide accurate, consistent and accessible data that was required for good and timely decision-making and performance assess- ment (e.g. delivery performance, quality metrics).

SAP R/3 requires a fairly rigid business struc- ture for it in order to work successfully. The participants of cross-functional workshops soon understood that their working practices must be adjusted in order to fit SAP, ultimately changing the way Rolls-Royce does business

The main technical problems that Rolls-Royce has encountered have been with the accuracy of data. The new system requires the retrieval of old data from the legacy systems that has to be normalised, screened and stored in a sensible data format within the new systems data repository

Rolls-Royce decided to adopt and utilise the SAP solution offered for the aerospace and defence industry

5.4.4. Phase 1 (strategy and direction) The first phase of the project was a short intensive study to set the scope of the project and provide an outline plan and costing. A steering committee was formed to administer the financial guidance of the project and a ‘ERP Core Team’ was formed to control and oversee the actual implementation process.

5.4.7. Phase three (implementation) This phase was too large to implement in one go, and thus was divided into two ‘waves’. Both waves were concerned with the physical imple- mentation of the system and its architecture. The waves were also concerned with changing working practices within the company

5.4.5. Phase 2 During the second phase a detailed plan was created and a prototype system was installed. An

Preliminary design review—developing a design and implementation strategy, defining the scope of the project, and developing the business process model.

High level design review—analyse the enterprise model, and develop ‘Vanilla’ prototype.

Critical design review—detailed design and customisation of the prototype.

Implementation realisation—integration test- ing.

Technical/operation review—user acceptance testing.

Post implementation review—system deploy- ment, systems conversion, user training before the ‘Go Live’.

The possible failure or inability to align goals through conflicting directions within the orga- nisation.

The non-delivery or non-availability of reliable IT hardware and infrastructure both before and during implementation.

The possible failure of providing inadequate and ongoing support after implementation, from both Rolls-Royce and EDS.

The resistance of change to new process methods by management and supervision.

Management and supervision may treat the project as merely an IT implementation, rather than change in process methods.

Inadequately educating the workforce to oper- ate the new system properly.

Possible failure to cut over to the new system through an inability to load data.

Possible failure to cut over to the new system through the inappropriate systems testing of volume, stress and data conversion.

Possible failure to give ERP adequate priority due to the number of existing and ongoing business improvements.

Maintenance difficulties may occur on bridged legacy systems.

The project may impact on company interim and end of year accounts.

The PDM project may not be sufficiently positioned in time with the ERP project.

Possible changes to kitting demand during ‘go live’ may stretch the new system and those operating it on a learning curve beyond capacity.

The decision to implement Wave 1 separately from Suite 3 may fail to integrate the new systems.

Airline Business After-sales may not be able to analyse and manipulate inventory investment in stock target groups (MERLIN functionality which helps to control forecasting for Airline Spares stock targets will be removed in Wave 1)

The following list contains just some of the problems encountered:

Matching the process to the software config- uration.

Training people to accept change, and getting them to do business in a totally new way.

Teaching employees to use modern IT equip- ment.

Equipment not delivered on time, or delays in technical equipment installation.

Data clean up has been particularly time consuming as many legacy systems have been involved.

Training the behaviour of SAP users such as MRP Controllers and Capacity Owners

Many activities have taken place, which have been vital to the overall success of the project, such as:

Bridging the legacy systems and cleaning up suspect data has given the company more trust in its management of information.

Training senior management, particularly the executive group, who are responsible for the overall direction of the company and are not technically orientated.

Managing effective relationships and leading teams in both technical and non-computer based environments.

Manufacture simulation exercises.

Transactional training.

Shop floor communication with line workers was an exercise that occurred during the implementation of suite 3. This required line workers to attend workshops to learn new PC skills in order to book work.