Why Predictive Maintenance
Can’t Answer What-If
Condition monitoring is good at the question it was built for: when will this machine fail? It is structurally unable to answer a different one: what do we get back if we fix it? Those are not the same question, and on a real line the answers can point at different machines.
Two different questions
A predictive-maintenance system learns from sensor data — vibration, temperature, current draw — collected from your plant as it runs today. From that it forecasts a failure before it happens. That works, and it is worth having.
But every one of those readings comes from one specific plant: the one with the buffers you have, at the speeds you run, in the order your machines are arranged. Ask what happens if you add a buffer, run the filler slower, or fix a different failure mode first, and the data is describing a line that no longer exists. Nothing in the sensor history of the plant you have describes a plant you have not built.
That is the boundary. It is not a shortcoming of any particular tool — it is what the method is.
Even a perfect failure prediction ranks the wrong thing
Suppose the prediction is flawless: every failure caught, every hour of downtime attributed correctly. You still have a loss report, and a loss report ranks failure modes by what they cost. What you need is a ranking by what comes back when you remove them. Those are different numbers, and the gap is not small.
In our bottling line case study, a five-machine line had two failure modes that a downtime Pareto ranks level:
Same loss, different return
| Failure mode | Direct loss | Returned when removed | Return ÷ loss |
|---|---|---|---|
| Labeler Misalignment — rare, long stops | 6.79% | +5.0 pts | 0.73× |
| Filler Micro Stop — frequent, short stops | 6.72% | +8.1 pts | 1.21× |
6.79% against 6.72%. On any Pareto chart these are the same bar, and most teams pick the Labeler — it is the bigger single event, the one people remember, the one with a work order attached. The one beside it recovers 62% more throughput when it is fixed instead.
Why these are not two similar things
The table hides what separates them, so it is worth being concrete.
The Labeler stops rarely, for a long time. When it does, the buffers do their job: upstream stock keeps the machines before it fed, downstream stock keeps the machines after it running. The line absorbs part of the stop. That is why removing it returns less than it appeared to cost — you were never losing all of it in the first place.
The Filler stops constantly, for seconds at a time. In the case study, 120 one-minute micro stops. A buffer absorbs a stop only if it has stock when the stop begins, and at that frequency the buffers never refill between events. So the losses stop being absorbed and start propagating.
And here is the part that makes this invisible to any report built on machine-level data:
Those 120 micro stops landed as idle time on the Labeler, the Case Packer and the Palletizer — recorded under their names, never under the Filler’s.
The Filler starves the machines after it and blocks the machines before it. Three other machines log the downtime. The Filler’s own record looks moderate. No amount of sensor accuracy on the Filler recovers a cost that was written down against three of its neighbours — and no Pareto ordered by machine finds it either, because the evidence has been scattered across the line under the wrong headings.
That is the real difference between rare-and-long and frequent-and-short. Not two similar things with different shapes: one the line quietly absorbs, and one the line quietly spreads.
What actually crosses the boundary
To answer what if, you need a model of the whole line — every machine, its failure modes, the buffers between them — that reproduces output you have already measured. Then you change one thing, re-run, and compare. The change can be one you have never made, because the model derives the behaviour rather than recalling it.
The reason to trust that step is that the method has been checked against reality. A peer-reviewed WSC 2020 study modelled a multi-line food plant — twenty-plus unit operations, up to twenty failure modes each — and agreed with the plant’s measured OEE to within one percentage point across a full year. That model was rebuilt in ReliaSim and independently re-run within 1% of both the measured figure and the original.
Validation and prediction are two different claims, and the order matters: matching a year you can check is what earns the right to be believed about a configuration nobody has built yet.
What this does not say
It does not say condition monitoring is wrong. If a bearing is failing you want to know before it does, and a vibration signature will tell you sooner than a model will. Keep it.
It says there is a question it was never built to answer — and that question, what does this change return, is the one standing between a maintenance budget and a defensible business case.
How to tell which you have
- Look for stops recorded against machines that were not the cause. Idle, starved and blocked time on the machines around a suspect is the signature of a cost that has been redistributed.
- Compare stop counts, not only stop hours. A hundred short stops and one long stop can log identical downtime and behave nothing alike.
- Check whether your buffers ever refill. A buffer that is empty when the next stop starts is not a buffer any more.
- Ask what a fix returns, not what the failure costs. If nobody can answer that with a number, the ranking is a guess.
Related: micro-stops vs breakdowns takes the same pair further, and how big a buffer should be covers the absorbing side.