Why ERP Rollouts Fail: It Is Almost Never the Software

Post-mortems on failed ERP programmes rarely conclude that the software could not do the job. They conclude that people kept working the old way, that data quality was worse than assumed, or that the process the system encoded was not the process the business actually ran.

The Shadow Process Problem

Every organisation has an official process and a real one. The real one includes the spreadsheet that reconciles two systems, the group chat that resolves urgent exceptions, and the person who knows which customers get non-standard terms.

ERP implementations are usually designed against the official process. At go-live, the real process has nowhere to live, so it moves back into spreadsheets — and the ERP becomes an expensive system of record that nobody trusts.

Discovering the real process before design, without punishing the people who reveal it, is the highest-value work in the entire programme.

Data Quality Is Always Worse Than Believed

Every migration finds duplicate customers, products with three different unit conventions, and historical records nobody can explain. Teams consistently underestimate this and consistently pay for it at go-live, when operations depend on data that turns out to be wrong.

Profile the data early and honestly. Cleaning is slow, unglamorous and cannot be compressed, so it needs to start long before anyone expects.

Configure Toward the Standard

Heavy customisation is the most reliable predictor of a painful long-term relationship with an ERP: upgrades become projects, vendor support weakens, and institutional knowledge concentrates in a few people.

Customise where the process is a genuine competitive advantage. Everywhere else, adapt the process to the software — which is a change management conversation, not a technical one.

Train on the Job, Not in a Room

Classroom training weeks before go-live is forgotten by go-live. Role-based training in the days around launch, with support embedded in the teams doing the work, is what actually transfers.

Identify credible people within each function early, involve them in design, and let them be the first line of support. Peers get asked questions that consultants never hear.

Plan for the Productivity Dip

Output drops after go-live. It always does. Programmes that pretend otherwise set expectations that break confidence when reality arrives. Plan capacity for it, communicate it in advance, and treat recovery time as a planned cost.

Define Success Beyond Go-Live

Go-live is not success. Success is measured months later: are people using the system as intended, has the spreadsheet population declined, is reporting trusted enough to make decisions on? Programmes that declare victory at launch rarely find out that they lost.