AI in the plant, without the hype. Where it pays off today.

There is an old lean principle that applies to AI just as much as to any software system: if you automate a bad process, you get bad results faster. Before you introduce a tool, it must be clear what the process is supposed to deliver, where it is stuck today and why.

In practice that means: first map the value stream in the office. How many handovers does a customer order pass through between receipt and release to production? Where does it sit without anyone working on it? Which information is entered more than once? Only once you can answer these questions do you know whether AI is the right means at all, or whether a clear responsibility and a clean standard already solve the problem.

I have seen plants that wanted to evaluate AI-supported order entry. The value stream mapping showed that the orders were not sitting for a long time because of the entry, but because of a release loop across three departments. The tool would have accelerated the wrong step.

In my experience, the tasks suited to getting started share three characteristics: they are recurring, they are based on text or documents, and a person checks the result anyway. Typical examples from plant and office:

• Pre-sorting incoming customer enquiries and orders and preparing the relevant data for order entry before a clerk releases them.
• Matching supplier confirmations and invoices against the purchase order and flagging deviations, instead of checking every line by hand.
• Summarising complaints and service reports and assigning them to the right department.
• Bringing work instructions, inspection plans and training documents from existing documents into a uniform, understandable form.
• Structuring minutes from shopfloor meetings and interface rounds so that open points do not get lost.

What they all have in common: the person remains responsible, the tool takes the preparatory work off their hands. That lowers the risk, and it makes the change comprehensible for those involved. They see immediately what the tool does and what it does not.

I am equally clear about where I currently advise against it. First, anything that intervenes directly in production control without a person in between: automatic rescheduling of orders, autonomous adjustment of machine parameters, unauthorised releases. Here the damage from an error is too great, and traceability is missing.

Second, processes that are not yet stable within the company itself. If three clerks handle the same transaction in three different ways, no tool has a foundation. First the standard, then the support.

Third, anywhere employees get the impression that the tool is being introduced to replace or monitor them. That is not a technical issue but a change issue, and it decides more about success or failure than the quality of the software. A tool that people reject gets bypassed. And bypassed tools create duplicate work, not relief.

An example from a plant with a large order processing department: the management team wanted to introduce a tool that automatically reads incoming purchase orders. Technically that was quickly implemented. In the department, however, the worry circulated that half the jobs would disappear. The clerks double- and triple-checked every suggestion the tool made, corrected things that were not wrong, and reported errors constantly. Within a short time the tool was considered unusable.

The fault did not lie in the technology. It lay in the fact that nobody had talked to the team about what would happen with the time freed up. When plant management made clear that the time should flow into order clarification with customers, an area that was chronically neglected, the mood turned.

That is why I treat every AI introduction as a change initiative: explain the purpose, involve those affected early, take fears seriously, small steps, visible results. The methods are the same as for any process change. Only the expectations are higher and the uncertainty greater.

My approach to AI in business processes hardly differs from my approach to other improvements, and that is deliberate.

• Map the value stream in the office: handovers, waiting times, media breaks, multiple entries. From that it emerges whether and where a tool helps.
• Choose a single use case that is recurring, based on documents and where a person checks the result.
• Design the procedure with the team that operates the process every day: what does the tool do, what does the person do, who intervenes when something is not right?
• Define a limited period in which the tool runs in parallel with the existing procedure, and evaluate honestly afterwards.
• Only after a visible result, tackle the next use case.

What I deliberately leave out: large strategy papers, roadmaps spanning several years, tenders for platforms. That can come later. At the start, a plant needs experience, not architecture.

Before you approve an AI initiative, it is worth taking a brief look at a few questions. If you cannot answer one of them, that is not a reason to stop, but a reason to start there first.

• Which problem in the process are we solving, and how will those involved notice that it is solved?
• Is the process stable enough today for a tool to build on it?
• Who checks the results, and who decides in case of doubt?
• Which data leaves the company, and is that compatible with our rules and those of our customers?
• What happens with the time that is freed up, and do those affected know that?

The last question is the one that most often remains open. And it is the one that decides most about success or failure.