Why ERP and system replacements fail in manufacturing

Six-figure implementations that stall are common enough in this region to be unremarkable. The failure pattern is consistent, and it is not really about software.

The failure is structural, not technical

Almost every failed replacement follows the same shape. The new system is specified up front in a long document, built or configured over many months, and then cut over in one weekend. Everything nobody thought to mention surfaces at once, in production, with orders waiting.

That is not a technology problem. It is a bet placed on the assumption that a specification written a year earlier captured how the plant actually runs. It never does — because much of how a plant runs lives in the heads of people who have done it for twenty years and do not think of it as information.

The spreadsheets are evidence, not a nuisance

Every plant has shadow spreadsheets running alongside the official system. It is tempting to treat these as bad habits to be eliminated by the new system.

They are actually the most valuable documentation in the building. Each one exists because the official system could not do something someone needed. A replacement that does not account for every one of them will produce a new generation of spreadsheets within a year.

Why the sunk cost keeps growing

By the time a replacement is visibly in trouble, a great deal has been spent and several people have staked their credibility on it. The rational move is to stop; the organisational move is to add scope and push the date.

This is why failed implementations are usually expensive rather than cheap. The cost is not the first mistake, it is the eighteen months of not admitting it.

What works instead

Replace one function at a time, running alongside the old system rather than instead of it. Receiving, or labels, or scheduling — whichever hurts most. Each piece goes live on its own and proves itself in production before the next one starts.

A wrong assumption then costs a week rather than a year, and there is never a point where the only way out is forward. The legacy system keeps running until the last thing it does has somewhere else to live, and it gets switched off quietly rather than dramatically.

Why this is affordable now when it wasn't

These projects were priced in the hundreds of thousands because they needed large teams for long periods, and most of that work was mechanical — data models, screens, integrations, migrations. That portion compresses dramatically with current tooling.

What does not compress is understanding your process and modelling it correctly, which is where the time should have been going all along.

Recognise any of this?

Describe it in a few sentences and we will tell you what it would take — or that it is not worth doing, which happens more often than you would expect.

Start a conversation