AI in manufacturing

Why AI in manufacturing starts in the office, not on the floor

AI is sold to manufacturers from the shop-floor side: vision-based quality control, failure prediction, process-parameter optimisation. Those projects can be valuable, but each has its own precondition, which we check before starting. Vision-based control needs labelled examples of defective images, process optimisation needs a history of parameters and outcomes, and failure prediction needs a recorded history of failures together with the signals that preceded them, large enough for a model to have anything to learn from. That last one is the one most often missing, so the project starts with data collection, not a model.

Meanwhile, in the same company, a stream of work flows every day that AI can take over now: customer orders in a dozen formats retyped by hand into the ERP (the business management system that handles orders, stock and accounting), complaints that require assembling documentation from three places, breakdown reports living on paper and in emails, shift reports compiled from spreadsheets. These are document- and text-based processes — the data exists, the rules can be written down, and a mistake is detectable and reversible.

That is why a good first AI project in a manufacturing company looks unspectacular: it does not touch the machines, it touches the flow of information around them. In return, the first results appear within weeks, which helps fund the next steps.

What we actually automate in manufacturing companies

• Order and specification handling. Reading orders arriving by email and as PDFs — in layouts nobody has described before — and preparing the ERP entry for a person to approve. This is the most common first process: it recurs daily, and order confirmation adds a second checkpoint. In the pilot we measure both the accuracy of the entries and the time needed to check them.
• Complaints and non-conformities. Classifying the report, assembling the quality documentation from systems and scans, drafting the response for approval. It shortens handling time where today the longest part is not the decision but gathering the material for it.
• Maintenance. Consolidating breakdown reports into one register, and an assistant that answers technicians’ questions from the machine manuals and repair history — instead of searching through binders. This is not failure prediction; it is the precondition for it ever being possible, because it builds the data history.
• Production reporting. Collecting shift data from spreadsheets and systems into one report, with gaps and outliers flagged for explanation — instead of assembling the same thing by hand every week.
• Preparing data for planning. Unifying demand and stock data for the planner. Forecasts, yes — but only once the input data is complete; a forecast on patchy data is a number generator.

The common denominator: a person approves the output, the system prepares it. Which processes qualify for this kind of automation at all — the five conditions a good candidate must meet — is set out on our AI automation page; in a manufacturing company those conditions are checked in exactly the same way.

What we do not promise

• Failure prediction without a data history. A model learns from the runs that preceded failures. If the plant does not record them, an honest offer starts with data collection — and says plainly that the predictive result comes later. Whether a plant has anything to predict from can be checked in one afternoon: we set out the five questions in the piece on predictive maintenance.
• Vision-based quality control “on the side”. That is a separate project with cameras, lighting and a station — with its own budget and schedule. It can be done well, but not as an add-on to document automation.
• Optimising “the whole plant”. We automate specific processes, with a number measured before the start. A project without that number has no way to show it paid off.

How we work

As in every project: we pick one process and measure one indicator before we start. Then we run the smallest possible pilot. Before switching over, the system runs alongside the current way of working for a while. The system prepares, a person approves every output, and the decision to loosen oversight is made on pilot data, not on enthusiasm. The full course — four phases and what you receive at the end of each — is set out in our implementation methodology, and the full scope of the service, from process audit through to upkeep, on our AI implementation page.

A separate subject that comes up in every manufacturing conversation is confidentiality: technical drawings, price lists, customer data. Where data goes when we integrate an AI model, and what to ask any supplier, is set out on our security and GDPR page.

What it costs

Three things drive the cost: the number of systems to connect, the state of the data, and how reliable the results must be, that is, how rarely they may be wrong. The size of the plant barely matters — what matters is whether the process lives in one ERP or in the emails and scans beside it. All the components, upkeep included, are broken down in our note on what an AI implementation costs.

Frequently asked questions

Where should a manufacturing company start with AI?

With the office processes around production, not with the shop floor. Order handling, complaints, quality documentation and maintenance requests are document- and text-based processes — the data already exists, a mistake is reversible, and results show in weeks. Shop-floor projects — vision-based quality control, predictive maintenance — need recorded machine signals, and separate infrastructure to archive them wherever nothing does so today, so they cost more and take longer. Starting with them is the most common way manufacturing companies spend their budget before seeing a first result.

Does AI in manufacturing require new sensors or equipment?

Not at the start. Most first projects we run in manufacturing companies work on data that already exists: customer orders, specifications, quality records, breakdown reports and ERP data. Recorded machine data is needed only for predicting failures (predictive maintenance) and analysing process parameters. The controllers and supervisory systems a plant already has (PLC, SCADA) often provide it, provided somebody records the readings for each machine. Missing records usually do not mean a missing sensor. The controller usually knows the current value but nobody stores it, the archive does not reach far enough back, or it covers only the whole line. That is a matter of setting up data collection and storage, not buying hardware. New sensors are bought only where nothing measures the parameter you need, where a different parameter is measured, or where readings are taken too rarely to catch the type of fault in question. Either way, you first need a history with enough failures of that type for an AI model to learn from. If somebody proposes failure prediction without asking about your machine data history, they are proposing a data-collection project, not an AI project.

Is our ERP data enough?

That is exactly the question the audit at the start of a project settles — and you can partly settle it yourself in one afternoon: try to export the last hundred instances of the process you want to improve from your ERP as a single table. If you can, the first stage is small. If part of the data lives in mailboxes, scans and spreadsheets beside the system — and in manufacturing companies it usually does — then tidying that flow is the first stage of the project, not an obstacle to it.

What does an AI implementation cost in a manufacturing company?

Cost is driven by the number of systems to connect, the state of the data, and how reliable the results must be, that is, how rarely they may be wrong — not by the size of the plant. An order-handling process with data in one ERP is a matter of weeks; the same process scattered across emails, scans and two systems is a different project and a different quote. Upkeep is a separate line: per-operation fees and periodic retesting after model version changes. We break the components down in our note on what an AI implementation costs.

What about the confidentiality of technical drawings and customer data?

That has to be settled before the project, not after it. When we integrate an AI model, you can control which data leaves the company at all, where it goes and on what basis — from the choice of provider and processing region to limiting the data to the minimum the process needs. The principles we apply, and the questions worth asking any supplier, are set out on our security and GDPR page.