Discrete-event simulation for business processes

Table of contents+

Why "discrete" and why "event-driven"

There are two ways to handle time in a simulation.

Time-step driven: the clock advances in fixed steps (every minute, every second), and at each step you check what happened. Easy to program, wasteful to run: in an approval process, hours pass between two events in which nothing happens and yet computation continues.

Event-driven: the clock jumps to the time of the next scheduled event. Nothing changes in between, so nothing needs computing.

Event list (sorted by time):
  09:14  Arrival of case #418
  09:22  End of processing #402 at step "Review"
  09:40  Shift change at Approval
  ...
Clock jumps to 09:14, processes it, schedules follow-up events, jumps on.

"Discrete" means the state changes in jumps at individual points in time rather than continuously. That fits business processes exactly. An application is processed or not; half-processed does not exist.

The four building blocks

The most important property: queues are not modelled, they emerge. Entering a three-day wait as a fixed step presupposes the result you set out to compute. Afterwards you cannot show how that time changes when capacity or variation changes.

The three decisions that sink models

1. Which distribution?

For inter-arrival times: exponential. That is the default assumption when cases arrive independently of each other, such as invoices from different suppliers or tickets from different users. It produces exactly the behaviour you observe in an in-tray: long quiet stretches, then three at once.

Arrivals are not exponential when they are batched: a month-end run, a daily handover at 08:00. Then you need a calendar, not a distribution.

For processing durations: right-skewed. Lognormal or gamma. When you only have estimates, triangular from minimum, most likely and maximum. The reason: processing times have a hard lower bound and a long right tail. A normal distribution produces negative durations and underestimates the outliers that create the queue.

Practical rule of thumb: if all you know is "5 to 15 minutes", use a triangular distribution with a mode at 8. The choice between lognormal and gamma moves the result less than the question of whether you allow variation at all.

2. Warm-up period

A simulation starts with empty queues. That is a state your process never occupies. The first modelled days are therefore systematically too good.

Treatment: either exclude the first days from the analysis (warm-up) or start with a realistic initial backlog. For processes well below 85 % utilisation a few days suffice; close to the limit, settling can take weeks.

How you notice: if the average of the first week is well below that of the second, the warm-up was too short.

3. How many runs?

A single run is a sample of one. It says as much about the process as a single working day. Repeat with fresh random numbers until the result band is stable.

Practical criterion: double the number of runs. If P50 and P90 move by less than a few percent, the count is sufficient. For business processes it is typically several hundred.

More important than the exact number: that repetition happens at all and that the output is a band. A simulation that reports a single number has missed the point of the method.

The two modelling views

For business processes the process-oriented view is the more natural one: you write down what happens to a case, which is exactly how a department describes its own flow.

Validation: three checks

1. Little's Law. Work in progress ÷ throughput must roughly equal lead time, in the model and in reality. This check holds without assumptions about distributions and is therefore the strongest available.

2. Utilisation against hand calculation. ρ = demand ÷ capacity can be recomputed per step with a calculator. A large deviation means a branch or a calendar is wrong.

3. Extreme value test. Double the capacity of one step. If nothing changes, that step was never the constraint. If you did not expect that, your model disagrees with your mental picture. That is exactly when the interesting discussion starts.

Where DES is not the right method

• Participants make their own decisions that change the flow (customers abandon, handlers cherry-pick cases) → agent-based simulation.
• The question is about stocks and feedback over years (workforce build-up, market dynamics) → system dynamics.
• There are no queues because capacity is ample → addition suffices.
• The question is what actually happened → process mining. DES computes an assumption, not a log.