Roughly half of major ERP programmes deliver material value. Half do not. The pattern of failure is consistent across industries and geographies. Here's what goes wrong — and what to do differently.
Dynamics, Oracle, SAP, Odoo all work. They are mature, well-engineered platforms that — in the right hands — solve the problems they're designed to solve. When ERP programmes fail, the failure is almost never about the software. It's about what surrounds the software.
Specifically, failure tends to arise from one of four patterns: wrong business-case discipline, wrong operating-model work, wrong change management, or wrong implementation partnership. Often more than one.
Every ERP programme has a business case. A surprising proportion of those business cases are better described as narratives than as defensible financial models. The benefits are aspirational. The costs are optimistic. The risks are under-quantified. The timeline is heroic.
When the programme runs into trouble — as most do at some point — the lack of a defensible business-case baseline makes every decision harder. Should we de-scope? Based on what? Should we accelerate? At what cost? Should we kill the programme? What's the actual value at risk?
What to do differently: commission the business case independently of the vendors being considered. Model at the level of specific business processes and specific benefit streams. Build in risk-adjusted ranges rather than point estimates. Keep the model alive through delivery — every major decision should be tested against it.
In failing programmes, the sequence is often: pick the vendor, start configuration, discover the process mismatches, try to change processes under time pressure. This produces two problems — the configuration is built to the wrong processes, and the process changes are being forced rather than designed.
In successful programmes, the sequence is reversed. Process design happens before vendor selection. The operating model is decided. The process taxonomy is agreed. Then vendor selection is against a clear picture of what the system needs to support.
What to do differently: invest in target operating model work before vendor selection. It is uncomfortable — the instinct is to pick the vendor and "figure the rest out" — but operating-model work before selection is strictly less expensive than doing it after.
In most failing programmes, the change-management stream starts at 20% of the resource level of the technology stream and is handed to the least experienced member of the leadership team. This produces the textbook outcome — the software goes live, but the organisation doesn't actually adopt it.
Adoption failure shows up in a specific way: six months after go-live, the promised benefits aren't being realised. Investigation reveals that user workarounds, dual operations, and shadow systems have proliferated. The old system is effectively still running in parallel. The new system has been installed but not absorbed.
What to do differently: resource change management at 30–50% of the technology stream, depending on scope. Staff it with experienced change leaders with authority to stop the technology if adoption is at risk. Measure adoption as a gating criterion for each wave, not a post-hoc metric.
ERP implementation is a specific skill. Being excellent at consulting does not make a firm excellent at implementation. Having deep product knowledge does not mean having deep operational experience in the client's industry. Being big does not mean having the senior people available for this specific programme.
Clients often find out they have the wrong partner 6–12 months into delivery, when the pattern of escalated issues and accommodations becomes undeniable. At that point, changing partners is expensive and risky.
What to do differently: select the implementation partner separately from the software selection if possible. Weight the decision toward operational experience in your sector. Require named senior people to be contractually committed — not just sold in the pitch. Include contractual exit rights that make a partner change feasible if the programme goes off track.
The programmes we see succeed share a common shape. They have defensible business cases modelled at the process level. They complete target-operating-model work before vendor selection. They resource change management seriously, with authority. They select implementation partners on operational experience. And they structure the commercial arrangement to keep incentives aligned from start to finish.
The programmes that fail usually fail on two or three of these. Rarely all four — one or two at a time is enough.
ERP failure is not a software problem. It's a discipline problem. The organisations that succeed invest in the work that surrounds the software — business case, operating model, change, partner selection — at a level that matches or exceeds the investment in the software itself. The organisations that fail under-invest in exactly these areas, then wonder why the outcomes differ.
If you are about to commission an ERP programme, or midway through one that is not going well, the questions above are worth a board-level conversation before the next wave goes live.