Why ERP Programmes Keep Underdelivering

The Pattern

I have spent eighteen years inside enterprise transformation programmes. The pattern that ends badly is almost always the same.

ERP implementations, platform migrations, process redesigns, digital rollouts. Different industries, different organisations, different systems.

It does not start badly. It starts with genuine energy: a business case with a credible number on it, a vendor with a compelling demo, a board that has approved the investment, a team that believes they can make it work. The first few months usually go well. Requirements are gathered, workshops are run, the configuration begins.

Then somewhere in the middle, the gap between what was planned and what is actually happening starts to widen. Data migration takes longer than anyone expected. The business stakeholders who were available at the start are now consumed by their day jobs. The scope grows, because the original discovery was not deep enough to surface what was really there. The go-live date moves. Then it moves again.

What surfaces at go-live is almost never a technology failure. The platform usually does what it was configured to do. What surfaces is everything that was not addressed before the platform was turned on: master data that was never cleaned, processes that were never redesigned, people who were never properly prepared for a different way of working, and a definition of success that nobody had written down clearly enough to hold anyone to.

A public example

Birmingham City Council's ERP implementation illustrates the scale this can reach. An estimated £39 million programme grew to approximately £90 million and left the council without adequate financial management systems for over two years. The technology was not the primary failure point. The governance, data, and process foundations were.

Fifty-five to seventy-five percent of ERP implementations fail to meet their stated objectives. The average cost overrun is around 189 percent. Those numbers have not moved meaningfully in twenty years of measurement. The technology has changed. The pattern has not.

What Is Actually Failing

The most useful insight I have seen from the research is this: the typical ERP programme experiences a 56 percent value deficit alongside only a 7 percent time overrun.

That is not a project management failure. A 7 percent schedule slip is within any reasonable tolerance. The value is missing because the strategy was wrong upstream of delivery - the wrong problem was being solved, or the right problem was being solved in the wrong sequence, or the foundation work required to deliver value was de-scoped to protect the budget.

42%

failures trace to inadequate change management

35%

to underestimated project staffing

34%

to technical or data issues known before go-live

93%

of organisations require customisation to their ERP

Forty percent of overrunning projects discovered organisational issues at go-live that should have been obvious from day one. None of these are technology problems. They are delivery and governance problems that sit upstream of any platform decision. And they do not disappear when the ERP goes live. They get absorbed into the running estate and become the invisible debt that every subsequent initiative has to work around.

Ninety-three percent of organisations require customisation to their ERP. Only 7 percent run it as delivered. Every customisation is a decision made at a specific point in time, often to preserve an existing way of working rather than to improve it, and it compounds over years into an estate that is genuinely difficult to change. That estate is what the AI is about to be deployed on.

Change Management Project Staffing Data Readiness Organisational Alignment Customisation Debt

"The typical ERP programme experiences a 56 percent value deficit alongside only a 7 percent time overrun. That is not a project management failure. The value is missing because the strategy was wrong upstream of delivery."

The AI Moment, and Why the Pattern Is Rhyming

I am watching something familiar happen.

Boards are asking about AI. Budgets are being allocated. Vendors are presenting compelling demos. Programmes are being approved with credible-looking business cases attached.

The energy is real. The intent is genuine. And in too many conversations, the same questions are not being asked that were not asked before the ERP went in.

What is the state of the data the AI will act on? Which business processes have been redesigned for machine action rather than human navigation? Who owns the governance of what the AI can and cannot do, and what happens when it does something unexpected? How will we measure whether it is working, in terms a CFO will accept, not just an AI team?

Only around 20 percent of enterprise AI projects achieve their stated objectives. Gartner estimates 30 percent of generative AI projects are abandoned after the proof of concept phase. MIT research in 2025 put the failure rate for enterprise generative AI pilots closer to 95 percent.

The technology is genuinely capable. The gap between what AI can do in a demo and what it delivers at enterprise scale is not an AI gap. It is a foundation gap. The same foundation gap that shows up in ERP programmes.

What AI Specifically Makes Worse

There is an important difference between ERP failure and AI failure that is worth being direct about.

A Failed ERP Implementation

Underdelivers. Costs more than planned, takes longer, does less than promised. But it typically does not make things actively worse at speed. It sits there, frustrating people, broadly stable.

AI on a Broken Foundation

Does not sit still - it acts
Returns confidently wrong results
Takes actions on bad data at machine speed
No person in the loop to catch exceptions

An AI agent querying master data that has never been cleaned does not know the data is wrong. It returns confidently incorrect results and takes actions based on them. The errors do not surface as a system failure. They surface as business decisions made on bad information, potentially at scale and at machine speed.

An AI agent amplifying a broken process makes the process faster and more broken simultaneously. The exceptions that a person would have caught and handled get processed automatically. The 25 percent of records with silent errors get actioned rather than flagged.

McKinsey has found that organisations reporting significant financial returns from AI were approximately twice as likely to have redesigned their end-to-end workflows before selecting their AI tools. Process first. Technology second. The causality is clear: AI amplifies what already exists. If what exists is well-designed and well-governed, the amplification is value-creating. If what exists has the accumulated gaps of a decade of underinvestment in the foundation, the amplification surfaces those gaps in ways that are harder to ignore and harder to fix.

The governance layer is a specific concern. Most enterprise AI governance programmes are still being developed. Forty-five percent of organisations surveyed in 2026 reported they were still building their AI governance framework. In an ERP, a governance gap means an approval that gets bypassed, a report that does not reconcile. In an agentic AI environment, a governance gap means a non-human actor taking actions inside live systems with no audit trail, no rollback mechanism, and no defined boundary around what it is permitted to do.

That is a different category of risk. It requires the foundation work to be in place before the AI is deployed, not built concurrently, and certainly not deferred.

"An AI agent on a broken foundation does not sit still. It acts. And it does not know the data is wrong."

What the Organisations That Get It Right Do First

The organisations I have seen approach this well are not waiting for a perfect foundation before starting. That would mean waiting indefinitely.

What they do instead is treat the AI initiative as the reason to finally address the foundation work that got de-scoped or deferred in the original ERP implementation. They use the AI business case to fund the data quality programme that should have been funded three years ago. They use the AI roadmap to force the process redesign conversations that never quite happened. They treat the governance question as real work, not a compliance afterthought.

They do not deploy AI first and fix the foundation later. They sequence it the other way.

The result is that when the AI does go live, it lands on something it can trust. The data is consistent enough for a machine to act on. The processes have been designed with machine action in mind. The governance is clear about what the AI can and cannot do, and the audit trail exists to verify it.

This is not a technology decision. It is a delivery and governance decision that happens to involve technology. It is, in many ways, the same discipline that determines whether an ERP implementation delivers its value - the same discipline that was missing in the 55 to 75 percent that did not.

I am not suggesting that every organisation needs to pause its AI ambitions until some theoretical readiness threshold is met. Momentum matters. Learning by doing has real value. Pilots that fail fast teach things that planning cannot.

What I am suggesting is that the decision about where to start matters more than many organisations are treating it. Starting with AI on top of a data foundation that was known to be inadequate before the ERP went live is not a fast path. It is a path that will surface the same problems again, at higher speed, with a higher cost to unwind.

"The question worth asking before the next AI programme is approved is not which AI model to use. It is whether what the AI will be asked to act on is actually ready to be acted on."

That is a different question. It is the one I keep coming back to.

Why ERP programmes keep underdelivering - and what that means for your AI ambitions

Open to comparing notes &
genuine conversation

Open to comparing notes &genuine conversation

Open to comparing notes &
genuine conversation