info@innovquant.com Indore, Madhya Pradesh, India

Why ERP implementations run late, and what actually helps

InnovQuant,

ERP projects have a reputation for overrunning, and the usual explanation is that the software is complicated. In our experience the software is the predictable part. Three other things cause most of the delay.

The data is worse than anyone admits

Every organisation believes its master data is broadly fine. It generally is not. Duplicate customers, items with three naming conventions, historical records that were valid under a process nobody follows any more.

None of this is a crisis, but it has to be found and fixed, and the only reliable way to find it is to attempt a real migration early. Run one in week two against a copy, not in month five against the real thing. A failed trial migration is cheap; a failed go-live is not.

Nobody is empowered to decide

An implementation generates a steady stream of questions that are not technical: should this approval route through finance or operations? Do we keep the exception we built for one customer in 2019?

If every one of those goes to a committee, the project runs at the speed of the meeting schedule. The single highest-value thing a client can do is name one person who can make process decisions without escalating, and give them the authority to do it.

Training is treated as the last task

Training scheduled for the fortnight before go-live is where projects quietly fail. People go back to the spreadsheet they trust, the data in the new system goes stale, and within a quarter the organisation is running two systems badly.

Get real users into a working environment early, with their own data, while there is still time to change the system in response to what they find. Their objections in month two are information. In month eight they are a crisis.

What actually helps

  • Migrate early and repeatedly. Treat the migration as a script you run weekly, not an event.
  • Name a decision-maker. One person, with authority, available weekly.
  • Phase the rollout. One department or one site first. A smaller first go-live teaches you the same lessons at a fraction of the cost.
  • Keep customisation honest. Every customisation is a thing you own forever, including through upgrades. Change the process where you reasonably can.

None of this is exotic. It is simply that the common causes of delay are organisational rather than technical, which means they are not fixed by the implementation partner working harder.

Let's talk about what you want to build

Tell us what it is. Someone who can actually answer will reply, usually within a working day.