What is process simulation? Definition, methods, limits

The definition

Process simulation is the artificial execution of a flow inside a model. Instead of describing what should happen, you let cases actually run through the model — with a clock, with queues, with randomly drawn durations — and measure what comes out.

The difference from a spreadsheet calculation comes down to one word: waiting. A spreadsheet adds processing times. A simulation represents the fact that a case waits when the next step is busy. In administrative and service processes, waiting is typically 90 to 99 percent of lead time — so the spreadsheet computes the unimportant part precisely and omits the important one.

The three methods

For a business process with steps, roles and approvals, discrete-event is essentially always the right method. Agent-based becomes interesting when participants make their own decisions that change the flow — customers abandoning a queue, for example. System dynamics answers no question about an individual case; it answers questions about stocks over long horizons.

What a simulation model needs

Five inputs per step, no more:

1. Arrivals — how many cases come in, and how much does that vary? A mean alone is not enough; the damage happens on the peak day.
2. Processing duration as a range — not "10 minutes" but "5 to 15". The spread is the actual information: it is what creates the queue.
3. Capacity — people × productive hours, or a fixed takt where a machine sets the limit.
4. Branching — which share of cases takes which path, and what leaves the process again (rejected, withdrawn, abandoned)?
5. Calendar and cost — when is work done, and what does an hour in this role cost (fully loaded, not gross salary ÷ 2,080).

What a simulation model does not need: an event log, a system integration, complete data. Estimated values are legitimate as long as they stay visible as assumptions — a model with open assumptions beats a spreadsheet with hidden ones.

How a run works

1. Clock to zero. Draw the first arrival time.
2. Jump to the next event (arrival, end of processing, shift change).
3. Update state: queues, busy capacity, counters.
4. Schedule the next event — draw the duration from the distribution.
5. Back to 2 until the horizon is reached.
6. Repeat the whole run hundreds of times, with fresh random numbers each time.

Step 6 is the Monte Carlo repetition. It is what produces the actual result: not a single number but a distribution. From it you read P10, P50 and P90 — the good case, the middle one, and the one you make commitments against.

What comes out

• Throughput — how many cases does the process manage per day?
• Lead time — as a band, not a mean. P50 and P90.
• Utilisation per step — the number the constraint hangs on. Above roughly 85 % it gets expensive, because waiting grows with ρ/(1−ρ).
• Queues — where do how many cases sit?
• Cost — staff cost per case, extrapolated to a year.

And, in a before/after comparison, the answer to the question that justifies the effort at all: where does the constraint move once I fix it, and what is that worth?

When simulation pays off — and when it does not

Worth it:

• The process has queues, and waiting is a large part of lead time.
• Volume or durations vary noticeably.
• You want to compute a change before implementing it.
• Somebody has to sign the number and will ask follow-up questions.

Not worth it:

• The process runs well below capacity with no backlog. Then processing time is lead time, and addition suffices.
• You want to document, not compute. A drawing tool is right for that.
• You want to know what actually happened yesterday. Process mining is right for that — simulation computes an assumption, not a log.

Common misunderstandings

"Simulation needs perfect data." No. It needs honest ranges. A model with five-to-fifteen-minute ranges produces a usable band; a model with an invented ten produces false precision.

"Simulation predicts the future." No. It shows what follows from stated assumptions. The value lies in comparing two states under the same assumptions, not in the absolute value.

"The more detail, the better." No. Five to ten steps is almost always enough. The constraint sits where utilisation is highest, and that is just as visible in a coarse model as in a fine one. Every extra activity costs input fields without moving the result.

In summary

• Process simulation executes a flow artificially instead of describing it — the difference is the queue.
• For business processes, discrete-event simulation is the appropriate method.
• Five inputs per step suffice; estimates are legitimate if they stay visible.
• The result is a distribution, not a value — P10, P50, P90.
• The real value lies in the before/after and in the migration of the constraint.