AI and ERP: it does not replace your system, it makes it queryable

Every so often the same headline comes round: artificial intelligence is going to kill the ERP. It is not going to happen, and understanding why is what tells you where the investment actually belongs.

An ERP is not intelligent and does not try to be. It is the financial and operational record of the company: what was bought, what was sold, what is in stock, what is owed. Its value lies in being a single consistent source. Replacing it with a probabilistic model would mean trading certainty for estimation in the one place you do not want to estimate.

What has changed is the layer above it. For twenty years, getting a number out of an ERP meant knowing how to navigate it. That requirement is disappearing, and that is where all the value is.

The bottleneck was never the system: it is access

In most mid-sized companies there are three or four people who know how to get information out of the ERP. Everyone else asks them by email or chat. Every query — however simple — routes through a busy person.

The cost of that is not the time of the person asking. It is that questions stop being asked. Nobody bothers finance to check a hunch, so small decisions get made from memory and large ones get made off last week’s report.

A conversational layer over the ERP removes that friction. The warehouse manager asks “how much of this product is committed for next week” and gets the answer, without opening the system or asking anyone to look it up.

It is not magic: it is a translated query. But once the wait disappears, so does the reason people stopped asking.

What kinds of questions it handles well

It is worth being precise about expectations, because half the disappointments start here.

It works well for: status and aggregation queries — how much, how many, since when, compared to what — searches across unstructured text such as notes or descriptions, summaries of a period, and anomaly detection along the lines of “what fell outside the normal range this month”.

It works badly for: anything that requires reconstructing a business rule that is not in the data. If real margin depends on a criterion that lives in the commercial director’s head and in no field anywhere, no model will deduce it.

It should not be used for: posting entries. Recording a movement, issuing a document, closing a period. All of that is deterministic and does not admit an approximate answer.

Holding that last line clearly is what separates a project that gets audited from one that presents well and nobody checks.

Why most of these projects fail

Because of the data, not the model.

If the same supplier is recorded as “Southern Distributors”, “South. Distrib. Ltd” and “SOUTHERN DISTRIBUTORS LTD”, no AI layer will give you a correct purchasing total. It will give you three partial totals, all delivered with the same confident tone.

That is the pattern that repeats: the conversation starts with the tool and ends with master data. Duplicate clients, uncategorised items, cost centres each department uses differently, free-text fields where someone typed whatever seemed right back in 2019.

The model cannot tell a bad record from a good one. It processes both with the same conviction, and that conviction is the problem.

A badly built report announces itself: the numbers do not add up and someone checks. A poorly grounded conversational answer sounds perfect. That is why messy data, which was merely an annoyance in the world of reports, becomes a risk in the world of AI.

The order that works

First, master data

Clients, suppliers, items, cost centres. Deduplicate, normalise and — most importantly — decide who owns each table.

Without an owner it is dirty again in three months. This is not a technical role: it is the person who decides whether “Southern Distributors” and “South. Distrib. Ltd” are the same entity, and who is allowed to create a new one.

Second, entry rules

If the mess came in through a free-text field, close it. Validation at the point of entry, pick-lists instead of text, mandatory where it matters.

Cleaning without fixing the source is an endless task. You will be deduplicating the same suppliers again next year.

Third, a small and measurable scope

One department and a handful of questions someone currently answers by hand. Note how long that took before you start.

That number is the only thing that later justifies widening the scope, and it is the one nobody records because it seems obvious at the time.

Fourth, traceability in every answer

Every answer has to be able to show where it came from: which table, which filter, which period. Ideally with a link through to the underlying query.

If it cannot be verified, nobody will make an important decision on it — and they would be right not to. Traceability is not a technical requirement, it is what turns the tool into something people actually use.

What cleaning up master data costs

This is the question that stalls these projects, and the answer is usually better than feared.

In a client or supplier base of moderate size, deduplication is largely automatic: the human work is the ambiguous cases, which are generally between five and ten per cent. What takes time is not the cleaning, it is the deciding — agreeing the criteria and getting someone to own them.

That is why it is worth treating the clean-up as a project in its own right, with its own return, rather than as a prerequisite for the AI project. Clean master data also fixes reporting, invoicing, and the decisions currently being made on numbers that do not reconcile. If the conversational layer never gets built, the work still paid off.

How to know whether you are ready

A quick test: ask for total purchases from your largest supplier for the last quarter, and ask for the same figure through a second route — accounting and the system, or two different departments.

If the two numbers match, your base is in shape and the AI layer will pay off quickly. If they do not, that is where the work is, and no tool will skip it for you.

That same clean-up is what makes it possible to delegate actions to an agent in the CRM, so it is not effort spent on a single front. And if the problem you have sits upstream of the ERP, it is worth placing it first with the nine diagnostic signs.