Predictive maintenance works when the operations team agrees with it

A maintenance model can be accurate, deployed, monitored and entirely ignored. The equipment still fails at 3am and the technician still finds the work order in a filing cabinet.

This is not a modelling failure. It is the most common failure mode in industrial analytics, and it is structural.

The five hours that decide everything

Ask a maintenance team when they actually decide a job happens. It is almost never when the model fires.

They decide when they open the work order, when they can find the part, when a qualified technician is free, and when taking the machine down will not cost more than leaving it running. The model produces a probability. The team produces a plan. Those are different artefacts and they have to meet somewhere.

If the meeting point is undefined, the model output is one more input in a decision the team already makes on different grounds.

Three failure modes worth naming

The alert is unachievable. The model flags failure probability rising on a component that cannot be replaced without a four-week planned shutdown. A technically correct prediction that cannot be acted on trains the team to ignore the system.

The recommendation contradicts the spares plan. The model is confident about a bearing. There is no bearing in the warehouse and a twelve-week lead time. Once again: correct, useless.

The prediction arrives after the failure. If your data pipeline has a two-day lag, you are forecasting the past. Teams spot this within weeks and conclude the whole thing is unreliable.

Each of these is fixable, but only by involving maintenance planners in the design. If they first hear about the model at a go-live demonstration, you have already lost them.

What to build alongside the model

A maintenance instruction, not an alert. Each prediction should arrive with the specific action: which component, what the current state is, what the predicted state is, what to do, and what to do if you cannot.

An explicit "do nothing" option. Sometimes the correct action is to defer to the next planned window. Making that a first-class choice stops the model generating pressure to act on everything.

A suppression mechanism. When a planner rejects a prediction, capture the reason. Ten rejections with the same reason is a spares or scheduling problem, not a model problem — and it should be routed there.

A weekly review with actual outcomes. Not model metrics. What the team did last week, what happened, and where the two diverged.

Measure the right thing

Accuracy is the model's opinion about itself. The metrics that matter:

• percentage of predictions acted on within the actionable window
• lead time between prediction and planned intervention
• unplanned downtime on assets under monitoring versus assets not yet covered
• planner hours spent reviewing alerts

That last one matters more than teams expect. If reviewing the system takes more time than it saves, it will be quietly abandoned regardless of its accuracy.

Start smaller than feels justified

The common instinct is to instrument a whole line and model everything. Resist it.

Pick one asset class with genuine downtime cost, existing failure history, and a maintenance team willing to participate. Prove the loop end to end on that. The second asset class is far easier once the first has changed how the team spends a Tuesday.

The honest summary

Predictive maintenance is a change programme with a model attached. The model is the easy part and takes weeks. Changing how a maintenance team plans work, and convincing them the plan is better than their judgement, takes months and is the part that determines whether any of it survives.