There are a lot of ways for ERP systems to fail. For one, many businesses rush into rolling out new functions without careful consideration of details -- or knowing beforehand the common reasons for ERP implementation failure.
"It takes time, dedicated training and adequate management for ERP to flourish as a proficient tool within your business," said Jenny Chua, business development manager at The World Management, an ERP consultancy in Singapore.
John Belden, project execution advisory practice leader at Boston-based UpperEdge, an IT negotiations consultancy, commonly sees three key characteristics of these projects that often contribute to ERP implementation failure.
First, ERP implementations are often two to 10 times bigger than previous projects. Second, they are transformational, which means there are winners and losers in the organization as a result of the software implementation. Third, they are generational, which means that an organization may not have done anything comparable in 10 to 15 years.
This article is part of
"A program will have problems when enterprises don't recognize these issues and try and mitigate these risks," Belden said.
Examining well-publicized cases reveals a handful of more specific reasons for ERP implementation failure.
Here are seven major reasons why ERP implementations fail and how to avoid them.
Taking on too much
Bigger projects tend to put an organization in the position where it is not prepared for the volume and magnitude of decisions required. As a result, overwhelmed teams end up piling on one bad decision after another.
Belden said a classic example was the 2012 attempt by the state online healthcare marketplace, Cover Oregon, to simultaneously implement Obamacare and replace all of its supporting transaction processing systems. It ultimately spent over $300 million and was unable to process a single insurance application through the exchange.
"They created a scenario where the project got so enormous, they could not meet the due dates," Belden said, or make the decisions that were required. Problems were exacerbated by the need to meet the hard deadline imposed by Obamacare. Belden said he believes the project would have worked out if Cover Oregon had kept the ERP project smaller and restricted it to what would have been required for Obamacare.
The big lesson: Limit the scope of the project to the appropriate time frame.
Generational problems can occur when no one on the program management team understands where the problems are.
"They may have prior experience, but it was 10 to 15 years ago and the people who learned the lessons are somewhere else in the organization or have moved on," Belden said.
A good example is ICL's failed ERP implementation in 2014. The project cost ballooned from $120 million to more than $500 million. Ultimately the CEO resigned, and the entire SAP ERP implementation was cancelled.
The CEO assigned the project to a relatively new person in the CFO's office, according to Belden. This project lead was primarily focused on making sure the financials were being incorporated into the ERP rather than taking into consideration the needs of the manufacturing and supply chain sides of the business. Employees in the first factory revolted after they had the new system imposed upon them.
"They got more focused on financial integrity rather than operational integrity," Belden said.
The lesson: Focus on all users and not just one part of the business.
Lack of disaster testing
National Grid's ERP implementation was essentially blown away by Hurricane Sandy when the utility attempted to consolidate all of its U.S. operations on a common SAP system in 2012. Ultimately, the project took two years to clean up, at a cost of $585 million.
The parent company had successfully worked with the Wipro consulting firm to implement a similar ERP consolidation in Europe. But the ERP project team struggled with major differences in the regulatory environments in the U.S. Wipro suggested the SAP ERP was ready to go live based on test results, but the actual system did not hold up under the increased workload and emergency business processes required to repair the electric grid after the hurricane, which involved special procedures for bringing in workers and materials from other utilities for the extensive repairs.
Belden said the implementation team had focused on "happy path" testing, which involved testing functions under ideal circumstances, but there had been insufficient testing of the system in emergency scenarios. National Grid decided to go live as the hurricane was making its way up the coast.
The key takeaway: It is vital to assess all of the information required to truly determine readiness before going live with a large ERP implementation.
Not verifying claims
Waste Management ran into some major snags when it attempted a massive SAP installation in 2005. After numerous delays and problems, the company ended up in a $500 million lawsuit against SAP that was eventually settled out of court.
SAP had suggested Waste Management could achieve $106 to $220 million in annual benefits from a consolidated ERP system that could be implemented in 18 months.
Deepak Lalwani, principal and management consultant at Deepak Lalwani & Associates, an IT consultancy, said one big problem was Waste Management's failure to verify SAP's claims before making an executive decision. The company quickly discovered there were significant gaps between what was promised and what was delivered in the software.
The takeaway: Verify vendor claims with internal business and technical teams. "Performing a proof of concept on critical functionality … can reduce significant risk," Lalwani said.
Setting unrealistic goals
Nike thought it could Just Do It when it embarked on a $400 million upgrade of its ERP system in 2000. But the new system resulted in $100 million in lost sales and a 20% drop in stock price when it couldn't fulfill orders for Air Jordan footwear.
Alex Sharpe, associate principal and management consultant at Deepak Lalwani & Associates said, "Nike was overly optimistic in their goals, and they failed to verify business process met operational needs before deploying the system."
The lesson: It's important to set realistic goals, especially with regard to ERP functionality and implementation schedules. Sharpe also recommends defining business and operational needs early on and keeping them in mind when developing systems.
"Ensure you take enough time to test the system for any kinks that need to be ironed out before putting your system into production," he said.
Hiring the wrong people for the job
MillerCoors embarked on an ambitious plan to consolidate all of its financials on a single ERP system to reduce costs and improve operational efficiency. In 2014, it hired HCL Technologies to implement the project, which was stalled by numerous defects. MillerCoors ended up suing HCL for $100 million, which was finally resolved in 2018.
Lalwani said the problem arose because the planning and architectural phases were not given adequate consideration. In addition, many critical defects and other additional problems were identified, but not fixed.
HCL's core competency was generally regarded as implementation, not planning and architecture.
The lesson: Be sure to have the right expertise for the particular project. "IT is often the toughest and the most expensive part of integrating multiple companies, and they rushed through the planning and architecture phase only to get hurt by it later," Lalwani said.
Not analyzing operational impact
Revlon attempted to integrate all of its ERP processes across business units after a merger with Elizabeth Arden in 2016. The new system failed spectacularly after it went live in 2018, resulting in a loss of $64 million in sales, a 6.4% loss in stock price and an investor lawsuit.
A key issue was that Revlon had attempted to consolidate Microsoft and Oracle systems on a new SAP implementation but lacked hands-on experience with SAP. It also decided to go live without making sure the ERP business processes would work as intended.
"Rolling out a system that does not meet operational needs and requirements often leads to adverse business impacts," Lalwani said.
The final lesson: Mind both the operational and business sides of the ERP equation.