Monthly Archives - March 2020

reasons for ERP implementation failure

7 reasons for ERP implementation failure

ERP consultants shared their analysis and takeaways from such spectacular ERP failures as National Grid, Revlon and Waste Management and gave advice on avoiding the same pitfalls.

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.

“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.

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, Covered 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 Covered 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 canceled.

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.

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.

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 proof of concept on critical functionality … can reduce significant risk,” Lalwani said.

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.

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.

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.

Source: George Lawton


Data V Tech is proud to be one of the leading ERP vendors in the Asia Pacific. We have implemented Epicor ERP for many businesses in Vietnam and China. For direct consultation, please feel free to contact us.

how to manage ERP customizations

How to Manage ERP Customization

Following up Elizabeth Quirk’s comments on how to manage ERP customization (see below), Data V Tech would like to add some information to complete the picture of this issue.

  • It is true that some ERP software requires knowledge of coding in order to customize the system. Some others, however, have been well-prepared with the drag-drop options. Epicor ERP is one explicit example as it allows end-users to easily learn and customize the system on their own.
  • How to manage ERP customization is usually the question of ERP vendors. That means your contract with the ERP providers should include this service. As a result, you do not need to worry about all technical problems or unforeseeable extra costs.

Enterprise Resource Planning system (ERP) customizations have a much broader purview, and typically involve extensive software coding modifications to better fit the needs of the business. They’re far more labor-intensive, and the margin for error is virtually nonexistent. Once you start making changes to the system, it’s a slippery slope towards more. However, when managed and done correctly, customized ERP systems can benefit the organization as a whole. In this article, we’ll explore the advantages and disadvantages of customizing an ERP solution, and how to manage one.

How to Manage ERP Customization

A study by Panorama Consulting showed that 90% of ERP systems have at least minor customizations, while 36% have customizations that involve modifying over 50% of the code. Only 2% are completely customized or homegrown. However, the landscape is clearly changing at an accelerated pace.

Consider the Pros and Cons

As you continue to make changes to the ERP system, it becomes much more complex and costly. Plus, upgrades can become the worst nightmare for businesses that have customized ERP. Since the code needs to be rewritten to support any modifications, upgrades become more and more difficult.

Panorama Consulting found that over-customization a key reason why so many organizations decide to replace their existing ERP systems – not because there is something wrong with the system really, but because it has been customized beyond the point of recognition. Customization requires design, development, deployment, and testing work, which is all very time consuming and sometimes very risky. Over-customization is one of the leading attributes to ERP failures, so it’s only fair that businesses would lean towards out-of-the-box ERP systems to avoid such risks.

However, the bright side of all this is that you will have an entire ERP system designed specifically to meet the needs of your business. Customizing allows you to modify and add your organization’s areas of competitive advantage. While most business leaders want to manage their implementations by simply using basic configuration, setup and personalization of the ERP software, a majority end up making fundamental changes to the source code.

Document and Identify Best Practices

It’s a good practice to document any existing and current industry best practices you cannot give up or change. Make sure that the ERP software vendors you are interested in providing explanations of how their specific solutions would address each business requirement.

Identifying the customizations that address business needs and provide demonstrated value is also important. Once an ERP customization is complete, ongoing source code management and documentation of customization-related activities are necessary to preserve the integrity of your ERP system.

Remove Unnecessary Customizations

The more your business grows, so does its needs and objectives. What was once a necessary business process may no longer be relevant to where you’re at now. Apply this to your ERP system. If an existing ERP customization no longer increases value, what’s the point of keeping it? According to Zach Hale, Marketing Copywriter for Gartner, after identifying dispensable customization, you can retire it in one of three ways:

  • Removing it entirely. The more isolated a customization, the less likely its removal will adversely impact the rest of the system. Only remove customization if you’re certain the rest of the ERP can subsist without it.
  • Disabling and hiding the functionality in the system. When customization is distributed among multiple system components, its removal will likely affect everything it touches (and not in a good way). In such a scenario, it’s better to simply disable or hide the customization and leave the underlying code as intact as possible.
  • Deciding not to upgrade your system or rebuild the customization in the new version. This should be your last resort, a scenario to be considered only when disabling or removing a customization would effectively kill your system. You’ll miss out on security updates and functionality enhancements, but hey, at least you’ll still have an ERP.

Source: Elizabeth Quirk


Data V Tech is Epicor’s Authorized Partner with over 20 years of experience in the Asia Pacific. We provide well-timed implementation with full support for software localization. As a one-stop-shop, we offer complete solutions for manufacturing, trading, and distribution businesses, from mobile applications to e-commerce and direct machine data integrations to Epicor Kinetic (ERP) software.

Epicor Kinetic (ERP) is accessible on the cloud, hosted servers, and on-premises. It is flexible and personalizable to individual use, company practices, and multiple industries.

Contact us