There is a version of an ERP project everybody has seen. Requirements are gathered for six months, a reference model is configured, the business is trained on it, and one weekend the old system is switched off. On Monday, something is wrong, and there is no version of Monday that works.
We do not run that project. Not because the risk appetite is different, but because on the systems we are usually asked about (a plastics plant in Riyadh, a trading operation in Dubai), there is no weekend available to bet.
The real failure is not technical
ERP fails when the software decides how the business should work. The reference model assumes a process; the plant has a different one, arrived at over years for reasons that are usually good and almost never written down.
The gap between those two fills with spreadsheets. Within a year the ERP holds the official numbers and the spreadsheets hold the real ones, and the project is nominally a success.
The workaround on a supervisor’s desktop is not a discipline problem. It is the requirement nobody wrote down, and a replacement that ignores it gets worked around within a month. So discovery happens on the floor, watching, rather than in a meeting room asking.
Module by module, each one reversible
The order is not arbitrary. It starts where the disagreement starts (usually production and inventory, because that is where the physical world and the ledger diverge first), then procurement, then finance and HR.
Each module goes live behind a switch that can be thrown back. That sounds like a deployment detail and it is really a negotiating position: it is what makes it possible for the plant to agree to go first on anything.
What the overlap costs
This is the part that gets underestimated, so it is worth being specific. While a module is live in the new system and the modules around it are still in the old one, the two have to agree, and something has to check that they do.
- A reconciliation job, running continuously rather than nightly, comparing the boundary records the two systems share.
- A decision, in writing, about which system is authoritative for each shared record during the overlap. "Both" is not an answer.
- A defined end date for the overlap, because two systems maintained in parallel forever is the second most common ERP failure and it does not look like a failure while it is happening.
- Somebody who owns the divergence when it appears. It will appear, usually within the first week, usually on a record type nobody listed.
That is real engineering cost that a cutover project does not pay. It buys the ability to be wrong on a Tuesday about one module instead of on a Monday about everything.
One master record, and why it is the whole game
Most of what makes an ERP disagree with itself is a second copy of a definition somebody needed on a Tuesday. A second item master for a department that wanted different codes. A second employee list for a site that joined later.
One item master, one employee master, one customer. Every request for a second one is a request to reintroduce the reconciliation problem the system was bought to remove, and it always arrives with a good local reason.
Configuration, not code
The Riyadh plant and the Dubai trading company run the same build. Procurement and HR are the same modules in both; sales and tax are where they diverge. Everything that differs is configuration.
The alternative, a fork per deployment, is the cheapest decision available at the start and the most expensive one by year three, because from that point every fix has to be applied more than once and eventually is not.
Tax is the clearest case. VAT rules that live in the codebase turn a regulatory change into an engineering project, so it gets done late and by hand. Modelled as configuration, the same change is a setting an accountant can be shown before it goes live.
What we would tell you before you commit
If a supplier offers you a fixed price for an ERP implementation without having spent time on your floor, the price is for the reference model, and the difference between that model and your operation is the part you will pay for later in spreadsheets.
Ask two questions instead: what happens if module three is wrong, and who owns the numbers during the overlap. The answers tell you more about the next eighteen months than any feature comparison will.
Written by
DevTechGuru Engineering
The engineers who built and still run the systems described on this site.
Published under the company name rather than an engineer's. That is a gap, not a house style. How we work.