What an ERP consultant does — and what it costs to skip one

There is a stage every growing company reaches where improvisation stops working.

For years the business ran on memory and relationships. The warehouse manager knew what was on the shelf without counting. The owner knew who owed what without opening a ledger. Then the company doubled, and the same instincts started producing invoices nobody collected and stock nobody could find.

That is the moment somebody says: let us buy a system. And within a month, the same person says: how hard can it be, we will do it ourselves.

Why “we will do it ourselves” is the expensive option

The temptation is understandable. The software is available, the documentation is free, and there is somebody on staff who is good with computers.

What that reasoning misses is that installing an ERP is not a software task. It is a redesign of how the company works, performed on a company that has to keep trading while it happens.

The comparison that fits is not assembling furniture. It is heart surgery on a patient who is still walking around. The instruments are purchasable; the decision about where to cut is not.

The three jobs you are actually paying for

One: drawing the map

Before a single record is created, somebody has to trace the full journey of one order — from the moment a customer clicks buy to the moment the money settles in the bank.

Where does the request land. Who approves it. What triggers the picking note. When does the invoice post. Which account moves.

Most companies have never written this down. They have habits, and habits are not a process. The map is the deliverable that survives the project, and it is the reason the same consultant can spot, in the second week, that two departments have been counting the same revenue twice.

Two: telling the client the truth

A client says: our approval workflow requires four signatures.

The useful question in reply is not how do we build that. It is: is this a policy, or is it something somebody started doing five years ago that nobody has questioned since?

Roughly, the answer is the second more often than anyone expects. Automating a bad process makes it faster, not better — and the company then owns a system that enforces the habit permanently.

A consultant who only takes requirements is a stenographer. The value is in refusing to build the third and fourth signature until somebody can name what they are for.

Three: protecting the client from their own enthusiasm

Two failure modes appear on almost every project, and they pull in opposite directions.

The pull	What it looks like	What it costs
Buying features	A module bought because the demo was impressive	A licence line paid annually for a screen nobody opens
Starving training	Budget spent on software, nothing left for the team	A system that works and staff who do not use it

The second is the one that kills projects. A company will approve a six-figure licence and then argue over two days of user training — and then wonder why, four months later, half the team is still running the business out of a spreadsheet.

A consultant’s job includes saying no to the first and insisting on the second.

The bill when nobody says no

The fee looks like the expensive part until the alternative is itemised.

• Licences bought for the wrong scope. Modules that were never needed, paid for every renewal, and modules that were needed and left out, bought later at list price.
• A team that leaves. Staff put through a badly run implementation do not merely resent it; the good ones update their CVs. Replacing an experienced accountant costs more than the training that would have kept them.
• Data migration done twice. Opening balances loaded without reconciliation, discovered at the first close, corrected by re-doing the whole load — during month-end.
• The rebuild. A configuration nobody documented, maintained by whoever happened to build it, and rebuilt from scratch when that person leaves.

None of these appear in the quotation that was avoided. All of them appear in the following year’s accounts.

What to buy instead of software

Do not buy a product. Buy a plan.

The deliverable worth paying for is not an installed system — anybody can install a system. It is the document that says which processes change, in what order, who owns each one, and what the company stops doing.

Whoever hands you that has earned the fee before the first record is entered.

If you are earlier than this decision, start with what an ERP actually is and how the modules fit together. If you are choosing between products, the comparison is in ERP systems. If the project is already running and going badly, the pattern is usually one of the failures documented here.