What is actually worth automating with AI in a factory

Most of what decides an AI project in a factory is not modelling. It is naming what kind of problem you have, checking whether your execution data can carry it, and designing what happens when the model is wrong.

Rules, machine learning, optimisation and language models: which fits which problem

Rules and statistics come first, and deserve more respect than they get. If a rule an engineer can write down gets most of the value, the honest comparison for any model is against that rule, not against doing nothing.

Machine learning earns its place where the relationship between inputs and outcome is real but nobody can write it down: dozens of process variables interacting, a defect that depends on material lot, ambient humidity and position in the cavity. It knows the conditions it was shown and says nothing useful about conditions it has never seen.

Optimisation is a different discipline and is routinely mislabelled as AI. Scheduling a finite-capacity plant, sequencing to minimise changeovers, assigning qualified operators: these are constraint problems with an objective function. They need no labelled examples, but they do need honest process times and constraints, which usually have to be measured rather than assumed. For planning, a solver that can express your real tooling and drying constraints is almost always the right tool, because planning is a constraint problem rather than a prediction problem.

Language models are the newest arrival and their fit is specific. They suit document and conversation shaped work: reading an incoming enquiry and drafting a structured one, condensing a long maintenance history into something a technician can read before walking to the machine, answering what a work instruction says about a setup. They are not measurement instruments: asking one to predict a bearing failure from vibration data is using a hammer on a screw.

What data an AI project in a factory actually needs

A model needs examples that pair a situation with an outcome, with enough context to tell one situation from another: a signal or set of conditions tied to an order, a machine, a tool, a material lot, an operator, and a timestamp that is true. The timestamp matters more than people expect. If confirmations are backfilled at the end of the shift, every event in that shift shares an approximate time, and anything depending on sequence or duration learns the data-entry habit rather than the process.

The outcome side is usually worse. Predictive maintenance needs failures recorded as failures, with a cause and a date, not as an unplanned stop with a blank reason field. Quality prediction needs scrap booked against the operation and the defect type that caused it, not aggregated into a monthly number. Forecasting needs consumption history that has not been silently rewritten by stock corrections. In most plants the inputs live in the historian and the outcomes live in a maintenance notebook or one person's spreadsheet.

The test is not how many gigabytes the historian holds, but whether you can pull, for one line and one product family, a year of rows where each row carries the conditions and the result, and two people who know the process agree the rows are true. If that extract takes a week of manual reconciliation, the model is not the project; the record is. This is why MES and historian data quality is the binding constraint, and no modelling sophistication recovers what was never captured.

Forecasting demand and consumption, where the payback is nearest

Forecasting usually has the shortest path to money, because the alternative is visibly weak: most plants take last year and add a percentage, or ask sales for a number that is really a target. A model using order history, seasonality, customer mix, open pipeline and calendar effects beats that on the items with regular, repeating demand. On intermittent and project-driven items, often most of the part numbers and a small share of the volume, it usually does not, and a naive or Croston-style baseline is hard to beat. The honest version segments the catalogue first and leaves those items to a stocking policy and judgement.

The value shows up downstream rather than in the forecast itself: safety stock moves, purchase timing on long lead items changes, and the emergency changeovers that wreck a schedule become rarer. A forecast accuracy percentage on a slide is not a benefit; inventory days and expedite count are.

Predictive maintenance, only where the failure mode is actually predictable

Everything here turns on whether the failure develops gradually and leaves a signature in something you can measure. Bearing degradation, imbalance, misalignment, progressive blockage in a filter or cooling circuit, drift in hydraulic pressure, motor current creeping up on the same operation: these develop over weeks or months, occasionally only hours, which is usually too late to be worth instrumenting, and show in vibration, current, temperature or pressure. A model can see them, and so, often, can a well-chosen threshold, which is why the comparison against simple statistics matters here.

A controller board dying, a tool snapped by a bad insert, damage from an operator error: these are effectively instantaneous, and no model predicts them from a trend that does not exist.

The second condition is that the warning must buy time you can use. If the part has a long lead time and the line cannot stop before the weekend, the investment that pays is a spares policy, not a model. Work out the intervention window before the sensor budget.

Quality prediction and scrap reduction

Quality is where the most money usually sits and where the data requirements are most demanding. The attractive version predicts, from conditions during the run, which parts or batches are at risk, so someone can adjust before the scrap is made rather than finding it at final inspection.

It works when the process is instrumented at the resolution of the thing you want to predict, and when scrap carries a real cause code against the operation. It fails quietly when scrap is booked at the end of the order against the order as a whole, because the model cannot then tell which conditions produced which failure.

One unglamorous step pays for itself before any model does: capturing scrap reasons at the machine, at the moment, from a short list of causes the operator recognises. Many plants that ask for quality prediction find from that data alone that a small number of causes account for most of the loss, and close the largest with an engineering change. That is a good outcome, not a failed project.

AI for production scheduling: why it is an optimisation problem, not a prediction one

If the plan slips every week, the cause is rarely a lack of intelligence and usually a lack of constraints. What changes it is a scheduler that respects shared tooling, changeover families, operator qualifications, curing times, and the maintenance windows you intend to keep.

Learning helps here in one narrow, real way: process times. A schedule built on standard times nobody has remeasured in years is precise about the wrong numbers, and actual durations captured through MES can update what the scheduler plans with. Judge a scheduling proposal on the constraints it can express and on how fast it re-plans when something breaks; a plan that takes overnight to regenerate gets overridden by hand in the morning meeting.

Anomaly detection on energy and process signals

Anomaly detection learns what normal looks like and flags deviation. It suits continuous signals where you have plenty of good behaviour and few labelled faults: energy draw per cycle, compressed air consumption, chiller performance, a process signal whose shape is stable when things are well.

Its strength is reacting to what nobody anticipated. Its weakness is that it says only that something is unusual, never what is wrong, and a plant receiving unexplained alerts learns to ignore them. The design work is not the detector but the routing: which alerts go to whom, what the first check is, and how the response is recorded so the next alert of the same shape arrives with history attached.

AI in sales and customer operations, where the work is document shaped

The commercial side of a manufacturing business runs on documents and conversations: enquiries, specifications, quotations, order confirmations, delivery queries, complaints. This is genuinely where language models fit, because the work is reading, extracting, drafting and summarising.

Concretely: an incoming enquiry parsed into part, quantity, requested date and special requirements, with previous quotations pulled up beside it. An email thread condensed into a CRM record carrying the commitment made and the next action.

Two rules keep this from going wrong. The model drafts and a person sends, at least until the error rate is understood in that workflow. And anything factual, price, lead time, stock, promised date, comes from the system of record rather than from the model, which should be quoting a looked-up value and never generating one. CRM automation that invents a lead time is worse than none, because it commits the company.

Sizing the prize before you buy anything

Name the loss in units your plant already tracks: scrap cost per month on the product family in question, unplanned downtime hours on the constraint machine multiplied by what an hour there is worth in contribution rather than machine rate, expedite freight, inventory tied up in the parts a forecast would move, hours a week spent retyping between systems.

Then estimate, pessimistically, what share of that loss the application could plausibly address. Predictive maintenance does not eliminate downtime; at best it converts some unplanned stops into planned ones, for the failure modes it covers. A quality model does not remove scrap; it shortens the time between a process going wrong and someone noticing it.

If that honest number, set against a total cost over the life you would actually plan for, including integration and the people who will run it, does not clear the hurdle your finance function applies to any other investment of that size, the project is a science experiment. That is allowed, but it should be funded and judged as one.

What integration really costs

The model is usually the cheap part; the cost lives in the seams. Getting signals off the machines comes first, and a real plant is a mixed estate: some assets speak OPC UA, some Modbus or a serial protocol, some offer a dry contact, and some closed controllers need a retrofit sensor on the spindle, the hydraulic circuit or the power line. Then the output has to land somewhere that causes an action: a screen an operator already looks at, a work order raised in maintenance, a constraint fed to the scheduler, a hold applied in quality.

After that comes the master data reconciliation nobody scopes. Part numbers differing by a suffix between systems, units of measure that do not match, a BOM maintained in two places, machine identifiers that changed when the line was rearranged. None of it is difficult and all of it takes longer than the software. A proposal that prices the model and leaves the seams as integration to be scoped is not a price.

Who operates the model, and what happens when it is wrong

Every deployed model needs an owner with a name, and the procurement question is who in your organisation that will be. That person needs to know what it was trained on, which conditions fall outside that, why it produced a given output, and how to take it out of the loop without stopping production. A model that stops answering must fall back to whatever controlled the process before it, the sampling plan, the threshold, the operator check, and not to an open gate or a blocked line. Decide which of those it is before go-live.

Explainability is not a philosophical concern on a shop floor, it is an adoption requirement. A recommendation that says which signal moved, by how much, and against what baseline, gets acted on. A score with no reasoning gets overridden, and once overriding is routine the system is decoration.

Over-alerting destroys trust faster than missed detections do, for the same reason over-rejection does on an inspection station: a false alarm is visible immediately and to everyone, a miss stays invisible until the failure arrives. Design the alert rate around the attention actually available on the floor, and route the uncertain band to a person, not to the line.

Governance, drift and the maintenance burden nobody budgets

A model is a snapshot of your process at the moment it was trained, and your process moves: a new supplier, a tool refurbishment, a part revision, a line rearrangement, a changed product mix, a sensor replaced with a slightly different one. Each can shift the inputs enough that yesterday's model is quietly wrong today, and the failure mode is not an error message but gradually worse advice.

Monitor the inputs as well as the outputs, because input drift shows before outcome degradation does. Keep a held-back test set of real cases, borderline ones included, so a new model can be compared honestly with the current one. Version the model and record which version produced which recommendation; after a retrain, yesterday's outputs came from a different judge.

And budget the ongoing effort. A model in production is a maintained asset, closer to process equipment than to a purchased report. If nobody has time allocated to retraining, reviewing alerts and checking that the data still arrives, it will degrade until people stop using it.

A realistic first project, with acceptance criteria

Pick one named loss on one line or one product family, stated as a sentence with a number in it: we scrap this much on this operation, we lose this many constraint hours to this machine, we hold this much stock because we cannot forecast this family. If the project cannot be stated that way, it is not ready.

Before buying anything, do the data extract. One year, one line, conditions and outcomes in the same rows, two people who know the process confirming the rows are true. Then benchmark against the simple alternative: a threshold, a control chart, or the current planner's judgement.

Write the acceptance criteria in plant units before go-live, in pairs so the trade-off is explicit. For predictive maintenance, a stated number of covered failure modes caught with at least a week of warning, against a capped number of false alerts per month. For forecasting, a stated reduction in inventory days on the modelled families with no increase in stockouts. For quality, a stated reduction in scrap on the target operation against the same months last year, with the process changes recorded alongside.

Name the owner, the failure behaviour and the retraining schedule in the same document, and set a review date with an honest option to stop. A first project that ends in a decision not to expand, made on evidence, is a success. A pilot that becomes a permanent demonstration is not.

Where Meta Smart Factory fits

Meta Smart Factory is modular, and that matters here because the AI and machine learning module sits on top of the execution layer rather than beside it. MES supplies the events and context, IIoT connectivity and OPC UA supply the machine signals, Quality supplies scrap with causes, Maintenance supplies failure history, and APS consumes the output where the answer is a schedule rather than a prediction.

You can start with one module against one named constraint and add the next once the first is in use. What no platform removes is the hard part: agreeing what the numbers mean, getting causes captured at the machine, and deciding who owns a model when it is wrong. Talking through that sequencing for a specific plant is a more useful first conversation than a demonstration, because a demonstration will always work.