Every industrial company I talk to is asking the same question right now, and most of them are getting the same unhelpful answer: a chatbot.
The chatbot is not the problem. The problem is that “what can AI do for us?” is too broad a question to produce a good decision. It invites vendors to demo whatever they have, and it invites internal teams to start with the technology instead of the work. Six months later there is a proof of concept nobody uses, and a leadership team that has quietly concluded AI is overhyped.
There is a narrower question that consistently produces better answers.
Start with decisions, not technology
Ignore AI for a moment and look at where your business actually loses time. In most ERP-driven operations I have worked with, it is rarely the dramatic things. It is this:
- A planner re-reads the same three reports every morning to decide what to prioritize, and the decision is different each time only in small ways.
- A sales admin manually retypes dealer orders from email and WhatsApp into the ERP, because the dealer will not use the portal.
- Someone reconciles what the ERP says against what the warehouse says, and investigates only the differences — a job that is 90% mechanical and 10% judgement.
- A customer service rep searches past tickets for how a similar issue was solved, because the answer exists but is not indexed anywhere useful.
None of these look like AI problems. All of them are, because each one is a decision that is slow, repetitive, and documented — three properties that together define where current AI tooling actually works.
The three-property test
Before any pilot, apply this filter to the candidate process.
Slow. The decision takes meaningful human time per instance. If someone spends four hours a week on it, automating it is not worth the integration cost. If four people spend a day a week on it, it is worth a serious look.
Repetitive. The same shape of decision recurs. AI systems are pattern machines; they are useful when the pattern is stable and the exceptions are identifiable as exceptions. A process that is genuinely different every single time is a poor first candidate, no matter how painful it is.
Documented. There is a record you can learn from — historical transactions, past tickets, previous quotes, archived correspondence. This is the constraint that kills most industrial AI projects, and it is worth being blunt about it: if the knowledge lives only in the head of one person who has been there eighteen years, you have a knowledge-capture problem, not an AI problem. Solve that first. It is cheaper.
Score candidate processes against all three. The ones that pass all three are your shortlist, and it will be shorter than you expect.
Why ERP data makes this easier than it looks
Companies with a mature ERP have an underrated advantage: the data is already structured, already has referential integrity, and already has an audit trail.
I have watched teams spend months building AI features on top of scraped spreadsheets and email exports when the same information existed as clean, transactional tables in the ERP they already pay for. The unglamorous move is to check what the ERP already knows before reaching for anything new.
Concretely, an ERP gives you three things that are hard to buy:
- A ground truth. When the model’s output disagrees with the ERP, you can tell. Systems without a system of record cannot be evaluated, and systems that cannot be evaluated cannot be trusted in production.
- History to learn from. Years of transactions are a labelled dataset you did not have to collect.
- A place to put the output. A recommendation that lands inside the workflow someone already uses gets adopted. One that lands in a separate dashboard gets ignored after week two.
That last point matters more than most technology decisions. The failure mode of industrial AI is almost never model quality. It is distribution.
Where the value actually shows up
Across manufacturing, distribution, and after-sales operations, the same handful of use cases keep appearing — because they are the ones that pass the three-property test.
Document and order intake. Turning unstructured inbound text — purchase orders, dealer emails, service requests — into validated ERP records. The AI handles the extraction; the ERP handles validation, business rules, and the audit trail. This is usually the highest-return starting point because the manual work is obvious, measurable, and universally disliked.
Retrieval over institutional knowledge. Question answering across service manuals, past tickets, contracts, and internal procedures. The critical design decision is not which model to use — it is insisting that every answer cites its source. An uncited answer is a liability in any regulated or warranty-bound industry.
Anomaly and exception triage. Not prediction, just prioritization. Instead of a human scanning every line for the one that matters, the system surfaces the twenty that deviate. The human still decides. This framing is what makes the project defensible to an operations manager who does not trust automation.
Forecasting with guardrails. Demand, spare parts, service load. AI is genuinely useful here, and genuinely dangerous when treated as an oracle. The reliable pattern is a forecast plus explicit uncertainty, reviewed by a human who owns the number.
Note what is absent from that list: fully autonomous decision-making. Every one of these keeps a human in the loop at the point where the decision has real consequences. That is not a temporary limitation to be engineered away. It is the design that survives an audit.
The industries differ in context, not in pattern
Automotive, utilities, oil and gas, and government all show up in my own project history, and the AI patterns above recur in each. What changes is the context around them.
In an automotive dealer network, for example, the friction is distributed: orders arrive from many independent businesses with different levels of process discipline, so intake quality varies wildly and exception handling dominates. In a utility, the friction concentrates in billing accuracy and regulatory traceability, so verification and auditability matter more than speed. In government, procurement and accountability rules constrain what can be automated at all.
The underlying question — which decision is slow, repetitive, and documented? — is the same everywhere. Which is exactly why you should resist starting from an industry-specific AI product and start from your own process map instead.
A first step that costs almost nothing
You do not need a budget to begin. Take one week and do this:
- List the ten most frequently repeated manual decisions in your operation.
- Score each on slow / repetitive / documented.
- Take the one that scores highest and, before touching AI, verify the data actually exists and is accessible.
- Define what a good answer looks like, and how you would know if the system got it wrong.
- Only now, choose a tool.
Step four is the one teams skip, and it is the one that determines whether the project is still alive in a year. If you cannot describe what a wrong answer looks like, you cannot evaluate a system, and you will end up shipping a demo.
What I would tell a hesitant leadership team
AI in an industrial setting is not a moonshot, and it is not a chatbot. It is a narrow, boring, measurable improvement to a process that already annoys everyone — validated against a system of record, with a human accountable for the outcome.
Start there. The ambitious projects are much easier to justify once you have one unarguable result and a team that has learned how to evaluate these systems on something that did not matter very much.
Anna Nurhayanto has spent 25+ years delivering enterprise systems — ERP (Odoo) implementation, automotive dealer systems, and system integration — and works on practical AI/LLM application in industrial operations. This article reflects experience across manufacturing, distribution, utilities, and government projects; it deliberately avoids product recommendations.