Saturday, June 15, 2013

ERP Implementation Cases Reflection

Zhang Danyang
This reflection will discuss about the lessons learned from both successful and unsuccessful Enterprise Resource Planning (ERP) implementation cases. The purpose of ERP is to integrate and unify every aspect of the business of an enterprise into one single suite of software system. Many of the ERP implementation cases occurred around late 1990’s, in an attempt to tackle with Y2K problems.  After discussion about the lessons learned from these cases, the reflection will talk about the ERP implementation approaches, and a new approach from Software Engineering is proposed.

The problem. ERP implementation is not the kind of project that companies should or even could attempt to force into a precise timeline. There is no better way to have sub-components missed or have configuration completed shoddily than to force the project to complete before a specific end date (Dieringer, 2004). Taking Hershey as an example, the project was initially planned to take 4 years, but the management forced the implementation to complete in only 2.5 years. When the system went live in July 1999, Hershey experienced serious problems generating orders through the system, resulting huge lost during business peak period (Perepu, 2008).
The solution. It is more important to define and adhere to technical principles and then set business goals. After that, the company is able to construct a flexible and realistic schedule that will accomplish those business goals in accord to the principles. At the same time, management must constantly review the need for extending deadline to reduce the rate of system errors (Barton, 2001). When Tektronix implemented Order Management Account Receivable in one of departments, due to complexity of legacy systems and potential dramatic change of business model, the company carried out additional cycles of testing. Although the implementation took twice as long as originally planned, the system is rolled out free of problem (Harvard Business School, 1999).
            The problem.  Many companies wrongly regard the end-user training as afterthought and commonly the first item to be trimmed when the implementation project falls behind schedule. Consequently, it can result in disgruntle from employees and will backfire the whole project. Without user training and universal buy in, workers felt their jobs were threatened. Consequently, they resisted the change by damaging inventory (Scott, 1999).
The solution. That company places a large focus on training is another essential factor of ERP implementation. Training is the key element of ERP implementation and future usage, because without it employees who will be using the ERP and the brand new business process for day-to-day transactions will not prepare themselves to do so.  Companies should resist cutting off the training, and should understand the criticalness that employees get sufficient training early and throughout the entire project (Dieringer, 2004). Additionally, companies can involve the end-users in the testing phase of the new project to speed up the implementation process as well as training process.
Industrial best practices. Companies should investigate their own business processes and evaluate the payoffs of re-engineering that will be carried out conjointly with an ERP implementation. Companies often seize the chances of ERP rollout to re-engineer their business processes to adopt the industry’s best practices built in the ERP system.
Competitive strategy. On the other hand, if a company depends on its unique competitive advantage to differentiate itself from competitors, it would possibly damage the strength of the company by forcing the company to fit the system. The best practices in ERP systems are general based and relies on a series of assumptions about how a typical company carries out business. The best practice may vary from region to region and companies may choose its own unique strategy, therefore the legacy processes as unique competitive advantage should be left alone, as argued by Erik Fosser (Erik Fosser, 2008). Otherwise, resistance and contempt will be bred within the company.
Conclusively, ERP implementations offers companies a great opportunity to re-engineer processes but great caution should also be taken when evaluating and choosing which one of business processes to be altered and tuned in the end.
It is recommended to confine the source code customizations and changes to the ERP system itself. As evidenced by Tektronix (Harvard Business School, 1999), if Tektronix did not adhere to Plain Vanilla principle, the timeline, cost, and bugs in the system would increase along with the increase in number of modification requested.
The future maintenance and upgrading will be easier and more cost-effectively if the number of modifications is limited, as evidenced by Panasonic SAP Upgrade Project (IBM, 2008) – the limitedly customized ERP system was upgraded within only one weekend for entire Europe.
Code modification should only be carried out on occasions when it is absolutely needed (e.g. unique competitive advantage). Otherwise, the company will run into heavy costs for implementation and upgrade. The company should evaluate different ERP vendors to find out a package can best fit its business model. The company will benefit from finding a vendor’s ERP system that mirrors its business processes as closely as possible, then resolve to implement that package with no drastic modifications (Dieringer, 2004). Moreover, it is possible to send an analysis team to the vendor, ensuring that that vendor can do what the company needs.
Top management commitment. Many implementation project teams have placed much emphasis on buying in top management. Without strong commitment and sponsorship, the ERP system can only be installed rather than be implemented (Elisabeth J. Umble, 2003). Unfortunately, top management commitment is only half of the story. As evidenced by FoxMeyer, the project failed despite the strong commitment of the CEO (Scott, 1999).Only buying in top management is not enough.
Universal buy-in. Every employee as well as management needs to support the implementation process if it is expected to be successful. As Dunn said, if the Nestle’s   implementation team was to do the project over again, the team would put the primary focus on obtaining universal buy-in, and thereafter on installing the software. “If you try to do it with a system first, you will have an installation, not an implementation. And there is a big difference between installing software and implementing a solution” (Worthen, 2002). In the case of FoxMeyer, if warehouse workers supported the new system and business process changes, there would not be such morale and inventory damage issues (Dieringer, 2004).
The problem. It is not uncommon that companies want to get the “best of breed”, thus they buy different products for different business process from different vendors and hire consultants from multiple consulting firms. The risk exposed to the company here is that different products are hard to achieve synergy due to compatibility issues. For example, the failure of ERP project of Hershey is partially attribute to choosing SAP for production, Manugistics for SCM and Siebel for CRM (Perepu, 2008). Furthermore, it is even more dangerous to switch consulting firm half way through the project; simply because the company has to start over again to bring the new consultants to the same page, which is both costly and time-consuming.
The solution. As many examples indicated, the one reason behind the success is to have a single vendor and consultant firm throughout the project. Panasonic Europe has established a long-term relationship with SAP as ERP vendor and IBM as consultant to ensure a successful implementation and upgrade of the system (IBM, 2008).
Integration points. Nevertheless, it is still possible to have different systems functioning together. Nestle succeeded making SAP module work together with Manugistics module after IT team’s careful examining of integration points. The key issue here is whether the company can synthesize the interfaces of systems. Only after that, the company can obtain the benefits from the specialized advantages of different systems.
When a company senses the risk that the ERP implementation may go out of track, it should halt the project proactively and re-assess the project scope and re-structure the project team. The management should not “bet the company”. Otherwise unfavorable results like bankruptcy can take place like what happened to FoxMeyer. 
Half way of implementation, Nestle found itself essentially substitute process silos for process silo; therefore Nestle halted the entire project proactively, and then gave Dunn full responsibility after removing project co-leader. After a series of meeting with key stakeholders and business executives, the project restarted and was successfully delivered one year later eventually.
Whirlpool, a home appliances company, opted not to halt the SAP ERP project despite the fact that read flags had been raised in the testing phase. Whirlpool made the shoddily-implemented SAP system go live; therefore the company suffered delays in delivering its products to customer. The decision of continuing the project rather than halting resulted in a crippled ERP order management system, which left the home appliances stacking in warehouses with 40- to 50-day delays for sales and delivery orders (Collet, 1999)

Traditional approaches such as big-bang and phase-in approach are waterfall approach (Figure 2). Big-bang approach implements ERP modules in various departments simultaneously, while phase-in approach implements the modules separately in different phases. But both of them are waterfall model, that is, one series of tasks after another in linear sequence, process flowing steadily downwards. ERP project team should move to next step of ERP implementation only when its preceding step is completed and perfected (Royce, 1970).
Figure 1: Steps of Waterfall Approach
Software development (Software Engineering) has radically changed due to the emergence of agile development approach. ERP implementation project should also go beyond the traditional waterfall approach, benefiting from using agile implementation approach.  
Figure 2: Steps of Agile Approach

Iteration. Agile methods break the ERP implementation into small increments with multiple iterations. Iterations are short-time cycle that typically last 1 to 4 weeks. Each iteration (Figure 2) involves planning, requirement elicitation, design, implementation, unit testing, and user evaluation and acceptance testing (Beck, 1999).
Incremental change. Traditional big-bang or phase-in approach, project team is required to fully implement one ERP module in one department and then do the testing. Instead, agile approach empathizes on implementing smaller portions of the module at a time. Both end-users can learn the system and the project team can learn the business process. Such learning comes from the incremental changes where the process starts with a simple implementation of a subset of the module and iteratively enhances the evolving versions until the full module is implemented (Allenman, 2002).
Working prototype. Agile approach empathizes on working prototype as the primary measure of ERP implementation process. One iteration might not implement enough functionality to guarantee a live system, but the objective is to have a working prototype to allow the client to evaluate project.
Communication. Agile approach empathizes on the high frequency face-to-face communication between the implementation team and client. Thus it facilitates the full involvement of the client throughout the process. Working closely with the client, ERP project team can understand more about the client’s requirements and get rapid feedback in every single iteration.

There are as many lessons learned from successful ERP projects as there are from failed projects. A portion of lessons is covered in this reflection derived from these project implementation cases:
·         Flexible and realistic project timeline
·         Emphasis on end-user training
·         Balance between re-engineering the business process and modification of the ERP software
·         Strong top management commitment as well as universal buy-in
·         Choice of single vendor and single consultant
·         Pro-active halting of the project
Moreover, the agile approach is recommended for the ERP implantation project in the future, compared to big-bang approach and phased approach.
ERP implementation is not a single destination, but a journey towards smarter business operations, an evolutionary process for modern enterprises.

(1950 words)

Works Cited

Allenman, G. B. (2002). Agile Project Management Methods for ERP: How to Apply Agile Processes to Complex COTS Projects and Live to Tell About It. Extreme Programming and Agile Methods: XP/Agile Universe, Springer Verlag, 70-78.
Barton, P. (2001, Nov 25). Enterprise Resource Planning Enterprise Resource Planning. Retrieved April 14, 2013, from
Beck, K. (1999). Embracing Change with Extreme Programming. Computer , 70-77.
Collet, S. (1999). SAP: Whirlpool's rush to go live led to shipping snafus. Computerorld.
Dieringer, D. S. (2004). ERP Implementation at Nestle. Enterprise Resource Planning Systems.
Elisabeth J. Umble, R. R. (2003). Enterprise resource planning: Implementation procedures and critical success factors. European Journal of Operational Research, 241-257.
Erik Fosser, O. H. (2008). Organisations and Vanilla Software: What Do We Know About ERP Systems and Competitive Advantage? European Conference on Information Systems, Galway, Irland.
Harvard Business School. (1999). Tektronix, Inc.: Global ERP Implementation. Harvard Business Cases.
IBM. (2008, Sep 01). Panasonic Europe teams successfully with SAP and IBM. Retrieved April 14, 2013, from IBM:
Perepu, I. (2008). ERP Implementation Failure at Hershey Foods Corporation. ICFAI Center for Management Research.
Royce, D. W. (1970). Managing the Development of Large Software Systems. Concepts and Techniques, Proceedings of WESCON.
Scott, J. E. (1999). The FoxMeyer Drugs' Bankruptcy: Was it a Failure of ERP? Americas Conference on Information Systems AMCIS, Milwaukee, USA, 223-225.
Worthen, B. (2002). Nestle's ERP Odyssey. CIO.

No comments:

Post a Comment