The bottom line
Predictive maintenance works - but not the way most vendors demo it. The 30–50% downtime reduction figures are real, but they require clean sensor data, a properly labelled failure history, and the operational discipline to act on alerts before the machine trips. Most pilots fail not because the AI model is wrong, but because the data foundation under it is broken. Fix the data layer first. The model comes second.
In This Article
What Vendors Show vs. What Happens on the Shop Floor
The vendor demonstration looks compelling: vibration sensor data feeds into a machine learning model that predicts a bearing failure three weeks in advance. Maintenance is scheduled. Downtime is avoided. Everyone wins.
What the demonstration does not show is the 18 months of labelled failure history the model was trained on, the fact that the asset in the demo has a well-documented failure mode, and that the integration between the IoT platform and the CMMS was built specifically for the pitch. On most shop floors, none of those conditions exist.
This is not a criticism of predictive maintenance as a discipline. It works. But it works under specific conditions that vendors are not incentivised to discuss, and most buyers are not equipped to probe. The result is a lot of failed implementations and a growing scepticism about AI in manufacturing that is holding the industry back.
The question to ask any PdM vendor is not "what does your model predict?" - it is "what labelled failure data did you train it on, and where did it come from?"
Why Most PdM Pilots Fail
In our experience across manufacturing clients in the GCC and North America, PdM pilot failures cluster around three root causes. First: insufficient historical failure data. A model cannot learn to predict failure if it has never seen labelled examples of failure. Most industrial assets have maintenance logs - but those logs are in CMMS text fields, not structured training data.
Second: wrong asset selection. Vendors pitch PdM on the most instrumented, most visible assets - not the ones where a failure causes the most damage. The most complex asset to model is rarely the most valuable to predict.
Third: broken CMMS integration. Predicting a failure is only useful if a work order gets created and the right parts are available when the technician arrives. Without tight integration to the maintenance management system, a prediction is just an alert that gets ignored.
Three Things That Actually Determine Success
The first determinant is data quality, not model sophistication. A simple threshold model on clean vibration and temperature data consistently outperforms a sophisticated ML model on messy, inconsistently labelled sensor feeds. Start with data quality. The model can evolve. The data cannot be retroactively cleaned if it was never captured correctly.
The second is CMMS integration from day one. The predictive model is the start of a workflow, not the end of one. If the prediction does not flow automatically into a work order with the right failure code, asset history, and parts recommendation, the operational value is zero regardless of model accuracy.
The third is organisational buy-in from maintenance teams before the technology is deployed. The best PdM system in the world fails if the maintenance technician does not trust it. Early involvement, transparent model logic, and a clear escalation path when predictions do not match experience are non-negotiable.
A simple threshold model on clean sensor data outperforms a complex ML model on dirty data - every time. Solve the data problem before the model problem.
Asset Selection: Start Here, Not There
The right starting point for a PdM programme is a maintenance cost analysis, not a sensor availability inventory. Identify the three to five assets where unplanned failure has caused the most downtime or production loss over the past 24 months. Those are your first targets - regardless of how well instrumented they are.
If those assets are not yet instrumented, the first phase of the programme is sensor deployment and data collection - not modelling. Trying to shortcut this phase by modelling assets with existing sensors rather than high-cost failure assets is the single most common mistake in PdM implementation.
Once the highest-impact assets are identified, the next question is failure mode specificity. Different failure modes on the same asset may require completely different sensor types and modelling approaches. A bearing failure requires vibration monitoring at specific frequencies. Thermal degradation requires IR or thermocouple data. Mapping failure modes to sensor requirements is step one of any serious PdM architecture.
Building a PdM Programme That Delivers
A PdM programme that delivers ROI within 6–18 months has four layers: sensor and data collection (OPC-UA or MQTT from PLCs, installed vibration/temperature sensors), a streaming data pipeline into a governed historian or data platform, a model layer (starting simple - threshold models and anomaly detection before ML), and a CMMS integration layer that converts predictions to work orders.
The mistake most organisations make is starting at layer three - buying an AI platform - before layers one and two are reliable. If the sensor data is inconsistent, the AI platform will produce inconsistent predictions. The investment is wasted, the maintenance team loses confidence, and the programme stalls.
Start with one asset group. Prove the full loop from sensor to work order. Measure the reduction in unplanned downtime over 90 days. Then scale. The temptation to deploy broadly and quickly is the enemy of a PdM programme that actually lands.
Predictive maintenance works. The programmes that deliver the 15–25% downtime reduction have one thing in common: they started with sensor coverage and clean data, not with models. Build the foundation first and the model follows naturally. Skip it and you'll spend 18 months demonstrating a pilot that never scales.