The model works, the demo convinces, and then nothing happens. The cause almost always sits upstream of the algorithm.
Predictive maintenance is the most heavily sold and least widely deployed promise of the connected factory. Pilots often succeed; roll-outs rarely do. The reasons come down to three points, and none of them is technical.
Unusable failure history
A predictive model learns from past failures that are correctly dated and classified. Yet in most CMMS systems the work order is entered three days late, the failure code is left at its default, and the real cause stays in the technician's head.
So before adding instrumentation, we make capture reliable: fewer codes, better defined, entered at the time of the intervention. Six months of clean data beats three years of doubtful data.
No action planned behind the alert
A predictive alert announces a likely failure in ten to fifteen days. If the maintenance planning process cannot insert an intervention into that window, the alert becomes noise. The project then fails for organisational reasons, not modelling ones.
A scope chosen for technical convenience
Teams often instrument the equipment that is easiest to fit, not the one whose downtime costs most. The demonstrated gain stays marginal, and the extension case never clears the investment committee.
Choose the equipment by the cost of its downtime, not by how easy the sensor is to fit.
Three steps, in order
We recommend a slower and far safer path: make capture reliable and compute MTBF and MTTR, then move to condition-based monitoring on a few simple, well-understood quantities, and only then introduce statistical models. Each step produces a measurable gain and funds the next one.
Back to the blog