We have been asked to rescue a substantial number of ERP implementations over twenty years, and the pattern is consistent enough to be useful. In almost none of them was the underlying technology the problem, and in almost none was the vendor incompetent in any ordinary sense.
They failed because the system modelled a generic version of the industry rather than the specific business, and the difference between those two things surfaced during testing, when the cost of change was at its highest and the goodwill at its lowest.
This article is about why that happens so reliably and what actually prevents it, which is mostly sequencing rather than software selection.
The specification problem
The valuable knowledge in an operating business is undocumented and frequently unconscious. That single fact causes most ERP failure.
The scheduler knows that one particular customer always revises the order after the first week, so nothing is cut until day eight. The storeman knows which supplier substitutes material grades without telling anyone. The accounts clerk knows that three customers are invoiced differently for reasons that made sense in 2014. None of this appears in a requirements workshop, because the people who hold it do not consider it information. They consider it obvious.
A requirements workshop therefore captures what people say they do, which is the approved process. The system gets built to that. Then testing begins with real cases, the exceptions surface, and the business discovers the system cannot represent half of what it actually does.
The only reliable remedy is to watch the work. Consecutive days, on site, across a full cycle including month end, a shift handover and at least one genuine exception. Almost every scope we have revised for the better was revised after somebody stood beside the process rather than after another meeting about it.
In practice
Big-bang cutover, and why it persists
The single most damaging structural decision in ERP implementation is switching everything at once on a defined date, and it persists because it is easier to plan, easier to contract for and easier to invoice against.
It concentrates all the risk into one weekend. If anything is wrong, and something always is, the business discovers it on Monday with no fallback, production affected and everyone under pressure. The pressure then produces workarounds, the workarounds become permanent, and within six months the organisation is running a system it does not trust alongside the spreadsheets it reverted to.
The alternative is unfashionable and it works. Replace one process at a time. Run each in parallel with the existing method for a full cycle so nobody has to trust the new system before it has proved itself. Once the numbers agree for a complete period, the old method stops and you move to the next.
It is slower, it costs more in the short term because of the duplicated effort, and it is the difference between implementations that finish and implementations that get quietly abandoned. Every step is short enough to abandon if it is not working, which is precisely what makes it safe to begin.
The exception path is the real system
Most software is designed happy path first and exceptions second. For operational systems that order should be reversed, because the exceptions are where the business actually lives.
If the only way to record a rework, a split job, a partial return, a scheme issue or a material substitution is a workaround, then the workaround becomes the system of record and everything downstream is wrong. The reporting is wrong, the costing is wrong, and nobody trusts the numbers, which is the point at which people revert.
So the design question that matters is not whether the system handles the standard case. Every system handles the standard case. It is whether it can represent the awkward things that happen weekly, as first-class operations with proper records, rather than as something a supervisor has to work around.
When we scope, we ask specifically for the cases people find annoying. Those are the ones that will decide whether the system is used.
The question to ask a vendor
Describe your three most awkward recurring situations, the ones your staff grumble about, and ask how the system represents each. A vendor who answers with a workaround involving a manual adjustment or a note field has told you that your real process will live outside their software.
What actually prevents failure
After twenty years the preventative measures are a short list and none of them are about choosing better software.
Discovery on site over consecutive days, watching a full cycle. Sequencing by process rather than by module, with parallel running until the numbers agree. Designing the exception path before the happy path. A named person on the client side with authority to decide, rather than a committee that reviews. And reviews where the client uses the system with their own data rather than watching a demonstration, because a demonstration is designed to produce nodding and an hour of hands-on use produces eleven findings.
One more, which is commercial rather than technical: do not pay for the whole implementation upfront. Scope and price the first module separately. The honest way to judge a supplier is to watch them deliver one thing and see whether the people who have to use it actually do. If they do, the next module is an easy decision. If they do not, you have found out cheaply.
In practice
Key takeaways
- ERP fails at specification, not engineering. The system modelled the industry rather than the business.
- The rules that matter are undocumented exceptions nobody mentions because they seem obvious.
- Big-bang cutover concentrates all risk into one weekend and is the most damaging structural choice.
- If the only way to record an exception is a workaround, the workaround becomes the system of record.
- Parallel running until the numbers agree is what separates implementations that finish from those abandoned.
- Scope and price the first module separately so you can judge delivery before committing.
Frequently asked
Specification rather than technology. The valuable knowledge in an operating business is undocumented and frequently unconscious, so a requirements workshop captures the approved process rather than the real one. The system is built to that, and the difference surfaces during testing when the cost of change is highest.
Phased, one process at a time, with each running in parallel against the existing method until the numbers agree for a full cycle. Big-bang cutover persists because it is easier to plan and contract for, and it concentrates all risk into one weekend with no fallback. Each phased step is short enough to abandon, which is what makes it safe to start.
Longer than most vendors propose, and it should happen on site. Consecutive days watching a full operating cycle including month end, a shift handover and at least one genuine exception. Scattered half-day visits and video calls produce a specification describing what people say they do rather than what they actually do.
Describe your three most awkward recurring situations, the ones staff grumble about, and ask how the system represents each. A vendor answering with a manual adjustment or a note field has told you your real process will live outside their software, which means the reporting and costing will be wrong and people will revert.
Not the whole thing. Scope and price the first module separately, deliberately small. The honest way to judge a supplier is to watch them deliver one thing and see whether the people who have to use it actually do. Suppliers who require commitment to a full programme before demonstrating anything are managing their risk rather than yours.