We have been called in to rescue enough abandoned ERP deployments to notice a pattern. In almost every case the software worked. It compiled, it deployed, the reports ran. What failed was the assumption underneath it.
Here is what actually goes wrong, in the order it usually happens.
1. Requirements gathered in a meeting room
A requirements document written by managers describes how work is supposed to happen. The people who will use the system every day know how it actually happens — including the exceptions, the workarounds and the informal steps that keep the business running.
If those never make it into the specification, the system will be technically correct and operationally useless. Staff will keep the old spreadsheet alongside it, and within six months the spreadsheet wins.
The fix is unglamorous: sit on the floor and watch the work before writing anything.
2. Buying modules nobody asked for
Vendors sell suites because suites carry a bigger licence. Organisations buy them because a longer feature list feels safer.
In practice, unused modules are worse than absent ones. They clutter navigation, confuse training, and create the impression that the system is complicated — which becomes the reason people avoid it.
Buy the core, prove it works, then extend. Modular delivery also spreads the cost, which most finance departments prefer anyway.
3. Training treated as a final-week task
Training is often scheduled after go-live, as a single session for everyone. That is roughly the worst possible design.
Adoption depends on the first week. Staff need someone physically present who can answer a question in ten seconds rather than through a ticket. We schedule floor-walking support for the entire first week of every deployment, and it is the single highest-return thing we do.
4. No migration of history
A system launched with an empty database is a system with no reason to be used. Staff still need last year's data, so they still open the old files, and the new system becomes a second place to enter things.
Migrate the history first, reconcile it, and launch with a database that can answer real questions from day one.
What prevents failure
None of the above is technical. It is about whose reality the system is modelled on. Spend the first three weeks understanding the operation, deliver a narrow core that works properly, migrate the history, and put humans on the floor during launch week.
That is the whole method. It is not sophisticated, but it is the difference between a system that runs a business for a decade and one that is quietly abandoned in a quarter.
We answer technical questions from people who are not clients. If this is a problem you are facing, write to us and we will tell you what we would do.
Ask a question →