Why Predictive Maintenance Is Still Failing to Deliver on Its Promise

The promise was always appealing

Predictive maintenance has been selling a wonderfully sensible idea for decades: monitor an asset, spot deterioration early, fix it at the right moment, and avoid the expensive drama of an unplanned failure. Nobody enjoys a 2 am call because a pump has stopped, least of all the person who has to find the pump, the spares cupboard and their will to live.

With cheaper sensors, cloud platforms and machine learning, that proposition became louder. Vendors began promising that AI could listen to motors, watch temperatures and practically sense a bearing's emotional state. Yet plenty of organisations have spent serious money on predictive maintenance and ended up with dashboards, alerts and no meaningful reduction in downtime.

The awkward truth is that predictive maintenance rarely fails because the algorithm was not sufficiently clever. It fails because the surrounding engineering and operational work was treated as an inconvenient detail.

Bad data is not a small problem

I have worked around temperature monitoring and IoT systems long enough to know that a measurement is only useful if you can explain where it came from, whether it is accurate and what it means in context. A sensor attached badly, placed in the wrong location or sampled at an unhelpful interval can produce impeccably formatted nonsense.

Take a refrigerated cabinet. A temperature probe near the evaporator may show sharp, regular swings that are entirely normal. A probe near a door may reveal staff behaviour, delivery patterns and the occasional determined shopper holding the door open while considering yoghurt. Neither is inherently wrong, but treating them as the same signal is how false alarms are born.

The same applies to vibration, current draw, pressure and acoustic data. Baselines shift with load, ambient conditions, product changes, maintenance interventions and age. If nobody records those changes, the model is asked to infer reality from a diary with most of the pages torn out.

Organisations also underestimate mundane data problems: missing timestamps, clock drift, swapped asset IDs, sensors that quietly go flat, and maintenance logs written as “fixed thing”. AI may be impressive, but it cannot reliably translate “made funny noise, sorted” into a labelled failure mode. Frankly, neither can most humans six months later.

Maintenance history is usually too weak for the ambition

Machine learning needs examples. To predict a particular failure, it needs good records of assets that exhibited relevant warning signs and then genuinely failed, ideally with a confirmed cause. Many sites do not have this.

They may have relatively few failures, which is good operationally but inconvenient for model training. Or they may replace components preventatively before failure, meaning the actual condition is unknown. Or their records may say a motor was changed without explaining whether the old motor had failed, was noisy, was replaced during a planned shutdown, or was simply nearby when someone had a spanner.

This creates a familiar trap. A supplier demonstrates a model trained on a broad industrial dataset. The customer expects it to understand their specific assets, operating regime and definition of failure on day one. It is a bit like expecting a satnav to navigate a factory after being shown a map of the country. Technically related, practically unhelpful.

An alert is not a maintenance process

Even a good prediction has to lead to action. This is where many deployments quietly expire.

Who receives the alert? Is it clear which asset is affected? Can they see the evidence? Is there a documented inspection task? Is the asset safe to inspect while running? Are the required parts available? Can the work be scheduled without disrupting production? Most importantly, does anyone have authority to decide that the alert warrants intervention?

If the answer is “it goes into a portal”, then the organisation has not implemented predictive maintenance. It has implemented an expensive electronic noticeboard.

Maintenance teams are rightly sceptical of alerts that cannot explain themselves. They already have planned work, statutory checks, breakdowns and the occasional priority-one email sent by somebody who believes all emails are priority one. Asking them to trust a black-box score without supporting evidence is not a change-management strategy.

The useful systems I have seen provide a trend, a comparison with normal operation, an indication of confidence and a practical recommendation. “Compressor current has risen 18% at comparable load over 21 days; inspect condenser cleanliness and fan operation” is actionable. “Anomaly score: 0.87” is a number in search of a purpose.

The economics are often hand-waved

Not every asset deserves predictive maintenance. That should be obvious, yet the industry has an unfortunate habit of attaching sensors to anything with a rotating part and a budget line.

For a cheap, easily replaced fan in a non-critical area, run-to-failure may be entirely rational. For a production bottleneck, a cold-chain asset protecting high-value stock, or a pump whose failure creates a safety risk, early warning can be extremely valuable.

The calculation should include sensor installation, connectivity, calibration, cybersecurity, platform fees, integration, training and the additional labour created by inspections. It should also account for the cost of false positives. Repeated unnecessary call-outs do not merely cost money; they teach people to ignore the system, which is rather like installing a smoke alarm that goes off whenever somebody makes toast.

Start with decisions, not technology

A better approach begins with a small number of painful, well-understood failure modes. Speak to the engineers who know which assets cause the most disruption. Review failure records, however imperfectly. Identify what can be measured reliably, what warning period is useful, and what action will follow.

Then pilot with disciplined instrumentation and feedback. Every alert should be reviewed: true issue, false alarm, missed event, unclear outcome. That feedback loop is where a model, and the trust around it, becomes better.

Predictive maintenance is not a magic layer sprinkled over neglected assets and chaotic work orders. It is a practical engineering capability built from credible measurements, sensible failure knowledge and maintenance teams given tools that respect their time. Get those foundations right and the clever bit of AI may finally have something useful to do.