Why ERP Implementations Fail (and How Not to Be One)

ERP implementations rarely fail because of the software. They fail from dirty data, absent sponsorship and staff who quietly keep their spreadsheets. The three real causes, and how to avoid each.

We are called into more failed ERP implementations than successful ones, because nobody calls a consultant when it is going well. Across those engagements, a pattern is unmistakable: the software is almost never the reason.

The platform is usually adequate. The vendor is usually competent. The project still failed, and it failed for one of three reasons — occasionally all three, which is when a business ends up running the new system and the old spreadsheets side by side for two years while pretending the project succeeded.

Cause one: the data was dirty, and nobody reconciled it

This is the leading cause, and the least discussed, because it is not anybody's exciting job.

Migration is presented as a technical task: extract from the old system, transform, load into the new one. That framing is wrong, and the framing is the failure. The technical work is a fraction of the effort. The real work is the reconciliation, and it is a business exercise, not a developer's.

What you discover when you actually do it: three departments maintain three different customer lists, and they disagree. Opening balances do not tie to your last audited accounts. Product codes changed in 2023 and the historical records were never updated. There are duplicate suppliers with slightly different names. Stock on the system has not matched stock on the shelf since a stocktake nobody remembers.

Migrate that faithfully and you have launched an expensive new system that produces numbers nobody trusts. And once your finance manager does not trust the general ledger, the system is dead. They will keep their own spreadsheet, quietly, and it will become the real source of truth. You have now paid for two systems.

The fix is unglamorous. Migrate early rather than at the end. Reconcile opening balances against audited accounts before go-live, not after. Put people who know the business on the reconciliation, not developers who know the database. And run the old and new systems in parallel through at least one full month-end close, because the errors surface at close and nowhere else.

Cause two: training was a demo, so staff kept their spreadsheets

The second cause is that the system went live and the people did not.

Training is budgeted as a two-hour session near the end of the project, in which someone demonstrates the software. Demonstration is not training. Nobody learned to use a system by watching someone else use it, any more than anybody learned to drive from the passenger seat.

What happens next is quiet and terminal. Staff carry on doing the work the way they know how, in the spreadsheets they trust, and enter data into the ERP afterwards because they have been told to. The ERP becomes a reporting obligation rather than a working tool. Its data is always slightly stale and slightly wrong, which confirms everyone's suspicion that it cannot be trusted, which entrenches the spreadsheets.

The fix is to train champions inside each department, weeks before go-live, and let them train their colleagues. People accept a new system from a peer who does their job and has already made it work. They resist it from a consultant who will leave in a month. Give the champions time — real, protected, scheduled time — and give them influence over configuration, so the system reflects how the work is actually done.

Cause three: nobody senior owned it, so process disputes never resolved

An ERP forces decisions that a business has spent years avoiding.

Two departments define a "customer" differently. Sales and finance disagree about when revenue is recognised. Operations wants stock allocated at order, finance wants it at dispatch. In the spreadsheet era these disagreements were survivable, because each department kept its own numbers and nobody reconciled them in public.

A single shared database makes that impossible. Somebody must decide. And the decision is not technical — it is a business decision with a winner and a loser, and consultants cannot make it for you. Neither can the IT manager, who has no authority over how finance recognises revenue.

If no executive owns the project, these disputes escalate to nobody and simply stall. The project slips, blame accrues to the software, and eventually the sponsor's attention moves elsewhere. We now insist on a named executive sponsor with genuine authority before beginning, and we have declined engagements where nobody would take the role. That is not fussiness. It is a reliable predictor.

The pattern beneath all three

Every one of these causes is organisational, and every one is discovered late — after the money is committed, when changing course is expensive and admitting the problem is politically difficult.

Which is why we phase implementations by module rather than attempting a single switchover. Finance and inventory first, then payroll, then the rest. Each phase delivers standalone value. Each phase contains the blast radius when something goes wrong. And a stalled phase does not strand the entire investment.

Big-bang go-lives are chosen for schedule reasons and regretted for operational ones. There is no prize for switching everything on at once, and the cost of getting it wrong is that your business cannot invoice anybody on Monday.

Before you sign anything

Insist on a fit-gap analysis before purchase, not after. Document how each core process genuinely works today — including the informal workarounds nobody has written down, because that is precisely where the gaps hide. A vendor demonstration is not a fit-gap analysis; it is a sales meeting.

Name your executive sponsor. Budget for your own people's time, which appears in no proposal and is frequently the largest cost. Start the data reconciliation before you think you need to.

And ask the vendor one question: what does it cost to leave, and can we export our data in a usable form? The reaction tells you more than the answer.

Frequently asked questions

What is the single most common reason ERP implementations fail?

Dirty data migrated without reconciliation. The new system launches with balances that do not tie to the audited accounts and customer records that disagree between departments. Once the finance team stops trusting the general ledger, they keep a parallel spreadsheet, and that spreadsheet quietly becomes the real source of truth. The organisation has then paid for a system it does not use. Migrating early and reconciling opening balances before go-live prevents it, but the work must be done by people who know the business rather than by developers.

Is it the software vendor's fault when an ERP project fails?

Usually not, though they are the easiest party to blame. The three causes we see repeatedly — dirty data, inadequate training, and absent executive sponsorship to resolve process disputes — are all organisational, and none can be fixed by a vendor. A vendor can and should warn you about all three. The ones who do not are worth avoiding, but selecting a different platform will not save a project that has none of the above addressed.

Should we go live with all modules at once?

No. Phase by module — typically finance and inventory first, then payroll, then the remainder. Each phase delivers value on its own, contains the damage if something goes wrong, and lets staff absorb one change before the next. Big-bang go-lives are chosen for scheduling convenience and regretted operationally, because when they fail, the business cannot invoice anyone on Monday morning. Keep the legacy system available as a fallback until the new one has survived a full close.

How much of our own team's time will an ERP implementation take?

Considerably more than any proposal states, because that cost is not billable and so nobody quotes it. Your finance manager, operations lead and the people who know why things are done a particular way will spend real days in discovery workshops, validating migrated data, testing workflows and learning the system — on top of their existing jobs. Plan for it explicitly, or it will be taken from somewhere else, usually from the same people at month-end.

Why does an ERP force us to change our processes?

Because a single shared database cannot hold two definitions of the same thing. When finance and sales define a customer differently, or disagree about when revenue is recognised, spreadsheets let both survive independently. An ERP does not. Somebody must decide, and it is a business decision with a winner and a loser — which is why a named executive sponsor with real authority is not a formality. Without one, these disputes stall the project and the software takes the blame.