I am sure if you are in anyway connected to the ERP world this will sound like a cliché- Initially many years ago (almost 20 now) when I started consulting in ERP this was not the standard statement but as more and more case studies across the globe are written on ERP success and failures- a general consensus started emerging that Technology is not the only reason for ERP Programs failure, there is a bigger cause. But because enterprise systems like ERP applications (SAP, Oracle, MS-Dynamics, Salesforce etc.) impact a lot of key stakeholders of the company, this confession/admission that Technology was the cause is rarely made in the boardroom as it can mean few people neck will be on the line if this is openly admitted. According to the Gartner estimates around 70% of the ERP Programs across the globe fail or does not meet the required outcome –( https://www.gartner.com/en/information-technology/topics/enterprise-resource-planning)
‘Gartner states directly: “By 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals. As many as 25% of these will fail catastrophically’
I posted an article on this few weeks ago and got few comments on this- How far this is true or is it a cliché without any evidence. The only way to prove this is by having one database of all ERP projects going around in the world and doing a RAG reporting which is practically impossible. One of the fun-facts of consulting is that like a Traveler who travels around the world and gain exposure to different traditions, cultures a consultant sees quite a lot through these big programs and having spent 20 years into ERP I am one of them. I have kept my eyes and ears open and not just stuck to my area of work.
Back in 2008 I got engaged in Delhi, India and was talking on phone to my would-be around 1am in night when I started getting another call – I told my would be that it’s a work call and she hung up the phone abruptly almost not believing me. It was a call from my manager (I used to work for a Big 4 then) that there are some escalations by the client on an ongoing ERP project and I need to report to work sharp at 9. Now these kind of calls are quite common in a typical ERP project. The program has been running for 18 months. The go-live date has moved twice. The SI is producing RAG status reports that are mostly amber- which in practice means Red, translated into a color that does not frighten the board. And now, three weeks before the rescheduled go-live , the CFO is on the phone asking whether the system is ready.
I have taken that call more times than I can count. And I have learned something from every one of them.
The CFO never asks whether people are ready. They never ask whether the data is ready. They never ask whether the business has actually changed its processes to match the new system, or whether the finance team has done more than attend three training sessions and declare themselves competent.
They ask about the system. Because the system is the thing they can point to. It is the thing that cost £4million and took 18 months and has a name- Oracle, SAP, Workday, Salesforce, Dynamics etc.- and its sitting there like a very expensive piece of evidence that something either went right or wrong.
“The system is almost never the problem”
There is a comfortable fiction that runs through the ERP industry, and it is maintained with an interest in maintaining it. The fiction is this: ERP Programs fail because the technology did not do what it was supposed to do. The system had gaps. The configuration was wrong. The vendor oversold the capability. The platform was not mature enough for the requirement.
This fiction is comfortable for the clients, because it externalizes the failure- it was not us, it was the system. It is comfortable for System integrators, because it shifts the conversation towards change requests, additional licenses and phase2 engagements. I have worked on 2 programs where the Phase2 stabilization phase was 2-3 times more expensive than the implementation cost.
Let me take some examples from the Web to explain this in detail
It took LIDL 7 years, $600 million to do their ERP transformation project and then returning back to the legacy system.
In 2011, Lidl – the German discount grocery chain- began a SAP ERP implementation across its business. The project ran for 7 years. SAP recognized LIDL as one of its top customers in 2017. By 2018, Lidl had abandoned the project entirely and returned to the legacy system.
The failure is routinely described as a technology mismatch. It was not. It was a process refusal.
The specific issue at the heart of the Lidl failure was inventory valuation. Lidl had always managed inventory using purchase price — the price paid to acquire goods. SAP’s standard retail ERP solution used retail price valuation — the price at which goods are sold. This is a fundamental operational difference, not a minor configuration detail. It affects how profitability is tracked, how financial reporting works, and how the supply chain is managed.
Lidl was presented with a choice. Adapt its processes to align with the system — changing a core operational assumption the business had operated on for decades. Or customize the system to replicate the legacy approach — building complexity into the implementation to preserve a way of working.
Lidl chose the second path. It spent seven years and $600 million attempting to force enterprise software to work the way the legacy system had always worked. The customization accumulated. The system became something different from what SAP had designed, tested and sold. Upgrades became progressively harder. The gap between what the organization needed and what the system could deliver continued to widen.
Eventually, Lidl’s management concluded that the accumulated cost of continuing was greater than the accumulated cost of stopping. They wrote off the investment and went back to where they started.
The SAP platform runs Walmart, Nestlé, Shell and thousands of other large retailers successfully. The same software that failed at Lidl is running the core operations of some of the most complex supply chains in the world. The software was not unsuitable. The business was unwilling to change.
That unwillingness is a change management failure and a leadership failure. It is not a technology failure.
Technology-first thinking is the most seductive trap for any leadership team. It begins with an excitement over a new capability- be it Artificial Intelligence, Blockchain, or a sophisticated cloud-based ERP- and leads to a search for a problem to solve with it. In this pattern, the tool becomes the strategy. Organization spends months on vendor selection and implementation, only to realize that the expensive new system does not address the core bottlenecks of the business. Technology is an accelerator, but it cannot accelerate a vacuum. Without a business led objective, “technology-first” initiatives end up as expensive digital ornaments rather than functional assets.
FROM THE FIELD
Global Professional Services Firm- Implementing Oracle Cloud ERP
Nine months- Annual Bill run- And a warning nobody wanted to hear.
The system integrator – a major UK firm- had sold this client a nine-month ERP implementation. For a global For a global professional services firm of this scale and
complexity — multiple practice groups, cross-border billing, partner allocations, and a highly sensitive financial calendar — this was already an ambitious commitment. But the detail that defined the program’s trajectory was buried in the project plan: the proposed go-live date fell in the first week of the client’s annual bill run.
For a professional services firm, the annual bill run is not a quiet period. It is the highest-volume, most financially consequential processing cycle of the year. For a firm going live on a new ERP for the first time — with users who have not yet learned to operate it under normal conditions — the annual bill run is the worst possible moment to switch systems. It is the equivalent of learning to fly a new aircraft type on a fully booked transatlantic route.
I joined the program in its first week. Within five days, the picture was clear. The data cleanse had not started. Process design was still in progress across three workstreams. Change management had no dedicated resource. The system integrator’s plan showed UAT completing three weeks before the proposed go-live — which left no meaningful contingency for anything that didn’t work.
I told the program director directly: this program, on this timeline, going live at this point in the year, will fail. Not might fail. Will fail.
The response was predictable. The contract said nine months. The SI maintained it was deliverable. The client’s leadership team had committed to the timeline internally and were not willing to revisit it without evidence they could take to their board.
The evidence arrived. As the program progressed, the gaps became impossible to ignore. Data quality issues surfaced that would take months to resolve. Process sign-offs that should have been completed in design were still open in build. The SI’s resource model, designed for a nine-month engagement, began to strain.
The program was eventually extended to eighteen months. The cost approximately doubled. The go-live was moved to a quieter period in the financial calendar. With proper time, proper data preparation and a revised change plan, the system was implemented successfully.
The same technology. The same business. The same system integrator. On an honest timeline, with adequate preparation, it worked.
The lesson is not that the SI was incompetent. The lesson is that the commercial incentive to win the deal drove the timeline, not any realistic assessment of what the program required. No one on the client side pushed back hard enough early enough. And the person who did push back — in week one — was initially told to work within the plan rather than challenge it.
Eighteen months and double the cost later, the program board wished they had listened in week one.
What pattern are we observing here
ERP projects success is like hitting a winning number in national lottery. Each number on your ticket needs to match for you to win the jackpot. Think of number as
Data migration, Change management, quality of people on the program, Business case, Quality and Robustness of the design etc. etc. There is a highly likelihood that few numbers can match but only in very few cases all numbers will which will lead to the investment not meeting the right outcomes.
Final Thoughts
SAP, Oracle, Workday, Salesforce, Dynamics have been implemented hundreds of thousands of times. The platforms have been used to run the supply chain of the largest companies on earth, to close the books of global financial institutions, to manage the payroll of governments. They work.
The organizations implementing them are the variable. The timelines those organizations impose on themselves are the variable. The willingness of those organizations to change the way they work is the variable. The governance quality under which those organizations make decisions at critical program juncture is the variable.
The next time you hear that an ERP program failed because the system was not quite right, ask what decisions are made- and by whom- in the twelve months before go-live
The answer is rarely about the software