Predictive maintenance: what makes a project succeed, and what makes it fail
Promised returns are high, and so are abandonments. The real difficulties are rarely the model: they are the data, the integration and the decision that follows an alert.
Predictive maintenance — anticipating a failure rather than suffering it or preventing it at fixed intervals — is among the most cited applications of industrial IoT. Published field reports are mixed: some describe quick returns, others programs abandoned or with no measurable gain after eighteen months. Figures vary strongly by source and objectivity (many come from vendors); it is better to retain the causes of failure, which recur from one article to the next.
First trap: the data
Practitioners estimate that a very large share of the effort — around 70% in several accounts — goes into data engineering rather than the model. Sensors drift, readings have gaps and noise, units and timestamps are inconsistent across machines. These defects compound across a large fleet. A sophisticated model fed doubtful measurements produces doubtful alerts (SumatoSoft).
Second trap: the lack of failures
To learn to recognize a failure, a supervised model needs examples of failures. If a pump runs ten years before failing, there is very little failure data. In that case, it is better to start with anomaly detection — spotting what departs from normal behavior — and simple physical rules (vibration, temperature, current thresholds) before aiming at a fine prediction of remaining useful life.
Third trap: an alert with no decision
An alert has value only if someone can act on it in time: a part available, a stop that can be scheduled, a technician reachable. Failing projects produce alerts that nobody has the authority or time to handle, or too many false alerts that wear out the teams' trust. Integration with the CMMS (maintenance management system) and the production schedule matters as much as the model.
Fourth trap: scope
Instrumenting the whole estate "to see what happens" dilutes effort. The approach that holds is to start from a few critical assets — those whose stoppage costs most or poses a safety risk — demonstrate a gain there, then extend. Models need several months of operation to stabilize: the pilot must last long enough to be judged.
An approach that reduces risk
- Put a figure on the cost of a stoppage for the targeted asset: without that baseline, no return on investment can be shown.
- Audit existing data before buying anything: what controllers already measure, and with what quality.
- Start with anomalies and simple rules, add learning when the data warrants it.
- Define who does what when an alert fires, and measure the rate of useful alerts.
- Plan data-flow security from the start: the connected asset becomes a possible entry point (see our article on OT security).
Our view
Predictive maintenance is a business project before it is an AI project: understanding failure modes, how teams intervene and what an hour of downtime really costs. AI comes afterwards, on a clean data base, for a bounded use case.
Sources
Have an IoT project in mind?
Describe your context, we'll propose a tailored solution.