Why ERP implementations fail, and what going well looks like
The code is almost never the problem. The decisions made in the first month, usually by people who were not in the room, are.
8 min read
A failed ERP rarely crashes. It goes live, people use it reluctantly, a parallel spreadsheet appears within a month, and two years later nobody trusts the stock figure. No single moment went wrong. The failure was arranged much earlier.
These are the five we see most, in rough order of how expensive they are to fix once they have happened.
1. The data model was settled late
An ERP makes exactly one claim: there is a single place that knows what you have, what you owe, what you are owed and who did what. Everything else is features.
When the data model is decided module by module as the build progresses, each module is locally sensible and the whole is incoherent. Sales has a customer, finance has an account, service has a site, and nothing joins them cleanly. By the time anyone notices, three modules depend on the mistake.
The early warning
Screens are being designed before anyone has drawn the entities and their relationships. If you ask what a customer is and get three answers from three departments, stop there.
2. The exceptions were treated as edge cases
Every operation has a handful of things that happen weekly and are not in the process documentation. The part substitution approved verbally. The delivery signed for at the back door. The customer on terms agreed years ago that nobody wants to revisit.
Build for the happy path and those do not disappear. They move somewhere the system cannot see, which is precisely where they do the most damage, because now the system is confidently wrong rather than merely incomplete.
The early warning
The written scope contains no exception paths, or the phrase "we will handle that manually for now" appears more than twice. Manual for now is permanent in practice.
3. Nobody owned the system after go-live
Handover is where most software projects quietly end. The documents get zipped, the credentials get emailed, somebody says to get in touch if anything comes up and genuinely means it. A year later the answer to who owns this is a shrug and a login nobody has.
Ownership after launch has to be assigned to a named party in writing, or it defaults to nobody. That is not a contract detail. It is the single thing that decides whether the system is still healthy in year two.
The early warning
You cannot name the person responsible for the system twelve months from now, on either side. Post-launch software support sets out what that arrangement should actually contain.
4. Training was the plan instead of the symptom
Heavy training requirements are a design finding, not a rollout task. If people need a two-day course to enter an order, the software modelled a different job to the one they do.
Sometimes the training genuinely is the answer, because the process itself is complex and the complexity is real. It is worth checking the other explanation first, while changing the design is still cheap.
The early warning
The training budget grows during the build. That is usually the project quietly admitting something about the interface rather than about the users.
5. Everything went live at once
Big-bang rollouts fail in a particular way: every unknown has to be resolved before anything is live, so the unknowns get resolved on paper instead of in production. The first contact with reality happens on the day the business depends on it.
A phased rollout is not slower overall. It front-loads the learning into a release where being wrong is survivable, and it gives the people who do the job a say before the decisions harden.
The early warning
There is a single go-live date in the plan and no release before it that real users touch.
What a project going well looks like
Healthy ERP projects are recognisable from outside, and none of the signs are about technology.
- The data model and permission structure were agreed and written down before the first screen was designed.
- The written scope names the exceptions, including the ones that are embarrassing.
- Something real is in production within the first few months, used by people who do the job daily.
- A named person on each side owns the system after launch, in the contract.
- Monitoring exists and somebody has agreed what happens in the first five minutes of an incident.
- The plan survives a workflow turning out to be harder than expected, because it assumed one would.
None of this is about choosing better technology. It is about settling a small number of decisions early, in writing, with the people who do the work in the room.
That sequence is the whole of our method, set out on how we work, and the document it depends on is covered in how to write a software scope.
Questions we get asked
Frequently asked
- Is it ever worth restarting a failing ERP implementation?
- Occasionally, but less often than people fear. If the data model is sound, most other problems are recoverable in place. If the data model is wrong, continuing usually costs more than restarting, because every further module deepens the mistake. That is the question to answer first, before anything about budget or timeline.
- How early can we tell whether a project is in trouble?
- Usually within the first six to eight weeks. Look at whether the data model is written down, whether the scope names exceptions, and whether anyone who does the job daily has reviewed it. Projects that fail on those three rarely recover on delivery quality alone.
- Our users resist the new system. Is that a training problem?
- Sometimes, but check the design explanation first. Resistance concentrated on one or two screens is nearly always a modelling problem: the software asks for something in an order or a form that does not match how the work happens. Resistance spread evenly across everything is more likely change management.
- Who should own an ERP internally?
- Someone with authority over the process, not only over the technology. The decisions that matter are about approvals, roles and exceptions, and they need an owner who can settle a disagreement between departments rather than escalate it.
Tell us what you are planning.
A new platform, a replacement for something that no longer fits, or a product that needs someone keeping watch over it. Start with a conversation.