You have probably seen the statistic that most ERP implementations fail. The figure quoted varies wildly depending on who is doing the quoting, from around 50% to over 75%, and it is worth being sceptical about all of them. Software vendors and consultancies both have reasons to shape that number, and the studies behind it rarely agree on what “failure” even means.
“Failure” is a slippery word
Very few ERP projects collapse outright. What usually happens is quieter: the system goes live late, costs more than budgeted, and ends up used for perhaps 40% of what it was bought for. Invoicing moves across but stock control doesn’t. Two departments adopt it 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 that quiet underperformance are consistent and largely preventable. In practice they 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 just criminalised how the business actually runs. People will work around it, usually by keeping 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 single 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 calcify into permanent workarounds, and the workarounds are what people eventually mistake for the system’s limitations.
Questions worth asking before you sign
- Who specifically will be accountable for the system three months after go-live, by name?
- What does support cost once implementation ends, and what response time does it guarantee?
- How many hours of training are included, and can any 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’s worth more than any demo. The answers tell you whether they see go-live as the end of their involvement or the middle of it.
None of this is about the software
Notice that 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. The choice of platform matters far less than most sales cycles imply.
That’s the part of ERP work we care most about at Eirvancee, whether that’s a NetSuite rollout or something smaller. If you’re weighing up an implementation and want a frank second opinion on scope, timeline or what support should actually cost, you can book a call and we’ll talk it through, including whether now is the right time at all.
The projects that go well are rarely the ones with the biggest budgets. They’re the ones where somebody insisted on describing the business as it really works, and then stayed around long enough to fix what that revealed.