Are you ready for ERP? Five questions to answer before the tender
ERP projects fail on organisational readiness far more often than on software capability. These are the questions worth answering before you write the specification.
An ERP implementation replaces the way an organisation records what it does. That is an organisational change with a software component, not a software project with a change component, and the sequence matters because it determines who has to be in the room.
1. Does one number have one owner?
Ask three departments for the value of current inventory and see whether you get one answer. If you get three, the ERP will not fix that — it will force the disagreement into the open on day one, at which point somebody must be empowered to decide which definition is correct. Nominate data owners before go-live, not during it.
2. Is your chart of accounts fit to build on?
A chart of accounts that has accumulated ad-hoc codes for fifteen years will carry that mess into the new system permanently, because nobody wants to renumber during a migration. Restructuring is painful once and cheap afterwards. Doing it as part of the implementation is the only realistic opportunity you will get.
3. Who can stop a process?
- If the system enforces that a purchase requires a budget line, and a genuine emergency has no budget line, what happens?
- Who can override, what is recorded when they do, and who reviews the overrides?
- An ERP with no override path gets bypassed. An ERP with an unlogged override path fails audit.
4. Are you buying modules you will actually operate?
Module count is the easiest thing for a vendor to sell and the hardest thing for an organisation to absorb. Every module needs an owner, trained users, and a reason to exist on the day it goes live. A finance and procurement core that works is worth more than nine modules where six are unused and quietly diverge from reality.
5. Have you costed the year after go-live?
Implementation budgets routinely stop at go-live. The year afterwards contains the enhancement requests that emerge once people use the system properly, the reporting nobody specified because they did not know it was possible, and the staff turnover that requires retraining. Budget for it explicitly or it will be funded by cannibalising something else.
The parallel running argument
Running the old and new systems together for a period is expensive and unpopular, and it is the single control that most reliably catches a migration error before it becomes a year-end problem. We insist on it. Clients rarely thank us during the parallel period and regularly do afterwards.
Sources and further reading
External links, provided for verification. CyberEdge is not responsible for third-party content.