I have now seen enough predictive maintenance deployments in South African plants to be reasonably confident about which ones will work within the first two hours of a site visit. It has almost nothing to do with the algorithm.
The question I ask is simple: show me the last twenty work orders closed on this asset. If the failure codes are blank, or everything is coded "breakdown — other", the model has nothing to learn from and the project will quietly die in month eight.
What the technology is genuinely good at
Three things, reliably.
Detecting drift in continuous signals earlier than a human reviewing periodic readings. Vibration on a critical pump set, motor current signature, bearing temperature trends, dissolved gas ratios in transformer oil. A model watching a signal every minute will flag a slope change weeks before a monthly walkdown does.
Combining signals that a human would not naturally read together. Discharge pressure falling slightly while motor current rises slightly is unremarkable in isolation on both counts, and together it is an impeller wear signature. This is where machine learning earns its place.
Prioritising a maintenance backlog. Less glamorous, high value. Most plants I visit have a backlog they cannot execute in full. Ranking it by modelled probability of failure and consequence is a better allocation than ranking it by the date it was raised.
Where it fails
Data quality is the first killer, and it is usually not the sensors. It is the maintenance history. A model that predicts failure needs labelled failures. If your CMMS records that a pump was "repaired" in 2023 without recording what failed and why, you have no training data, only noise.
The second killer is the response loop. I worked with a smelter that had a genuinely good anomaly detection system running on its fan drives. It generated a valid warning eleven days before a gearbox failure. Nobody acted on it, because the alert went to an email address, not into the planning cycle, and the planner had no authority to move a scheduled job on the strength of it. The failure cost them a four-day outage. The system had done its job perfectly.
The third is confidence calibration. Early deployments generate false positives while the model learns. If the first three alerts are wrong and there is no agreed protocol for how the team responds to an unconfirmed alert, credibility is gone and no amount of subsequent accuracy recovers it. Agree up front what an alert triggers: usually an inspection task, not an intervention.
The sequence that works
Start with criticality. Model the assets whose failure actually hurts — the ones where an unplanned stop costs production, not the ones where instrumentation happens to be easy.
Fix failure coding before you fix anything else. Six months of disciplined failure coding is worth more than any vendor platform, and it produces value on its own because it tells you where your losses actually are.
Then define the decision the model must support, and who makes it. "Should we bring this bearing change into the next planned window?" is a decision with an owner. "Give us insights into asset health" is not.
Finally, run the model alongside the existing regime for a full cycle before you change any maintenance strategy on the strength of it.
What this means for the people
The role that changes most is the planner's. Planning shifts from calendar-driven to condition-driven, which requires the planner to interpret probability rather than read a schedule. That is a real skills change and it is usually under-resourced in these projects.
The role that does not disappear is the experienced technician's. Every well-run deployment I have seen has a person who can look at an alert and say "that is the coupling, not the bearing" because they have heard it before. The model narrows the search. Somebody still has to know the plant.