In this final installment on these lessons learned and mini case studies, we will look at a few older SAP project failures. Even in these older SAP project failures, many of the same problems continue to repeat themselves.
I would like to point out once again that in the major SAP project failures the software application itself was not at the root of the failure. The project failures I focused on are the ones where there is plenty of published literature to evaluate. Obviously that does not mean that there aren’t projects with failures where the software itself was responsible, only that the available literature where you can do a fair analysis of the projects do not point to the software itself as the cause.
One of the interesting trends for several of the project failures was the SAP project was blamed for poor business results. For example,
- Here, you can see the Hewlett-Packard example listed below (2004).
- In the first post of the series, we discussed the Shane Company (2008) (SAP ERP Project Failure Lessons Learned and Mini Case Studies 1).
- In the second post, we covered Levi Strauss & Company (2008) (SAP ERP Project Failure Lessons Learned and Mini Case Studies 2).
SAP ERP Implementation Failure Overviews – part 3
Some reasons these older SAP ERP projects fail (and many of the modern ones) include the following:
- insufficient or improper training,
- lack of change management,
- insufficient testing,
- poor scoping,
- bad go-live timing,
- unreasonable timelines,
- bad project management,
- lack of senior management participation,
- multiple simultaneous enterprise application projects,
- too much or too complex custom development efforts (interfaces),
- and inexperienced or incompetent consultants.
Hewlett-Packard Company – SAP ERP Project Failure? (2004)
- Even though this was attributed to the SAP implementation, we need to consider other aspects. At the time of this implementation, HP was a fairly mature SAP shop. They had already done four prior rollouts of the application, and this was number five. The “hiccup” only prevented one week’s shipments. As an SAP consultant since 1994, I can all but guarantee you that this “hiccup” was at the beginning of a month, and probably the beginning of a quarter– not at the end. As a result, it could not have affected the financials to that extent.
- CIO and Executive Vice President of Global Operations Gilles Bouchard didn’t think that… data modeling problems between the legacy and SAP systems was the source of the $160 million impact. He blamed HP’s inability to keep pace with orders in the supply chain once the problems were discovered. [FN1, pg. 26]
- Although HP’s Industry Standard Servers (ISS) business woes were blamed on SAP because of a one-week supply chain hiccup, the actions by HP hint at a different reason. If the SAP software were to blame, then the division’s sales executives would not have been fired:
HP “announced that three major sales executives, including former server group head Peter Blackmore, had been fired in a management shake-up following the disappointing quarter in the company’s server division.” [FN2]
- I do not believe this was an SAP software failure, regardless of how it was reported.
Lessons Learned: This “hiccup” was most likely a result of insufficient testing. Otherwise, this appears to be a case of blaming the enterprise software implementation for company or marketplace-related issues.
Hershey Food Corporation – SAP ERP project failure overview (1999)
Hershey foods went live with their SAP implementation just before Halloween in 1999. For the candy company, this was the beginning of their peak season. The go-live created a major business disruption at the worst time from a revenue and operations standpoint.
- Insufficient training and user preparation
- Users were not prepared to do their jobs, to manage day-to-day operations, or to clean up and correct data. Training and change management needed more emphasis.
- Unrealistic implementation timeline
- The original timeline for the entire project was four years; that timeline was cut down to 2.5 years. Scope management, project planning, and project scheduling (including task and resource leveling) are critical for success.
- Improper go-live schedule
- They went live at peak sales season and did not allow enough time to “shake out” data and process issues. Formal project plan and schedule; the integrator bears this responsibility unless they notified the company of the risks and the company insisted on going live.
- Additional large enterprise applications such as Siebel CRM and Manugistics went live at the same time.
- The business has since worked through and resolved the implementation issues and SAP is running smoothly.
Lessons Learned: Careful timing and planning of the project are important considerations, as well as sufficient time and resources for training, change management, and user involvement. Major enterprise applications (ERP, CRM, Logistics, etc.) should be implemented one at a time, and then at least modestly stabilized before undertaking additional enterprise applications. Attempt to schedule go-lives so that they coincide with the end of a busy season and a potential “lull” in business. This way, you have some time to work through stabilization issues before busy seasons start.
Whirlpool Corporation – SAP ERP project failure overview (1999)
Just before a Labor Day go live in 1999, several warning signs of serious problems appeared. Interfaces and batch jobs that fed external systems indicated serious performance problems, but Whirlpool management and their SAP implementation vendor Deloitte decided to go live anyway. They made a decision to go with the known problems and the problems would be resolved within roughly a week after going live. However, the interface problems created far more disruption to the external shipping and distribution systems than anticipated. Shipments were delayed six to eight weeks, causing significant lost business because many customers cancelled orders and went elsewhere.
Lessons Learned: Red flags with enterprise applications should be carefully evaluated for a “go” or “no go” decision as you approach going live. Testing of interfaces cannot be ignored, and serious performance problems or known interface problems should not be overlooked.
Fox Meyer Drugs – SAP ERP project failure overview (1995)
- Management failure
- SAP was being used to automate and consolidate warehouse operations, and layoffs were known to be coming. Labor sabotaged the efforts.
- Warehouse consolidation was occurring just as the company captured a major new contract increasing the transaction and processing volume.
- An additional large enterprise warehouse management system was implemented during the SAP implementation.
- This is scope management and project planning/scheduling.
- Multiple enterprise systems create significant project risks.
- Insufficient training and user preparation
- Users were not prepared to do their jobs, to manage day to day operations, or to clean up and correct data. They needed more emphasis on training and change management.
- The consulting company provided “trainees” to do the SAP implementation, which turned out to be a disaster.
- Project scope and cost were mismanaged because the consulting company drove the entire project.
- They also dealt with poor project planning and coordination.
Lessons Learned: Change management, training, and employee acceptance are critical. Avoid multiple enterprise-wide software projects at the same time. Ensure that the SAP vendor partner doing the implementation does not staff the project with inexperienced, ineffective, or less-than-optimal consultants.
====================
[FN1] Bhagwani, A. (2009). Critical Success Factors In Implementing SAP ERP Software, University of Kansas Graduate School. https://www.iitrun.com/literature/2009-Bhagwani-SAP-Project-Success.pdf
[FN2] SAP implementation contributed to HP shortfall. Computerworld, August 12, 2004. http://www.computerworld.com/s/article/95223/SAP_implementation_contributed_to_HP_shortfall
