AI Chatbot for ERP: What It Solves, What It Doesn't

The answer to “which customer did we deliver late to most this month?” is already sitting in the ERP. The problem is not that the answer is missing; it is that getting to it means knowing which screen, which filter and which report. People who don’t know ask a colleague who does, rather than asking the ERP.

AI assistants land squarely in that gap. But the same gap is where unconvincing demos come from: opening a chat window is easy, guaranteeing that the answer behind it is correct is not.

What an ERP chatbot actually is

It is a conversational layer over the ERP: it turns a plain-language question into queries the ERP already supports, and returns the answer together with its source.

Saying what it isn’t may be more useful. It is not a new database — the data stays in the ERP. It does not replace the ERP; records still live there. And it is not a “chat with your documents” tool: searching inside a PDF and reading a live stock balance are two entirely different jobs.

The three jobs it does in practice

1. Answering questions

This is the visible benefit. “How many boxes are left of lot 4521”, “which line scrapped the most last week”, “where do this customer’s open orders stand” — questions that meant navigating three separate screens collapse into one sentence.

The real gain here isn’t time, it’s access. The number of people who are entitled to ask these questions but don’t know how to drive the ERP is higher in every plant than anyone expects.

2. Drafting the entry

The second job matters more, because data entry is the part of any ERP that meets the most resistance. Someone writes in plain language — “log today’s production: lot 4522, 12,000 boxes, 2 scrapped” — and the assistant fills in the relevant form and shows a preview.

Here is the critical part: the record should reach the ERP only after the user approves it. Unattended writing buys speed at the cost of accountability. A wrong entry needs an owner.

3. Summarising without being asked

The third job runs with no question at all: stock risk each morning, lots nearing expiry, the gap between the production plan and the order load. Instead of waiting for someone to open and interpret a report, the place worth looking comes to you.

Under the hood

The most useful thing to know when evaluating these tools is that the model does not roam freely through your database.

In a properly built assistant, the model calls predefined queries — “get stock balance”, “create production entry”, “list open orders”. The model interprets the question and decides which query to run; the query itself is something you defined and can audit.

Three things follow from that:

• The numbers come from the ERP, not the model. A figure the model produced itself is a defect, not a feature.
• Permissions are inherited. A user must not see through the assistant what they cannot see in the ERP. Otherwise the chat window becomes a back door around an authorisation structure that took years to get right.
• Every action is logged — who approved what, and when.

What it does not solve

To be fair to the reader, the list of things an assistant cannot fix is not short either.

It will not clean up bad master data. If your stock cards are inconsistent, or the same material was opened under two codes, the assistant will hand you that mess faster and in a more confident tone of voice. That is all.

It will not define undefined business rules. If “delivery date” means two different things in two departments, the assistant cannot know which one you meant. What’s interesting is that these ambiguities usually surface while an assistant is being set up — because asking a machine a question forces you to ask it precisely.

It does not replace deep analysis. It is strong on questions with a single answer; a multi-dimensional cost study still needs a report and a human.

It will not improve a broken process. If production is logged in one batch at the end of the shift, the assistant makes that easier — it does not make the data real-time. That takes data from the floor.

Seven questions to ask a vendor

When a demo looks good, these are the questions that separate the tools:

1. Where did this number come from? Can the answer show which module and which record it came from?
2. Can it write without approval? If it can, can that be switched off?
3. Are permissions inherited from the ERP, or kept in a second list somewhere?
4. Is there an audit trail? Can you produce who approved what six months from now?
5. Where is the data processed? Do questions and records travel to a model abroad — under GDPR (and KVKK in Turkey), you want that answer in writing.
6. What is in scope? Stock, orders, production entries, accounts — which are read, which are written to?
7. What happens when it answers wrongly? Is the error rate measured, or left for users to notice?

The seventh is the one most often skipped. An accuracy rate nobody measures is an accuracy rate that does not exist.

Where it meets shopfloor data

The ERP knows what was planned and what was recorded; it does not know what happened on the floor. How long the stop actually lasted, which machine dragged the pace down, whether the shift will make its target — none of that is in the ERP, because factory data comes from somewhere else.

Join the two and the question changes: answering “can we make this order?” requires knowing both the open order load and the line’s real pace. OnoTwin Studio reads the floor live, while the ERP AI Assistant answers the same question from the ERP side.

Which side comes first depends on the plant’s digital maturity level. Where the ERP is orderly but the floor is blind, start on the floor; where data flows but nobody can drive the ERP, start the other way around.

Where to start

Trying to cover the whole ERP is the most common way these projects fail. What works is starting with one job: the transaction that repeats most, costs the most time, and has a measurable outcome. Production entry is usually a good candidate — it happens daily, everybody complains about it, and it can be timed.

Seeing it work on one transaction is both faster and cheaper than trying to cover everything from the start.

Tell us which ERP you run and which transaction eats the most of your time, and we’ll work out together whether the assistant makes sense for you — you can write to us from the contact page.