Process simulation

Process simulation takes a candidate design for how work should run and plays it against work that has already run. You have a record of six months of real cases. You have a proposal for a different way of handling them. The simulation asks the only question that matters before you build anything: what would have happened to those cases under the new design?

Out comes a per-case answer. This one would have cleared in an hour instead of three days. This one would have stalled waiting for an approval the new design routes differently. This one the agent would have got wrong.

Why it matters now

Until recently the only way to find out whether a redesign worked was to build it and watch. The pilot was the experiment, and it cost a quarter and a budget line. That expense quietly shaped which ideas got tried: conservative ones, because nobody wanted to spend a quarter on a long shot.

Simulation moves that cost down by an order of magnitude, and the consequence is not mainly speed. It is that you can afford to test the ambitious option. Most redesigns that look reckless on a slide turn out to be fine or obviously bad within an afternoon, and either answer is worth having.

The misuse

Simulation gets talked about as prediction. It isn’t, and the distinction is worth being pedantic about.

A simulation tells you how a design would have handled cases you have already seen. It says nothing about the case you have never seen, which is usually the one that breaks things.

So treat the output as a filter, not a forecast. It is very good at telling you which of three candidate designs is worst, and that is most of its value. A team presenting simulation results as expected benefits has quietly converted a weak claim into a strong one.

Two questions worth asking of any simulation: which cases were excluded, and what did it assume about how long humans take? The second is where optimism hides.