Why Predictive Maintenance
Can’t Answer What-If

Condition monitoring is good at the question it was built for, which is when will this machine fail? By design, it can’t answer a second question, what do we get back if we fix it? Those questions aren’t the same, and on a real line the answers can point at different machines.

Two different questions

A predictive-maintenance system learns from sensor data, such as vibration, temperature and current draw, collected from your plant as it runs today. From that it forecasts a failure before it happens. That works, and it’s worth having.

But every one of those readings comes from one specific plant, 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 haven’t built.

Even a perfect failure prediction ranks the wrong thing

Suppose the prediction is flawless, with every failure caught and 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 isn’t small.

In our bottling line case study, a five-machine line had two failure modes that a downtime Pareto ranks level:

Most teams pick the Labeler, because it’s the bigger single event, the one people remember and the one with a work order attached. The one beside it recovers 62% more throughput when it’s fixed instead.

Why these aren’t two similar things

The Labeler stops rarely, for a long time. When it does, the buffers do their job. Stock upstream of it gives the machines before it somewhere to send product, and stock downstream keeps the machines after it fed. The line absorbs part of the stop. So removing it returns less than it appeared to cost.

The Filler stops constantly, for seconds at a time. In the case study, it had 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 spreading.

Any report built on machine-level data misses the next part.

Those 120 micro stops landed as idle time on the Labeler, the Case Packer and the Palletizer, recorded under their names and never under the Filler’s.

The Filler starves the machines after it and blocks the machines before it. 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 neighbors. No Pareto ordered by machine finds it either, because the evidence has been scattered across the line under the wrong headings.

What actually crosses the boundary

To answer what if, you need a model of the whole line that reproduces output you’ve already measured. It has to include every machine, its failure modes and the buffers between them. Then you change one thing, re-run and compare. The change can be one you’ve never made, because the model works out the behavior rather than recalling it.

You can trust that step because the method has been checked against reality. A peer-reviewed WSC 2020 plant model matched measured OEE within one percentage point over a full year, and so did its ReliaSim® rebuild.

Validation and prediction are two different claims, and the order matters. Matching a year you can check is what earns a model the right to be believed about a configuration nobody has built yet.

What this doesn’t say

It doesn’t 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, so keep your condition monitoring.

It says there’s a question condition monitoring was never built to answer. 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

1. Look for stops recorded against machines that weren’t the cause. Idle, starved and blocked time on the machines around a suspect is the signature of a cost that has been redistributed.
2. Compare stop counts, not only stop hours. A hundred short stops and one long stop can log identical downtime and behave nothing alike.
3. Check whether your buffers ever refill. A buffer that’s empty when the next stop starts isn’t a buffer anymore.
4. 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.

Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck.