When an ERP project is described as a failure, the software is usually blamed. In our experience the decisive mistakes were made much earlier — in how the scope was set, how the process was understood, and how the change was introduced to the people expected to use it.
The process was never documented
A module list is not a process map. If nobody has written down how an order actually moves through the business, including the exceptions and the informal controls, then the system is designed against an assumption. The exceptions then arrive during testing, when accommodating them is expensive.
The exceptions are not edge cases. In most process-heavy businesses, they are a substantial share of daily volume.
The counter is straightforward but requires patience: trace a live order end to end with the people who handle it, and write down what actually happens rather than what the policy says should happen.
Everything was attempted at once
A simultaneous launch across every department maximises risk. Training load peaks, support demand peaks, and any single failure undermines confidence in the whole system. Phasing by department — starting where the pain is sharpest — produces visible results early and builds internal advocates.
End users saw the system only at training
If the storekeeper first sees the stock entry screen during training, their objections arrive after development is complete. Reviewing a prototype with the actual daily users costs a conversation; the same corrections after build cost weeks. Adoption follows from their involvement, not from a mandate.
Migration was treated as a final step
Data migration is where implementations most often lose credibility. Opening balances that do not reconcile, duplicate customer masters and inconsistent item codes are discovered days before go-live, and the launch begins with users distrusting what they see. Migration should start early, be reconciled with the client's own team, and be verified against records they already trust.
Nobody inside the organisation owned it
An implementation needs an internal owner with the authority to make decisions — someone who can settle a disagreement between two departments about how a process should work. Where that role is absent, decisions escalate slowly and the project stalls between reviews.
Go-live was treated as the finish line
The first month-end, the first stock verification and the first payroll run are the moments where a new system either earns trust or loses it. Support needs to be closest precisely when the project is formally 'complete'. Planning for that period — and for the enhancements that follow — should happen during architecture, not afterwards.
A short checklist
- Is there a written process map that the operating team recognises as accurate?
- Has the scope been phased, with a defined first release?
- Have the daily users reviewed and approved the screens they will use?
- Has migration started, and has migrated data been reconciled against trusted records?
- Is there a named internal owner with decision-making authority?
- Is post-launch support defined in writing, including response commitments?
None of these are technical questions. That is precisely the point: the technology is rarely the constraint.
Written by
Beyond Papers
We build customised ERP, CRM and manufacturing systems for process-heavy businesses. If any of this is familiar, a discovery conversation costs nothing.
Book a consultation