Predictive Maintenance Doesn't Fail at Predicting
Rockwell Automation and Augury announced a partnership in late July aimed at machine health and maintenance. The interesting part is not the technology. It is how they describe the problem they are solving: closing the gap between insight and action, by connecting reliability recommendations to maintenance execution and production context.
Read that as what it is – two vendors in this market saying out loud that the insights have not been the constraint. After a decade of selling predictive maintenance, the industry is now selling the part that comes after the prediction, because that is where the value was leaking.
The failure nobody puts in the case study
Predictive maintenance works. Vibration and thermal data really do surface a failing bearing weeks before anyone hears it. The models are good enough, and have been for a while.
What happens next is the problem. The system flags an asset. The alert lands in a dashboard, or an email, or a system the maintenance planner opens twice a week. The line is running, the order book is full, and taking that machine down means missing a shipment. So the alert waits. Another one arrives. Within a few months there are more open flags than anyone can work through, the team learns which ones tend not to matter, and the system quietly becomes background noise. Then something fails, and it turns out it was flagged in March.
Nothing in that sequence is a technology failure. The sensor was right, the model was right, the alert was correct and on time. The organization had no route from the alert to a scheduled, resourced, prioritized job, and no way to weigh one flag against the production plan.
Why the routing is harder than the prediction
Acting on a maintenance prediction requires answering questions the prediction cannot answer. How bad is it, in money, if this runs to failure. Do we have the part. Which shift has capacity. What does taking this asset down cost against the current schedule, and is there a changeover window where it costs less. Who decides when the answer is not obvious.
Those answers live in the CMMS, the ERP, the production schedule, and in the planner’s head – not in the monitoring system. Which is precisely why the vendors are now building the connective tissue between them rather than better models. It is also why buying a monitoring product and expecting downtime to drop is a bet on the part of the workflow the product does not touch.
What this means before you buy anything
If you are evaluating predictive maintenance, the question that predicts your outcome is not model accuracy. It is: when this system produces an alert, what happens?
Trace the path concretely. Who sees it. Where does it go. Who decides whether to act. How does it become a work order with a part and a slot on the schedule. What happens when it conflicts with a production commitment, and who breaks the tie. If you cannot answer those today for your existing maintenance requests, adding a source of more accurate alerts will not fix it – it will produce a more accurate backlog.
And if you already have monitoring in place and are not sure it is earning its cost, there is a cheap diagnostic available before any purchase. Pull the alerts from the last six months and check how many resulted in a scheduled intervention. If most did not, you do not have a prediction problem. You have a decision-and-scheduling problem, and no additional sensor will touch it.
The wider pattern is one worth carrying into every AI project on the shop floor. The model that produces a recommendation is usually the easy half. The workflow that turns the recommendation into a job someone actually does is the half that decides whether any of it was worth buying. The vendors are now building for that half, which is a good sign – and a hint about where your own attention should have been all along.
“Content generated using AI”