Why your predictive maintenance pilot stalled

The story is so common it has a shape. A vendor demo impressed the leadership team. A pilot got funded. A model was trained on a slice of maintenance history and it worked, in the sense that its precision and recall looked respectable on a slide. Eighteen months later the subscription is still being paid, the maintenance planner still runs the same Monday meeting from the same spreadsheet, and nobody can name a work order that exists because the model asked for it.

The usual post-mortem blames the data, or the vendor, or “change management.” Having sat on the receiving end of a few of these inheritances, we think the causes are more specific than that, and more fixable.

The model answered a question nobody asked

Most predictive maintenance products answer: “what is the probability this asset fails in the next N days?” A maintenance planner’s actual question on Monday morning is: “which of the jobs I could schedule this week buys me the most uptime for the crew hours I have?” Those are different questions. A probability with no cost, no crew, and no window attached is trivia. The planner glances at it, agrees or doesn’t, and goes back to the spreadsheet that at least speaks in jobs.

A failure probability becomes useful the moment it is joined to things the ERP already knows: the parts on hand, the planned production schedule, the cost of the last five failures of that asset. That join is unglamorous integration work, which is exactly why the pilot skipped it.

It lived in a new screen

The pilot shipped as a portal. Another login, another tab, another thing to check. The people it was built for already run their shift from two or three screens they trust, and a prediction that lives anywhere else is competing for attention it will not win. Six weeks of enthusiasm, then the tab stops being opened, and the model is now making predictions into a void.

Software the floor doesn't open is indistinguishable from software that doesn't work.

The fix costs less than the model did: put the flag in the CMMS queue, on the dispatch screen, in the morning report that already gets printed. Wherever the decision already happens. If the integration is the expensive part, that is the project telling you what it actually is.

Trust was never measured

Every pilot review we have read reports model accuracy. Almost none report the number that decides the pilot’s fate: how often the humans act on what the model says. Override and ignore rates are measurable from day one, and they are the earliest honest signal you can get. A model that is 85% accurate and acted on beats a model that is 95% accurate and ignored, every week, by a margin you can put on the P&L.

Measuring trust also changes behaviour on both sides. When an ignored alert later turns into a failure, there is a record and a conversation. When the model cries wolf, there is a record of that too, and the threshold gets fixed instead of resented. The planner who overrode the forecast stops being an anecdote and becomes data.

The exceptions were treated as noise

Every operation has them: the compressor that always runs hot in summer and is fine, the line that gets slammed before the holiday rush, the sensor that has read 4°C low since it was replaced. The floor knows all of this. The pilot’s model knew none of it, so its first confident alerts were things every fitter already knew were fine, and its credibility never recovered.

The exceptions are not noise. They are the specification. Collecting them takes days of sitting with the people who hold them, and it is the highest-value data work on the project. A model that opens by confirming what the floor knows earns the right to later tell it something it doesn't.

What we do differently

When we scope this kind of system now, the model is maybe a third of the work. The rest is the join to the schedule and the parts ledger, the wiring into the screens that already run the shift, the exception interviews, and an override rate on a chart that the engagement is judged by. None of that demos well in a sales meeting. All of it is the difference between a pilot and a system.