Why ERP implementations fail — and the three fixes that matter

I have been called into enough stalled ERP projects to notice that the post-mortems all sound different and are all the same. The software gets blamed. The implementation partner gets blamed. Occasionally a specific employee gets blamed.

The actual causes are narrower than the stories suggest, and there are three of them.

Why does an undocumented process sink an ERP project?

A business decides to implement an ERP. Nobody writes down how work currently flows, because everyone assumes they already know. Configuration starts in week two. Each department describes its process from memory during a workshop, in an idealised form that omits every exception — and exceptions are where operational reality lives.

The system goes live encoding a process that never existed. Staff hit the first exception in day three, find no path through it, and route around the system. Within a month there are shadow spreadsheets, and the ERP has become an expensive data-entry chore performed after the real work is done.

The fix: spend one to two weeks documenting the as-is process before touching configuration — by observation, not interview. Sit with the storekeeper. Watch what happens when a delivery arrives short. Note every workaround, because each is a requirement in disguise.

Then design the to-be process explicitly, decide which workarounds become supported flows and which get eliminated, and get it signed off. This step feels slow and is the single strongest predictor of whether the project succeeds.

What happens when nobody owns user adoption?

Implementation partners are contracted to deliver a configured system. They are almost never contracted to deliver a system people use. Those are different projects with different skills, and the second one usually has no owner.

What this looks like in practice: training happens once, two weeks before go-live, in a single session covering every module for every role. People retain almost none of it. There is no reference material. When someone gets stuck at go-live, the queue for help is long, so they revert to the old method — and the old method is still available, which is the real problem.

The fix, in four parts:

• Role-based training on your own data. A storekeeper needs the twelve screens they will actually touch, in depth, using items they recognise — not a tour of the whole product.
• Written SOPs and recorded walkthroughs. People forget. Give them something to consult at 6pm without asking anyone.
• Named internal champions per department, trained deeper, who become the first line of help. Adoption spreads through peers far better than through consultants.
• Close the old path. This is the hard one. As long as the old spreadsheet works, some people will use it, and your data will be split. Set a firm date, communicate it early, and actually enforce it.

Why does treating ERP as an IT purchase fail?

An ERP is not software procurement. It is a change to how the business operates, delivered through software. When it is delegated entirely to IT or to an outside partner, three things follow.

Decisions that require business authority — should branch managers approve their own purchases up to a limit? do we enforce batch tracking even when it slows receipt? — get made by whoever is available, usually a consultant guessing. Cross-department conflicts have no arbiter, so they get deferred, and deferred conflicts become go-live emergencies. And staff read the leadership's absence accurately: if the owner does not attend the reviews, this is not important.

The fix: a business owner — ideally the person who feels the operational pain most acutely — sponsors the project, attends reviews, makes the process decisions and is visibly accountable for the outcome. Not the IT manager. Not the consultant.

Budget their time explicitly: roughly four to six hours a week through the project. If nobody senior can commit that, the honest conclusion is that the business is not ready to implement an ERP yet, and starting anyway will cost more than waiting.

What are the warning signs of a failing ERP project?

Stalling projects announce themselves. Watch for these, roughly in the order they appear:

1. The blueprint document does not exist, or nobody has read it
2. Go-live has moved twice and no scope was removed either time
3. Requirements arrive as feature requests rather than process descriptions
4. The steering meeting is attended by consultants and the IT manager only
5. Master data cleanup is "in progress" past the halfway point of the project
6. Training is scheduled for the fortnight before go-live

Two or more of these means intervene now. All six means stop, re-plan, and accept a delay — it is dramatically cheaper than a failed go-live.

Can a stalled ERP implementation be recovered?

Recovery is usually possible and usually cheaper than starting over, but it needs an honest audit first: is the configuration sound, is the data trustworthy, and are people using it? Those three answers determine whether you fix, re-implement, or migrate.

The most common finding, by a wide margin, is that the configuration is broadly fine and the adoption never happened. That is a good outcome, because adoption is fixable without spending the licence money again.