Unplanned downtime is one of the most expensive things that can happen to an operation. A pump that fails on a Tuesday morning costs more than the pump: the line stops, crews are pulled off other work, and customers wait. Fixed maintenance schedules were the answer for decades, but they replace parts too early on one machine and too late on the next.
Predictive maintenance promises something better: service equipment when the data says it is needed, not when the calendar says so. Yet a lot of pilots stall after the first dashboard. More often than not, that is not because of the model. It is because of the choices made before and after it.
Start with the failure, not the sensor
The most common mistake is to start from the data that happens to be available and look for patterns in it. Start from one failure that hurts instead. Pick one asset class where breakdowns are costly and happen often enough to learn from, and answer two questions before anything is built:
- What exactly counts as a failure? A trip, a breakdown, a part replaced outside the schedule? The definition determines your labels.
- How much warning is useful? A warning two hours ahead needs different data and a different model than a warning three weeks ahead, when a planner can still order parts and schedule a crew.
The data is usually already there
Most organisations already collect what a first model needs. It is just spread over systems that were never meant to be combined:
- Sensor data from SCADA, PLCs or IoT gateways: vibration, temperature, pressure, current, run hours.
- Maintenance history from the CMMS or ERP: work orders, replaced parts, downtime records.
- Operating context: load, shifts, product type, weather for outdoor assets.
The real work is joining these sources: aligning timestamps, and turning years of work orders into labelled failure events. Work orders are messy free text ("bearing noise, replaced, see previous"), and this is where language models earn their keep. They can classify thousands of maintenance notes into failure modes in hours, work that would otherwise take a reliability engineer weeks.
Pick the approach that fits your failure history
There is no single predictive maintenance model. The right approach depends mostly on how many failures you have on record:
- Few recorded failures: use anomaly detection. The model learns what normal behaviour looks like for each asset and flags deviations, without needing failure labels. This is the same principle we used to make an unlabelled medical imaging archive searchable: let the model learn structure from the data itself.
- A solid failure history: train a supervised model that predicts the probability of failure within a time window, or the remaining useful life of a component. Gradient-boosted models on well-engineered features are often hard to beat here; sequence models help when the shape of the signal over time matters.
Whatever the approach, always compare it with a simple baseline: the current schedule or a fixed threshold. If the model cannot clearly beat that, it should not go live.
Measure what the planner cares about
Accuracy is the wrong headline number. Failures are rare, so a model that never raises an alarm scores high accuracy and is useless. The metrics that matter on the floor are:
- Alert precision: how many alerts turn out to be real. False alarms destroy trust faster than anything else.
- Lead time: how far ahead of the failure the warning comes.
- Missed failures: what still slips through.
Evaluate on time: train on the past and test on a later period, never on a random split, or the model quietly learns from the future. And keep monitoring after go-live: sensors get replaced, recalibrated or moved, and operating regimes change. A model that is not watched will drift.
Put the prediction where the work happens
An alert on a dashboard that nobody opens changes nothing. The prediction has to land in the process that already exists. In practice that means a proposed work order in the CMMS, with the evidence attached: which signal deviates, by how much, and which past failures looked similar. The planner decides; the system prepares.
This is where predictive models and agent workflows meet. The model predicts, an agent prepares the work order and checks parts availability, and a person approves. Every decision stays traceable.
A realistic first step
Start with one asset class and its history. Prove on a backtest whether the warnings come early enough and precise enough to act on. Then run the model in shadow mode next to the current maintenance schedule, so the team can see what it would have flagged before anyone acts on it. Only when the predictions hold up in shadow mode does it make sense to change how maintenance is planned.
That route is slower than a flashy pilot, but it ends with a model the maintenance team actually trusts, and that is the only kind that reduces downtime.