Why ERP implementations fail in Indian SMEs

When an ERP project fails, the post-mortem usually blames the software. Occasionally that is fair. Far more often the same product is running well somewhere else in the same city.

The differences are almost always in how the project was run — and the failure modes repeat with remarkable consistency.

1. Nobody inside the company owned it

This is the single strongest predictor. An ERP implementation needs someone in the business who can decide how a process should work, and who has the standing to make that decision hold.

Where the project is delegated entirely to the vendor, every decision that requires internal authority stalls, and the vendor either waits or guesses. Both are bad. Waiting kills the timeline; guessing produces a system that matches nobody's process.

The owner does not need to be technical. They need to know how the business actually runs and be senior enough that their answer is final.

2. The scope was described by department, not by workflow

"We need accounts, stores and production" is not a scope. It is a list of modules.

What matters is the handover points: what happens when material moves from stores to production, who records it, what document is raised. Failures cluster at those boundaries, because that is where two departments have to agree — and where each assumed the other was handling it.

A scope described as workflows surfaces those disagreements during design, when they are cheap. A scope described as modules surfaces them at go-live, when they are not.

3. The data was worse than anyone admitted

Every business believes its master data is roughly fine. Almost none are.

Duplicate items under three spellings, customers with old addresses, stock figures that have not been physically verified in years, opening balances that do not tie. None of it matters while the data lives in separate registers that nobody reconciles. All of it matters the moment one system holds all of it.

Migrating bad data does not fix it. It publishes it — and then users conclude the new system is wrong, which is the point at which adoption fails.

The uncomfortable but correct sequence is to clean before you migrate, and to accept that this takes longer than anyone wants.

4. Training was treated as an event

A two-day session before go-live is not training. It is a demonstration.

People learn a system by using it on their own work, with someone available when they get stuck. Where training is a one-off, the first difficult transaction after go-live gets handled the old way — on paper, in a side sheet — and the parallel system begins. Once a parallel system exists, the ERP is holding partial data, which makes its reports wrong, which justifies the parallel system.

That loop is very hard to break afterwards. It is much easier not to start it.

5. Go-live was scheduled for a convenient date rather than a quiet one

Going live on the first of the financial year is tidy and is usually a mistake. It puts your riskiest week on top of your busiest.

A quiet period gives the team room to be slow while they learn. A busy one guarantees they revert to what is fast, which is whatever they did before.

6. Customisation started before the standard system was used

Requests to customise almost always arrive before anyone has run a full cycle on the standard configuration. Many of them turn out to be unnecessary once people understand the tool; some turn out to be genuinely required.

Building them all up front costs money, delays go-live, and complicates every future upgrade — for features that may not be needed. Running standard for one full cycle first is uncomfortable and almost always cheaper.

What a project that works looks like

• One internal owner with authority, named before the project starts
• Scope written as workflows and handover points, not module names
• Data cleaned before migration, with someone accountable for each master
• Training on real work, with support for the first few weeks — not a session
• Go-live in a quiet period, with a defined fallback if something breaks
• Standard configuration first; customisation after one full cycle

What to ask a prospective partner

1. Who from your side is on this project, and are they the people who will support it afterwards?
2. What do you need from us, and by when? A partner who cannot answer this has not planned the project.
3. What happens if data cleaning takes longer than expected?
4. What does support look like in the first month after go-live specifically?

A partner who only wants to talk about features has not thought about delivery — and delivery is where these projects are decided.

If you would like to talk through your own rollout, see how we run implementations or book a consultation.