Your Dashboard Knows What Happened
It Cannot Tell You What Would
A plant dashboard is a rear-view mirror with excellent resolution. It will show you yesterday’s OEE by line, this week’s top five stoppages, the shift that underperformed. Then someone asks what happens if the filler goes down for a day in peak season, and every one of those numbers goes quiet — because none of them was ever a mechanism.
Descriptive, not predictive — and those are different tools
A dashboard reports measurements. Every figure on it is a summary of something that already occurred: counts, averages, rates, rankings. That is genuinely valuable, and it is why every plant has one.
A disruption question is not a measurement. “What if this supplier is two weeks late,” “what if we lose the second line for a shift,” “what if demand is 20% above plan in October” — each is a question about a plant that has not existed. There is nothing in a table of last month’s numbers that can answer one, no matter how many ways you slice it.
This is not a criticism of your dashboard. It is a category difference, and the trouble starts when the dashboard is the only tool in the room and the question gets asked anyway.
What people do instead, and why it misleads
When a what-if is asked and only history is available, the usual move is to reason from averages. If the filler is down 4% of the time and we lose it for another day, we lose roughly a day of output. That arithmetic is clean, intuitive, and wrong in a specific and expensive way.
It is wrong because a line is not a set of independent machines. They wait on each other. A stop upstream starves everything downstream; a stop downstream blocks everything upstream. Whether a given stop costs you anything at all depends on what was in the buffers when it began — and averages have no buffers, no sequence, and no clock.
A dashboard can tell you a machine stopped for 120 minutes. It cannot tell you whether those 120 minutes cost you anything — and sometimes they did not.
The case that shows the gap
In our bottling line case study, two failure modes recorded almost identical direct losses: Labeler Misalignment at 6.79%, Filler Micro Stop at 6.72%. On any dashboard they are the same bar, and most teams would attack the Labeler — it is the bigger single event, the one with a work order attached.
What the dashboard could not see
| 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× |
The one ranked lower recovers 62% more throughput. And the reason the dashboard could not warn you is worth stating plainly: the Filler’s 120 one-minute micro stops landed as idle time on the Labeler, the Case Packer and the Palletizer — logged under their names, never under the Filler’s. Three machines recorded a cost caused by a fourth. No amount of slicing recovers a number that was written down against the wrong machine.
What answering a what-if actually requires
To say what would happen, you need something with a mechanism: every machine, its failure modes, the buffers between them, and a clock. Then you change one thing, run it again, and compare. The change can be one nobody has made, because the model derives the behaviour rather than recalling it.
And the reason to believe the answer is that the same model reproduced a period you already measured. 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, rebuilt in ReliaSim and independently re-run within 1%.
That is the thing a dashboard cannot do and a model can: it can be wrong in a way you would notice, and then not be.
Keep the dashboard
None of this argues for replacing it. The dashboard is how you know the plant is behaving today, how you spot a drift, how you run a shift. It is also where the raw material comes from — the stop and start times your historian is already recording are exactly what a model is built from. The two are not competitors; one is the record, the other is the question.
The failure is asking the record a question only a model can answer, and then acting on the answer because it arrived in a familiar format.
Four questions worth asking in the next review
- “Is this a measurement or an estimate?” Both appear on dashboards, usually in the same typeface.
- “What would we get back if we fixed it?” Not what it cost. If nobody can answer with a number, the ranking is a guess.
- “Where did this stoppage actually originate?” Idle, starved and blocked time on the machines around a suspect is the signature of a cost that has been redistributed.
- “Have we ever checked this against a year we already lived through?” A tool that cannot reproduce the past has not earned a question about the future.
This is one of three: predictive maintenance knows your plant intimately and still cannot say what a change returns, and a language model will answer anyway, which is worse.