Predictive maintenance: from sensor to the alert someone actually acts on
Why most predictive maintenance pilots don't survive past month six — and what changes when the alert is designed together with operations.
Almost every predictive maintenance pilot gets the statistics right and the organization wrong. The model detects the anomaly, nobody acts, and by the next quarter the project loses its sponsor.
What to measure first
Start with critical assets that have a known, progressive failure mode. Motors, gearboxes, pumps, and compressors give measurable signals:
- Vibration (RMS and spectrum) — misalignment, imbalance, looseness, bearing wear
- Bearing temperature — friction and lubrication
- Motor current — abnormal load
- Differential pressure — clogging and wear
Assets with sudden failure and no physical precursor are not good candidates: for those, redundancy is cheaper than a model.
From anomaly to named failure
A generic anomaly detector produces alerts that are true and useless: "something changed." Operations needs something actionable.
Anomaly detected → ignored
Coupling-side bearing with
growing energy at BPFO
for 9 days → work orderThe way forward is combining statistical detection with diagnostic rules derived from the failure mode. The model says *when*; reliability engineering says *what*.
Choosing the model based on available data
| Situation | Approach |
|---|---|
| No labeled failure history | adaptive thresholds and novelty detection |
| Few labeled failures | classification with data augmentation and temporal validation |
| Rich, seasonal history | remaining useful life prediction with per-asset validation |
Always validate with a temporal split, never random sampling: predicting the past from the future inflates any metric.
Design the alert with the people who will act on it
A useful alert states four things: the asset, the symptom, the recommended intervention window, and the confidence level. And it arrives on the channel maintenance already works in — the work order, not a dashboard nobody opens.
Agree before the pilot starts: what false-positive rate is acceptable, who triages, and what happens when an alert is ignored and the failure occurs.
Measure the program's outcome, not the model's
Accuracy doesn't pay the bills. Track avoided unplanned downtime, hours of unavailability, corrective maintenance cost, and alert-response rate. That last metric is what predicts whether the program survives.
Conclusion
Predictive maintenance is a reliability problem with a data component, not the other way around. Well-chosen sensors, named diagnostics, alerts integrated into the workflow, and program-level metrics — in that order.