Process costs in Excel: four mistakes that sink any business case
Process cost spreadsheets systematically overstate savings for four reasons: they compute with means instead of distributions, they add processing times and therefore miss queues, they average utilisation over the month instead of looking at the peak day, and they credit savings to steps that are not the bottleneck. None of these are slips — they are limits of the instrument. A spreadsheet has no concept of a queue.
The business case for a process improvement is almost always built in a spreadsheet. That is entirely fine — until somebody checks the maths.
Four mistakes recur so reliably that they can be called a pattern. None of them is carelessness. All four are limits of the instrument.
Mistake 1: computing with means
The spreadsheet says “processing time: 7.5 minutes”. In reality the case takes between 4 and 25 minutes, usually 6.
This is not a rounding issue. For non-linear relationships, the expected value of the result is not the result of the expected value — Jensen's inequality, popularised as the “Flaw of Averages”. And queues are highly non-linear.
In practice: a process where every case takes exactly 7.5 minutes and a process with the same mean but wide variability have completely different lead times. The second is markedly slower. The spreadsheet treats them as identical.
How to spot it: every duration in the model is a single number. There is no “from” and “to” column.
What helps: collect durations as ranges. Do not ask “how long does this take?” but “how long on a good day, and how long in the worst case you had last month?”.
Mistake 2: confusing processing time with lead time
The spreadsheet adds up: 5 + 12 + 8 + 10 = 35 minutes. The arithmetic is right. It just measures something other than what the customer experiences.
The customer experiences: application arrives Monday, decision arrives Thursday. Between those 35 minutes of work lie three days of waiting — in inboxes, in front of approvals, in clarification loops.
In most administrative processes, actual processing accounts for a low single-digit percentage of lead time. A business case that saves 20 % of processing time therefore saves a fraction of a fraction of lead time — while being sold as “20 % faster”.
How to spot it: the total row is labelled “lead time” but is the sum of processing times.
What helps: Little's Law as a cross-check. Count the waiting cases and divide by daily throughput. If the result deviates strongly from your sum — and it will — your model is missing the queues.
Mistake 3: utilisation as a monthly average
The spreadsheet says: “case handling 74 % utilised, so there is room.”
The monthly average is the friendliest of all metrics. It hides exactly what goes wrong. A process at 74 % on average can sit at 130 % on five days a month — and on precisely those five days the entire backlog is created that the remaining fifteen days then work off.
Add the non-linear effect: waiting grows with the factor ρ/(1−ρ). At 74 % that is 2.8. At 95 % it is 19. An average across both states is not a meaningful number, because the relationship is curved.
How to spot it: a utilisation figure appears without stating what it refers to.
What helps: compute with the 90th-percentile day. If you only have monthly volumes, divide by working days and multiply by 1.4 to 1.8 for the peak — and name that assumption in the document.
Mistake 4: saving at the wrong step
This is the most expensive mistake, because it leads to real investments.
The spreadsheet computes: “step 4 takes 18 minutes, we automate half of it, that is 9 minutes × 1200 cases × €65/h = €23,400 a year.” The multiplication is correct. The saving still does not materialise.
Because if step 4 is not the bottleneck, speeding it up changes throughput by nothing. The freed-up time does not land in the P&L — it lands as waiting time in front of the actual constraint. That is the core of the Theory of Constraints, and also the lived experience of every process owner who has introduced a tool that “didn't do anything”.
Conversely: relieve the real constraint and you often get more than calculated — until the constraint migrates to another step and throttles again.
How to spot it: the business case multiplies time saved by hourly rate by volume, without stating anywhere which step is the bottleneck.
What helps: compute utilisation per step first and sort it. Anything that is not the highest value contributes nothing to throughput. It may still be worth doing — quality, error rates, job satisfaction — but then the business case must argue on those grounds.
The four mistakes side by side
| Mistake | Effect on the business case | How to spot it |
|---|---|---|
| Means instead of ranges | lead time too low | every duration is a single number |
| Processing instead of lead time | savings heavily overstated | “lead time” = sum of processing times |
| Utilisation as monthly average | bottleneck invisible | percentage without a reference |
| Saving at a non-bottleneck | saving never materialises | no mention of which step is the constraint |
What a spreadsheet fundamentally cannot do
These four points can be mitigated with discipline, but a residue is structural: a spreadsheet has no concept of a queue. It computes cells, not cases waiting on one another. So it also cannot see what happens after an improvement — that a relieved constraint passes the full volume to the next step, which then becomes the constraint.
That is what simulation is for. It runs individual cases through the model, with variability and a calendar, hundreds of times. The output is not a number but a distribution — and that survives a critical follow-up question.
The test before you submit
Before your business case goes into a decision paper, answer four questions in writing:
- Which step is the bottleneck, and how do I know?
- Am I referring to processing time or to lead time?
- Which day does my utilisation figure refer to?
- How wide is the range of my saving, and what is the unfavourable case?
Answer all four and you have a business case. Fail to, and you have a spreadsheet.
Frequently asked
What is the “Flaw of Averages”?
The observation that plans built on average values are systematically wrong where relationships are non-linear — mathematically, Jensen's inequality. It hits processes especially hard because waiting time depends non-linearly on utilisation: two processes with the same mean processing time but different variability have markedly different lead times.
What share of lead time is actual processing?
In administrative processes it is typically in the low single-digit percentages — the rest is waiting in inboxes, in front of approvals and in clarification loops. That is why measures saving processing time often barely move the lead time customers experience. Measure the share rather than guessing: inventory divided by daily throughput gives you lead time.
Why does automating a non-bottleneck deliver nothing?
Because throughput is set by the slowest step. Speed up a step before or after it and the freed capacity simply waits longer on the constraint. The saving shows up in the spreadsheet but not in the accounts. The measure may still be worthwhile — but then on grounds other than throughput.
What factor should I use for the peak day?
Without daily data, a factor of 1.4 to 1.8 on the daily average is a common approximation for administrative processes with month-start or weekend effects. More important than the exact value is that the assumption appears in the document — then somebody can correct it instead of adopting it unnoticed.
Run the numbers on your own process
FlowVisual turns the figures in this article into a model that runs — with your volumes, your capacities, your range.
- Method
Monte Carlo simulation for business processes: what it does and when it lies
Monte Carlo is not a magic word, it is systematic dice-rolling: the same process, hundreds of times, with different random draws each time. What comes out is not a number but a distribution — and that is the whole point.
Read - Method
Reading P10, P50 and P90 — and where the average misleads you
Percentiles are not statistician's vanity; they are the only honest way to report a result that varies. Three numbers, three purposes — and three misreadings that routinely end up in decision papers.
Read - Method
How to calculate a bottleneck: why 85 % utilisation is already too much
The bottleneck is not the longest step, it is the step with the highest utilisation. And waiting time does not grow linearly with utilisation — it explodes just before the limit. The maths behind it fits on one page.
Read