Natural language replaced the ERP consultant — mostly

The ERP consultant did four jobs. AI has taken one and a half of them, and the one it took was the most expensive. That is the whole story, but the details decide whether you still need to hire one.

The four jobs

Strip away the job title and a good implementation consultant was doing these things:

1. Translation. Sitting in a room, listening to how your business actually works, and converting that into the vendor's data model — this becomes a custom field, that becomes a workflow state, this exception becomes a conditional rule.
2. Configuration. Building it. The actual clicking, scripting and testing.
3. Advice. Telling you your process was daft, and that the other eleven companies they had done this for handled it differently and better.
4. Politics. Getting the branch manager who hates the project to go along with it.

Jobs 1 and 2 were the bulk of the invoice. They are also the two that AI has largely absorbed.

Why translation was ever a job

This is worth dwelling on, because if you never lived it, the value is invisible.

A traditional ERP has a fixed data model. Your business does not fit it — nobody's does. So the gap has to be closed by somebody who is fluent in both languages: yours ("we don't invoice until the supervisor signs the job sheet") and the software's ("that's a custom status with a validation rule and a role-based permission on the transition").

That bilingual person was rare and therefore expensive. And because they were expensive, you rationed access to them, which meant you batched up requirements, which meant a blueprint phase, which meant a long project. The entire eighteen-month shape grew out of translation being scarce.

Language models are, definitionally, good at translation. Point one at "we don't invoice until the supervisor signs the job sheet" and you get the status, the rule and the permission. That is not the AI being clever. That is the AI doing the thing it is fundamentally built to do.

The scarce resource stopped being scarce. Everything downstream changed shape.

What AI took

Translation: almost entirely. If you can describe your process in plain language, you no longer need someone to convert it. This is the single biggest cost line to disappear from ERP projects.

Configuration: almost entirely. The clicking is gone. Describing a purchase-approval flow and receiving a working one is a minutes-long operation that used to be a work package with a day rate on it.

Advice: partially, and this is the interesting one. A model has read more about business process than any consultant has lived. Ask it how other distributors handle consignment stock and you will get a competent answer. What it cannot do is know that your warehouse manager has a workaround that everyone depends on and nobody documented. Generic best practice: solved. Situated judgement: not.

Politics: not at all. Obviously.

What is left, and who does it now

Three things did not move, and they are the three things that decide whether your project works.

Deciding what you actually want

AI removed the cost of building the wrong thing. It did not remove the cost of not knowing what you want.

This catches people out constantly. "Build me an inventory system" produces something generic and disappointing, and the disappointment gets blamed on the AI. But the failure happened earlier: nobody had decided what the system was for. A consultant used to absorb this by interrogating you for a fortnight. Now nobody does, unless you do it yourself.

The skill that matters is no longer knowing the software. It is being able to describe your own process precisely — and most organisations are much worse at this than they think. The tell is when two people from the same department describe the same workflow differently. That happens in almost every project, and no model resolves it.

Data

Your fifteen years of records are messy in ways specific to you. Three customer records for the same company. A notes field holding payment terms. Product codes that changed meaning in 2018.

AI helps with mapping. It does not tell you which duplicate customer is real. Only your team knows, and only by looking. This remains the most reliable way to blow a timeline.

Judgement about what should not be automated

Someone has to look at a proposed automation and say "no — a person signs that". That is not a technical call and it is not a preference. On anything touching money, regulators, or safety, human sign-off is the price of admission, as we argue in AI in accounts payable.

So should you still hire one?

Sometimes. But for a different job, and for less time.

You probably do not need a consultant to build it. That was the expensive part and it is gone. Paying day rates for configuration in 2026 is paying for a solved problem.

You might well want one to think with. Someone who has seen forty implementations knows which of your requirements will quietly wreck you in month four. That is pattern recognition across many businesses, and it is genuinely valuable — but it is a few days of work, not a few months.

You will want specialist help for specific things. A gnarly integration with a legacy system. A migration of a decade of records. An unusual costing method. These are still real work.

The honest shape now is a few days of experienced advice up front, your own people describing and building, and specialist help on the two or three things that are genuinely hard. That is a different order of magnitude to a traditional engagement.

Which is why we sell developer time by the day rather than by the project. If you need three days, buy three days. The model where you buy a year because the vendor's data model does not fit you was a consequence of the translation problem, and the translation problem is over.

The uncomfortable bit

Consultants were not the problem. They were a symptom — of software rigid enough to need professional interpreters standing between you and it.

The interesting question is not "are consultants obsolete?" It is "why did business software ever need a translation industry?" The answer is that the data model was fixed and yours was not, so somebody had to negotiate between them, forever, at an hourly rate.

Remove the fixed model and the negotiation stops being necessary. The industry that grew in that gap shrinks accordingly — not because the people were not good, but because the gap they filled has closed.

Common questions

Do I still need to hire an ERP consultant?

Sometimes, but for a different job and for far less time. You probably do not need one to build it — that was the expensive part and it is gone. You might well want one to think with, because someone who has seen forty implementations knows which of your requirements will quietly wreck you in month four. That is a few days of work, plus specialist help on the two or three genuinely hard things.

Which parts of the consultant's job did AI actually take?

Translation and configuration, almost entirely, and those were the bulk of the invoice. Translation meant converting "we don't invoice until the supervisor signs the job sheet" into a status, a rule and a permission, and language models are definitionally good at translation. Configuration meant the clicking, scripting and testing. Advice went partially: generic best practice is solved, situated judgement is not. Politics did not move at all.

Why were traditional ERP projects so long in the first place?

Because closing the gap between how your business worked and a fixed data model needed someone fluent in both languages, and that person was rare and therefore expensive. Because they were expensive, you rationed access to them, so you batched up requirements, which meant a blueprint phase, which meant a long project. The whole eighteen-month shape grew out of translation being scarce.

If AI can build it, why do implementations still go wrong?

Because AI removed the cost of building the wrong thing, not the cost of not knowing what you want. "Build me an inventory system" produces something generic and disappointing, and the failure is usually blamed on the tool when it happened earlier, when nobody decided what the system was for. Two other things did not move: your messy records, where only your team knows which duplicate customer is real, and deciding what should not be automated.

More on that architecture in what is an AI-native ERP, and the method in Vibe ERP explained. Or see the AI builder.