Why Most ERP Implementations Fail (And How to Avoid Being One of Them)

ERP projects rarely fail in a dramatic way. More often they go live late, cost more than planned, and end up used for a fraction of what they were bought for. The causes are consistent and largely preventable: a process map of the business as it should work rather than as it does, training squeezed into launch week, and nobody owning the system once it is live.

You have probably seen the claim that most ERP implementations fail. The figures quoted vary wildly depending on who is doing the quoting, and it is worth being sceptical of all of them. Vendors and consultancies both have reasons to shape that number, and the studies behind it rarely agree on what “failure” even means.

What does ERP “failure” actually look like?

Very few projects collapse outright. What usually happens is quieter. Invoicing moves across but stock control doesn’t. Two departments adopt the system and a third keeps its spreadsheets. On paper the project completed. In practice the business paid for capability it never got.

That distinction matters, because the causes of quiet underperformance cluster into three areas, and none of them are really about the software.

Failure point one: mapping the process you wish you had

Almost every implementation begins with process mapping, and almost every process map is subtly wrong. Not because anyone is dishonest, but because the people in the room describe the official process rather than the real one.

The official process says purchase orders are approved by the operations manager. The real process is that when she’s away, the warehouse supervisor approves them verbally and the paperwork catches up on Friday. Build a system around the official version and you have made the way the business actually runs impossible. People will work around it, usually with a spreadsheet.

The fix is unglamorous: talk to the people doing the work, not only the people managing it, and ask specifically what they do when things go wrong. The exceptions are where the real process lives.

Failure point two: training treated as a launch-week event

Training is usually scheduled as a block just before go-live, which is precisely when everyone is busiest and least able to absorb anything. Two days of screens, a PDF, and then live running.

What people retain from that is enough to complete their most common task and nothing else. Every edge case becomes a support ticket or, more often, a workaround that never gets reported. Six months later the business concludes the system is inflexible, when really nobody was ever shown the flexible parts.

Training works better spread thin and repeated: short sessions before launch, then again a month after, once people have hit real problems and have real questions. The second session is the one that changes behaviour, and it’s the one most projects skip.

Failure point three: nobody owns it after go-live

Go-live is treated as the finish line. The project team disbands, the implementation partner’s contract ends, and the system is handed to whoever in the business seems most comfortable with it.

But the first six months after launch are when the system needs the most attention. Reports need adjusting, permissions need fixing, and the assumptions made during configuration meet reality. Without someone accountable for that, small irritations harden into permanent workarounds, and the workarounds are what people eventually mistake for the system’s limitations.

What should you ask a partner before you sign?

• Who specifically will be accountable for the system three months after go-live, by name?
• What support is included once implementation ends, and what response time does it guarantee?
• How much training is included, and can some of it be scheduled after launch?
• Which of our current processes will have to change, and which will the system adapt to?
• What happens to the data we can’t clean in time?

If a prospective partner is vague on the first two, that tells you more than any demo. The answers show whether they see go-live as the end of their involvement or the middle of it.

None of this is about the software

None of the three failure points are really about which product you choose. Good products get implemented badly all the time, and unremarkable ones work fine when the process mapping was honest, the training was spaced out, and somebody stayed accountable afterwards.

That is the part of ERP work we care most about at Eirvancee, whether it’s a NetSuite rollout or a smaller custom system. If you’re weighing up an implementation and want a frank second opinion on scope, timeline or support, book a free 20-minute consultation and we’ll talk it through, including whether now is the right time at all.