Every ERP now demos a chat box. Then someone asks a real question in the language the business actually speaks, and the trouble starts: terms that resolve to no field, answers that change between runs, clean tables built on the wrong question. The fix is not a better chat window - it is the semantic layer nobody shipped.
Ask the ERP a question in the words the business actually uses. Get the correct answer. Ask the same question again tomorrow and get the same answer - with no pre-built query behind it, no report request, no analyst in the loop.
That is the whole ask. It sounds modest. Most chat-over-ERP stacks cannot do it.
Heard from the leader of an ERP-improvement team at an enterprise coatings and specialty-chemicals maker, after hands-on experimentation with a chat-over-ERP stack left the team frustrated. We are documenting demand here, not deployments.
Wiring a language model to an ERP and getting a demo to work takes a weekend. Getting the same right answer twice is a different job entirely. Three failure modes do the damage:
Terms like a company-specific material category exist in people’s heads, not as a field, value or label anywhere in the ERP. The system has nothing to bind them to, so it has to be re-taught on every single query.
When a term does not resolve, these systems group by whatever field happens to be populated and joinable, and return clean output to the wrong question. Nothing flags the error. The table looks right. That is the trust-killer.
Teams respond by pre-building the insights the chat was supposed to generate on demand. That works - and it is just BI with a chat skin. The maze of static reports survives, now with a friendlier front door.
The root cause underneath all three is a missing semantic layer. Decades-old ERP data models are close to worst-case input for text-to-SQL: cryptic table and field names, meaning buried in classifications and custom fields, ERP/SAP vocabulary that only a handful of veterans can read fluently. The real product is the semantic layer. The chat window is a detail.
Directional, because your numbers are your numbers. The cost pools are the same wherever we hear this ask:
Every question needs a human translator between business language and ERP tables, and the translation costs planner and analyst time on both sides of the conversation.
The ERP takes the question in the words the business already speaks. Both sides of the translation get their hours back.
A question becomes a ticket, the ticket becomes a report, and the report arrives after the decision was made.
The ERP answers directly, so the loop has nothing left to route. Answers stop arriving after the decisions they were meant to inform.
The first confidently-wrong answer ends adoption - quietly and permanently. Nothing flags the error; the table just looks right.
The same question gets the same right answer tomorrow. Correct and repeatable is what keeps the tool in use - which is why determinism is not a nice-to-have.
Because the ERP cannot answer ad hoc questions, teams build and maintain a second landscape of pre-built dashboards to compensate.
The ERP answers directly and the compensating estate stops growing. The maze of static reports finally loses its reason to exist.
Two engines run in production today - Analytical Lab Reports and account Knowledge Twins. Everything else on this map is an extension on the same foundation.
This entry maps to a Knowledge Twin scoped to your ERP's material and consumption vocabulary. The hyper-contextualization work - teaching the system what your categories, classifications and custom fields actually mean - is precisely the semantic layer the chat-over-ERP stacks are missing. And "same question, same answer, twice" is an acceptance test we welcome.
How a Knowledge Twin worksThe owners of the ERP estate - the people who field the requests and know exactly why the chat demos stalled.
The people asking about consumption, coverage and movement - today through tickets, analysts and patience.
The team that runs whatever gets chosen, and would strongly prefer it to be governable, testable and inside the boundary.
The whole thing runs inside your boundary: your infrastructure, your choice of models, your economics. The vocabulary map you build stays your asset - you keep the freedom to swap models and move workloads underneath it without losing what you taught it.
Back to the AI ROI MapBring a question your ERP could not answer in plain language - your vocabulary, your data. Ask it twice and see if the answers agree. We would rather be tested than believed.
On-prem. Your data never leaves your boundary.