Business
The ERP nobody uses: why business system projects fail
An ERP project doesn't fail with an error, but with a spreadsheet kept in parallel. The causes repeat: starting from the screens instead of the process, customising everything, migrating without rehearsal, going live all at once, and nobody sitting beside the people who have to use it. All predictable, all avoidable before signing.
The way an ERP project dies is not what you expect. There is no technical failure, no red error on screen. There is a spreadsheet, open on the second monitor of someone in the back office, updated every morning next to the brand-new system.
That file is the verdict. It says the system you paid for doesn't answer a question someone asks every day, and that the cost was paid without collecting the benefit. The causes are almost always the same five.
1. Starting from the screens instead of the process
The first meeting is a demo. It is convenient — you see something — and it is the fastest way to make the wrong decision: you are assessing how a product looks, not whether it covers your work.
The useful conversation starts elsewhere: who does what, with which document, where data is typed a second time, where people wait. It takes being on site and watching, because the version told in a meeting and the one happening at the counter never quite match. Anyone selling you a system without having seen how you work is selling what they have, not what you need.
2. Customising everything, then falling behind
Faced with a standard product, the temptation is to make it look like the old one. Every request seems reasonable, and every customisation is code to maintain: at the first major upgrade half the changes have to be redone, and at that point the upgrade gets postponed. Three years later you are on a version nobody updates.
Our rule is a single question per request: do we do this process the way everyone does it, or is it one of the reasons customers choose us? In the first case you adapt to the standard and save money; in the second you customise, in a separate versioned module the upgrade doesn't touch.
If the spreadsheet stays open next to the ERP, the project isn't finished. It has only been delivered.The acceptance test we use
3. Data migration rehearsed on the day itself
It is the phase everyone underestimates and the only one that allows no improvisation. Old data is always worse than you remember: duplicate customers, codes used for two different things, note fields containing information someone genuinely relies on.
Migration must be rehearsed several times, and every rehearsal checked against the numbers: do the balances match? Do the open items agree? Are there as many records as expected? If the first rehearsal happens on go-live weekend, you are discovering the problems at the worst possible moment.
4. Going live all at once
The single big launch has an organisational appeal — one weekend, everything switched on, Monday we start — and it is the choice that concentrates all the risk in one point. If something doesn't work, you are not fixing a problem: you are stopping the company.
The alternative is to start from the flow that matters most and add the rest once the first really runs. You lose a few weeks and gain the ability to fail small. Where running both is sustainable, keeping the old system in parallel for one billing cycle is the best safety net there is.
5. Nobody sits beside the people who will use it
Training given two weeks earlier, in a classroom, on an empty test environment, is not training: it is a presentation. People genuinely learn on the first day they have to do their real job with the new tool, and that is when someone needs to be next to them.
It is also when the things the analysis missed surface — and they are always few and important. A project with no two weeks of hands-on support after go-live has saved money on the part that decides whether the system gets used or worked around.
How to spot it in time
Three signals, all visible before signing:
- The quote is itemised to the cent over twelve months. It means the supplier has estimated work they have not yet understood.
- Nobody asked to speak with the people who will use the system daily, only with the people who decide.
- When asked "what happens if halfway through we find we need something different?", the answer is awkward. It is the most likely question of all.
If you have a system nobody fully uses, the answer is not necessarily to replace it. In most cases it pays to understand why that spreadsheet still exists: the answer is cheaper than a new project, and often faster too.