Why ERP rollouts fail, and how to phase one that sticks

ERP projects rarely fail technically. The software installs, the modules work, the data loads. They fail when, six months after go-live, half the organisation is still running the spreadsheet they used before — and now the company is paying for both.

That outcome has causes, and almost all of them are decided before a line of configuration is written.

Cause one: the system encodes a process the business doesn't follow

Every ERP ships with an opinion about how purchasing, inventory and approvals should work. Those opinions are usually sensible. They are also usually not what your business does — often for good reasons that nobody wrote down.

Two ways this goes wrong. Either the implementation forces the vendor's process onto the team, who quietly route around it; or it faithfully reproduces every existing quirk, including the ones that were workarounds for a system being replaced.

The distinction that matters is between a quirk that reflects a real business constraint and one that reflects an old tool's limitation. That's not a technical judgement — it needs someone who knows why the process is the way it is, in the room, during design.

Cause two: the big-bang cutover

Everything goes live on the first of the month. Every department learns a new system simultaneously. Every problem surfaces at once, into a support function that has never run this system before.

Even when it technically works, the experience is bad enough to poison adoption. People form their opinion of the system in the first fortnight, and that fortnight is chaos by design.

Phased rollout, module by module, is slower on paper and faster in practice:

1. Start with the module that hurts most — usually inventory or sales. The team feels the benefit immediately, which buys patience for what follows.
2. Let it run for a month. Real usage surfaces the configuration mistakes. Fix them while the blast radius is one module.
3. Add the next module. The team now knows the interface, the navigation and the support route. Each subsequent module is easier than the one before.
4. Retire the old system per module, not all at once. Parallel running for one module is manageable; for eight it is not.

Cause three: nobody owns the data

Master data — customers, suppliers, products, chart of accounts — is where ERP implementations quietly go wrong. It arrives from several sources, in several formats, with duplicates, inconsistent naming and no agreed authority.

If nobody owns it, everybody edits it. Within months you have four spellings of the same supplier and reports that nobody trusts. Once reports aren't trusted, people rebuild them in Excel, and the ERP is now a very expensive data entry system.

Name a data owner per domain before migration. Give them the authority to say no. Do the deduplication before load, not after — cleaning live transactional data is dramatically harder than cleaning a spreadsheet.

Cause four: training treated as an event

A two-day session a fortnight before go-live, covering every module, for everyone. By the time people need the knowledge they've lost it, and the person who could answer is dealing with forty other questions.

What works better:

• Role-based, not system-based. A warehouse operator needs their four screens, not a tour of the finance module.
• Just in time. Train each module immediately before it goes live, not all of it up front.
• Super-users per department. One person who learns deeply and answers day-to-day questions locally. This single measure reduces support load more than anything else we've tried.
• Short written guides with screenshots, kept where people work. Nobody watches a forty-minute video while a customer waits.

Cause five: customisation without a boundary

Every ERP project accumulates requests. Some are essential; many are preference. Without a decision rule, the ones that get built are the ones from whoever asks loudest.

A rule we use: a customisation must either be legally required, remove a measurable amount of manual work, or unblock a process that genuinely cannot proceed. "It's how we've always seen it" doesn't qualify — it goes on a list, and gets revisited after three months of live use. Most items never come back.

The reason to be strict isn't purity. Every customisation is code you own forever, that must be retested on every upgrade, and that the next implementer will not understand.

What good looks like at go-live

Not "everything works". Realistically:

• One module live, in daily use, with the old process switched off for that module.
• Master data for that module cleaned, deduplicated and owned by a named person.
• A super-user in each affected department who can answer most questions locally.
• A known list of open issues, prioritised, with owners — not a claim that there are none.
• Reports that finance and operations have both checked against a known-good period.

That last point catches more problems than anything else. Run the new system's reports against a month you already have verified numbers for. If they don't match, you have a configuration or data issue — and you'd much rather find it in a comparison than in a board pack.

On compliance modules

Statutory requirements — e-invoicing, tax reporting, audit trails — deserve separate mention because they fail differently. A normal ERP bug creates inconvenience. A compliance bug creates a filing problem with a deadline attached.

Build these with the assumption that the government endpoint will be slow, will reject valid-looking submissions, and will time out ambiguously. That means queued submission with bounded retries, idempotency so a retry can't create a duplicate filing, a reconciliation sweep for anything left uncertain, and a permanent record of every attempt.

We've written up exactly this pattern in the FBR digital invoicing case study — the failure handling is the bulk of the work, and it's the part that gets underestimated every time.

The honest summary

An ERP rollout is an organisational change project with a software component, not the reverse. The technical work is well understood; the failure modes are all human — process mismatch, cutover shock, unowned data, misplaced training and unbounded customisation.

Sequence it so the team feels a benefit in month two rather than month twelve, and the rest becomes much more manageable. Ask for everything at once and you'll get the spreadsheets back.