You Customised the ERP Until It Stopped Being an ERP

Three years ago, the ERP went live. It was a big decision — a serious budget, a respected implementation partner, a steering committee, a go-live party. Today, the vendor has quoted an upgrade that costs close to what the original implementation did. The IT head says two modules “can’t be touched” without breaking the invoicing. And finance still closes the month in Excel, because the reports the system produces don’t match the way the business actually reviews its numbers.

The software isn’t the problem. The software was fine. What happened is that the business spent three years teaching the system to behave like the old way of working — and succeeded.

How a standard system becomes a bespoke one

Nobody sets out to over-customise an ERP. It happens one reasonable request at a time.

Sales wants the quotation format to look exactly like the one customers are used to. Purchase wants a three-level approval because “that’s how we’ve always controlled spend.” The plant wants its own costing logic, because the standard one doesn’t reflect how the founder thinks about margins. Accounts wants a custom field for the thing the old accounting package used to track.

Each request is small. Each one has a sponsor senior enough to insist. And the implementation partner — who bills for customisation — has no reason to say no. By go-live, a system designed around best-practice processes has been rebuilt, piece by piece, around yours.

Every customisation is a decision about the past

Here is the uncomfortable truth: most ERP customisation is a vote to keep an existing process rather than examine it.

The standard workflow in a mature ERP is not arbitrary. It encodes how thousands of businesses in your industry handle procurement, inventory, billing and close. When your team finds that workflow “doesn’t fit,” there are two possibilities. Either your business is genuinely different in a way that creates competitive advantage — or your process has habits in it that nobody has questioned for a decade.

In our experience, it’s the second far more often than the first. The three-level approval exists because of a fraud incident in 2014. The custom costing exists because one partner never trusted standard costing. The special report exists because the MD likes to see things in a certain order.

None of these are strategy. They’re history. And customisation turns history into code.

What it actually costs

The costs arrive quietly, then all at once.

Upgrades become projects. Every customisation has to be retested, rewritten or re-bridged each time the vendor releases a new version. Businesses end up running software several versions behind, missing security patches and features they’ve already paid for through their licence fees.

The implementation partner becomes permanent. Only they understand the custom code. Your “system” is now a relationship you can’t exit.

Workarounds come back. When a customised process breaks — and eventually one will — the team routes around it in spreadsheets. Within a year, you’re paying for an ERP and running parts of the business outside it.

New hires can’t be productive quickly. Someone who has used the same ERP at three other companies arrives and finds a system they don’t recognise.

Why it keeps happening

Because ERP projects are run as technology projects, not operating-model projects. The steering committee asks “can the system do what we do?” — when the question that matters is “should we still be doing it this way?”

That second question is harder. It involves telling a senior leader their approval chain is unnecessary, or telling the founder that the way they’ve always read margins is misleading. IT teams and implementation partners are rarely in a position to have that conversation. So they build what they’re asked to build.

What actually fixes it

If you’re about to implement, adopt a simple default: standard first, and every deviation has to earn its place. A customisation request should come with a written case explaining what competitive advantage the non-standard process protects. If nobody can articulate one, the process changes — not the software.

If you’re already living with an over-customised system, don’t start with the technology. Start with an inventory. List every customisation, who asked for it, and what problem it solved. You’ll typically find a third are no longer used, a third could be replaced by standard functionality with a small process change, and a third are genuinely needed. Retire the first group, redesign the second, and protect the third.

Then put someone in charge of the process — not the system. A business owner, not an IT owner, who decides when the business adapts to the software and when the software adapts to the business.

The system was never meant to fit you

An ERP is not a mirror. It is a discipline. The point of buying one was to run the business on processes that scale — and that means the business has to change first.

Every time you customised the system instead of questioning the process, you bought comfort at the price of flexibility. The good news is the choice isn’t permanent. The same decisions that bent the system can be unwound — one honest question at a time.

If your ERP upgrade quote made you wince, the problem probably isn’t the vendor — it’s worth checking what you taught the system before it costs you another implementation. See how our Technology & Data practice works →