Spreadsheet, Dashboard, AI or Simulation?
Which One Can Answer What-If

Four tools get pointed at the same question: where is our throughput going, and what should we change? A spreadsheet and a dashboard both describe what already happened. A model trained on history can’t answer for a line it has never seen. Each one fails in a different way, and how they fail matters more than their feature lists.

The spreadsheet, or loss tree

Almost every plant starts here, and for good reason. A loss tree is transparent, it costs nothing, anyone in the room can audit it, and it’s usually right about the total. If you want to know how many minutes were lost last month and roughly to what, a spreadsheet answers that well.

Where it breaks is interaction. A loss tree adds losses as if they were independent, and they aren’t. Where a stoppage sits in the line decides what it costs, so two stoppages of equal length can cost completely different amounts. The spreadsheet has no column for that. Which Loss to Fix First works through what that does to a ranking.

AI, on its own and on top of a model

A model trained on your historian is good at pattern-finding that a spreadsheet can’t do, like spotting a signature that comes before a failure, or two events that show up together more often than chance. But a model learned from history can only answer questions about configurations that appear in the history. Ask about a fifty-pallet accumulator between the labeler and the case packer and it’ll still answer, with an extrapolation dressed as a prediction (see why predictive maintenance can’t answer what-if and why an LLM will answer anyway). The useful setup is AI running a validated simulation instead of standing in for one. You ask in plain language, the engine computes the answer, and every figure traces back to a run you can reproduce.

Simulation, and what it costs

A discrete-rate model answers counterfactuals because it computes the answer instead of learning it. Rates, capacities and interrupts interact mechanically, so blocking and starvation emerge from the flow rather than being assumed. Change the buffer and the model has never seen that line before either, and it doesn’t need to.

The cost is real:

• You have to build a model, which means describing the line's structure rather than just exporting its data.
• You need failure data good enough to parameterize it. Lumped downtime gets you a working model; named failure modes get you one that tells you which machine to fix.
• It has to be validated before it’s worth anything. An unvalidated simulation is a confident answer with no more standing than the AI's.

Our models are checked against measured production per failure mode, not just in aggregate. See Asset Efficiency vs OEE for what that comparison involves and why the denominator has to be agreed first.

Two things a spreadsheet structurally can’t do

A loss tree is a static, mean-value model, and a production line is neither static nor deterministic.

It has no clock

A spreadsheet has no representation of when. A table of totals has no way to show a buffer filling and then draining, a stoppage propagating upstream three stations later, or a machine starved for the first hour of a shift and blocked for the last. You can add a column for downtime. You can’t add a column for sequence, and sequence decides whether ten minutes of downtime cost anything at all.

It computes with averages, and averaging is biased

This is the more serious of the two, because you can’t be careful around it. For machines in series with buffers between them, expected throughput is strictly less than the figure you get by multiplying average rates and average availabilities. The mean of the output isn’t the output of the means, and the error always runs the same way.

The arithmetic is exact in only one case, a single resource with no upstream or downstream interaction, when all you want is the long-run mean. That describes very few packaging lines. Add a second stage and a buffer and the exactness is gone.

What a loss tree is actually for

A loss tree is the right tool for accounting. It gives a shared, auditable statement of what happened last month. The mistake is carrying it over into prediction.

The dashboard, and the what-if it can’t answer

A plant dashboard is a rear-view mirror with excellent resolution. It’ll show you yesterday’s OEE by line, this week’s top five stoppages and the shift that underperformed. Every figure on it sums up something that already happened, and that’s why every plant has one.

A disruption question isn’t a measurement. Take “what if this supplier is two weeks late,” “what if we lose the second line for a shift,” or “what if demand is 20% above plan in October.” Each one asks about a plant that hasn’t existed. Nothing in a table of last month’s numbers can answer it, no matter how many ways you slice it. The usual fallback is to reason from averages, and that runs into the same bias as the loss tree above.

Keep the dashboard

None of this argues for replacing it. The dashboard is how you know how the plant is doing today, spot a drift and run a shift. It’s also where the raw material comes from, since a model is built from the stop and start times your historian already records. The mistake is asking the record a question only a model can answer, then acting on the answer because it showed up in a familiar format.

Four questions to ask in your next review

1. “Is this a measurement or an estimate?” Both appear on dashboards, usually in the same typeface.
2. “What would we get back if we fixed it?” Ask that instead of what it cost.
3. “Where did this stoppage actually originate?” Costs get logged against the machines around the cause. In our bottling line case study, two failure modes with nearly the same direct loss differed by 62% in the throughput a fix recovered (how to spot it).
4. “Have we ever checked this against a year we already lived through?” A tool that can’t reproduce the past hasn’t earned a question about the future. A peer-reviewed plant model and its ReliaSim rebuild landed within one percentage point of measured OEE across a full year.