Skip to main content
ERP & Operations

Why 60% of ERP implementations disappoint — and the four things that prevent it

ERP projects rarely fail on technology. They fail on master data, undocumented process, absent sponsorship and a go-live date that was never realistic. Here is what we do differently.

3 min read940 views

We have implemented ERP for manufacturers, distributors and process industries for close to a decade. In that time we have also been called in to rescue perhaps twenty implementations that someone else started. The pattern is remarkably consistent, and it has almost nothing to do with the software.

Reason one: master data was treated as an afterthought

The single most reliable predictor of a difficult go-live is the state of the item master. We routinely receive extracts with the same physical part listed four times under different codes, units of measure recorded as "kg", "KG", "Kgs" and "kilogram", and 30% of items with no valid HSN code.

You cannot compute a meaningful stock valuation on that. You cannot run MRP on it. And every user who sees a wrong number in week one stops trusting the system permanently.

What we do: master data cleansing is a distinct, funded workstream that starts before configuration, with a named owner on the client side and a weekly quality score we both look at. We do not begin transaction migration until that score crosses an agreed threshold.

Reason two: the documented process is not the real process

Every organisation has an official procedure and an actual procedure. The gap between them is where implementations die.

The stated purchase process might be indent → approval → PO → GRN. The real one includes an urgent verbal order placed by the plant head on a Saturday, regularised with backdated paperwork on Monday. If your ERP has no answer for that, users will find a workaround, and your data integrity is gone within a month.

What we do: process study means sitting with the store keeper, the purchase executive and the accounts clerk for a full day each, watching what they actually do. We then design for the real path — including a documented emergency-procurement flow with the right approvals attached afterwards.

Reason three: sponsorship was delegated to IT

ERP changes how people work, which means it changes who has authority, whose numbers are visible, and who can no longer quietly adjust a figure. That is an organisational change, and an IT manager cannot enforce it however competent they are.

What we do: we will not start an implementation without an executive sponsor who chairs a monthly steering committee and is willing to say "this is how we will work now" in a room full of department heads. If nobody will take that role, the project is not ready.

Reason four: a big-bang date fixed before the scope was understood

"We will go live on 1 April" — decided in November, before process study, before anyone counted the interfaces. From that moment every decision is made under schedule pressure, and testing is the thing that gets compressed.

What we do: phase it. Finance and inventory first, then purchase and sales, then production, then HR and payroll. Each phase is genuinely live and stable before the next begins. Total elapsed time is often similar, but risk at each step is a fraction, and users learn one thing at a time.

What a well-run implementation looks like

PhaseDurationExit criteria
Process study & blueprint3–4 weeksSigned-off blueprint, gap list, phasing plan
Master data cleansingParallel, 4–8 weeksQuality score above agreed threshold
Configuration & gaps4–6 weeksConfigured system demonstrated against blueprint
Migration & UAT3–4 weeksReconciled balances, UAT sign-off by process owners
Parallel run1 accounting periodBoth systems reconcile within tolerance
Go-live & hypercare4 weeks on siteTicket volume stabilised, month-end closed in system

The uncomfortable questions to ask a vendor

  • How many days will your team spend on our shop floor before configuring anything?
  • Who owns master data cleansing, and what does the plan look like?
  • What happens if we fail UAT — who bears that cost?
  • Can I speak to a client whose implementation went badly, and hear how you handled it?

That last one tells you more than any reference call with a happy customer. Every experienced implementation partner has a difficult project. The ones worth hiring will tell you about it.

Found this useful?

Keep reading

Related articles

More from the blog

Other articles worth your time

Browse all

Free consultation

Have a system that needs this kind of thinking?

Tell us what you are working on. The first consultation is free, and you will speak to an engineer.