Spreadsheet, AI, or ReliaSim?
What Each One Can Actually Tell You

Three tools get pointed at the same question — where is our throughput going, and what should we change? They fail in three different ways, and the failure modes matter more than the 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 is 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.

It breaks on one specific thing: interaction. A loss tree adds losses as if they were independent. They are not. Ten minutes of downtime on a machine feeding a full buffer costs nothing; the same ten minutes on a starved constraint costs ten minutes of finished product. The spreadsheet records both as ten minutes.

AI on its own

A model trained on your historian is genuinely good at things a spreadsheet cannot do: finding patterns across thousands of tags, spotting a signature that precedes a failure, flagging that two events co-occur more often than chance. On messy plant data at scale, that is real value.

Its limit is structural rather than a question of model quality. A model learned from history can only answer questions about configurations that appear in the history. Ask what happens if you add a fifty-pallet accumulator between the labeler and the case packer, and there is nothing in the training data about a line with that accumulator. It will still answer. The answer is an extrapolation dressed as a prediction, and it is confident either way.

That is the whole difficulty with using AI alone for capital decisions. The questions worth spending money on are exactly the counterfactual ones — a line you have not built, a buffer you have not installed, a shift pattern you have not run.

Simulation, and what it honestly costs

A discrete-rate model answers counterfactuals because it does not learn the answer — it computes 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; it does not need to have.

The cost is real and worth stating plainly:

• 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 parameterise 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 is worth anything. An unvalidated simulation is a confident answer with no more standing than the AI's.

That last point is the one that separates a useful model from an expensive one. Ours is 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 cannot do

It is tempting to hand the spreadsheet a few honourable wins for balance. That would be misleading, because the gap is not one of precision or convenience — it is that 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 buffer filling and then draining, a stoppage propagating upstream three stations later, a machine starved for the first hour of a shift and blocked for the last — none of that exists in a table of totals. You can add a column for downtime; you cannot add a column for sequence, and sequence is what 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 it is not something you can be careful around. 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 is not the output of the means, and the error runs one way: arithmetic on averages overstates what the line will produce.

The arithmetic is genuinely exact in one case: a single resource, no upstream or downstream interaction, and you want only 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

None of that makes the spreadsheet useless — it makes it a different instrument. A loss tree is the right tool for accounting: recording what happened last month, attributing minutes to causes, giving everyone a shared and auditable statement of the past. It is transparent, it is cheap, and anyone in the room can check it.

The mistake is carrying it across into prediction. Reporting the past and forecasting a change are different jobs, and the tool that is excellent at the first is structurally unfit for the second. Most plants own a good loss tree and ask it the wrong question.

The combination, which is the actual argument

These are not really three competing options. The useful arrangement is AI operating a validated simulation rather than substituting for one: the model supplies mechanism and a defensible baseline, and the AI supplies the speed of asking. Questions get posed in plain language, the engine computes the answer, and every figure traces to a run you can reproduce.

It also fixes the failure mode people rightly worry about with AI in engineering. When the numbers come from an engine rather than from a language model's recall, a wrong answer is a modelling error you can find — not a fluent invention.

Related: Asset Efficiency vs OEE · How big should a buffer be? · Five decisions every production system faces