Process simulation

What is process simulation?

Process simulation is running a model of your process to find out what a change would do, before you touch the real one. You give the model how often work arrives, how long each step takes, who is available and when, and which way cases branch. Then you let a few thousand cases flow through it and read off the lead time, the queues and the workload per person.

The question always has the same shape. What if we add a second approver? What if we drop the goods-received check? What if volume goes up twenty percent in autumn? What if the shift starts an hour earlier? That is why the same thing is often called what-if analysis.

Two families of tools do this work.

Discrete-event simulation is the classic one. The model has cases that arrive, activities that take time, and resources with limited capacity. When a case reaches an activity and nobody is free, the case queues. The clock jumps from one event to the next, an arrival, a start, a finish, instead of ticking through empty minutes, which is why a year of work runs in a few seconds. Tools in this family, Simul8 among the older ones, ask you to name what flows through, the rules it follows and the resources it competes for, with the randomness of real life built in.

What-if on a discovered model is the newer route, and the reason simulation stopped being a specialist job. A process mining tool discovers the model from your event log, pulls most of the parameters out of that same log, and lets you edit a scenario and press run. Apromore does this on BPMN models: the output is a simulated log that you put next to the real one in a dashboard. SAP Signavio Process Manager has the same idea in its modelling tool, with tabs for costs, durations, case frequency and resources.

Either route does the same work for you: comparing two designs before you build either, sizing a team, checking whether next quarter's peak fits, and putting a number on what one handover costs.

What a model needs before you trust it

Five inputs, and almost every one of them is a distribution or a calendar rather than a single number.

• The arrival pattern. Not fifty invoices a day, but how the gaps between arrivals are spread, plus the shape across the week and the month. Apromore lets you pick fixed, normal, exponential, uniform, triangular, log-normal or gamma for the time between arrivals.

• A duration per activity, also as a distribution. Two hours on average with a long tail behaves nothing like a flat two hours, and the difference shows up in the queue behind it.

• Resources and their calendars. How many people can do this step, when they actually work, and what else fills their day. Wil van der Aalst's survival guide for business process simulation lists fifteen risks that undermine a simulation study, and names the naive modelling of resources as one reason models come out unreliable. Someone who spends two days a week on this process ends up in the model as if they sit waiting for it.

• Routing probabilities per gateway. Of the invoices that reach the three-way match, what share fails it and goes round again.

• Cost per activity and per hour, when you want the answer in euros as well as in days.

If you have an event log, you invent none of it. The gaps between arrivals, the duration of each activity, the share of cases down each branch, and who did what and when all sit in the timestamps. Building the parameters from real event data instead of from a workshop is what van der Aalst has been arguing for, and it is why simulation turned up as a button inside process mining products rather than staying in a tool of its own.

Why an average under-predicts the waiting

The classic mistake is to build the whole thing out of averages. Fifty invoices a day, three minutes each, two and a half hours of work in an eight-hour day, so there is no queue. That answer is wrong, and it is wrong in a predictable direction: it always says the waiting is shorter than it is.

Queues are not caused by a shortage of capacity. They are caused by variability. Work does not arrive evenly and no step takes the same time twice. When six invoices land in the same ten minutes, five of them wait, and the quiet hour that follows does not hand the waiting back. An average has no memory of that bunching.

The field that studies this is queueing theory, and the result that matters here is John Kingman's 1961 approximation for a single queue. In plain words it says average waiting goes up with three things: how spread out the arrivals are, how spread out the service times are, and how close the resource is to being busy all the time. That last one is not a straight line. Going from eighty to ninety percent busy roughly doubles the waiting, and ninety to ninety-five doubles it again. A simulation reproduces this by construction, because it draws every arrival and every duration from a distribution and lets the queue form on its own.

Simulation versus a spreadsheet calculation

The dimension that separates them is whether queues and variability exist in the model at all.

A spreadsheet divides work by capacity. It tells you whether the total fits in the available hours, which is a real question and usually the first one to ask. What it cannot tell you is how long one case waits, because a spreadsheet has no cases and no queue, only totals per period. It will report cheerfully that a manager with two and a half hours of invoice work a day has plenty of slack, while those invoices sit for four days.

A simulation pushes the cases through one at a time against resources that can be busy. You get a spread of lead times instead of one number, so you can ask what the slowest case in twenty looks like, and that is the case that generates the phone call. The price is setup effort and parameters you have to measure. Our rule of thumb: spreadsheet when the question is whether the volume fits in the year, simulation when the question is how long a case will wait.

Worked example: invoice approval at a sixty-person company

About a thousand supplier invoices a month, so roughly fifty a working day. The steps are registration, coding by bookkeeping, a goods-received confirmation that goes back to the person who ordered, approval by the department manager, and the weekly payment run. Measured lead time from arrival to payment: eleven working days. Hands-on work per invoice: under half an hour.

The event log gives the waiting per step: one day at registration, five days at the goods-received handover, four days at approval, one day until the next payment run. Two changes are on the table and the finance manager wants to know which one to do first.

• Add a second approver. Give the department manager a colleague with the same signing authority. The simulation drops the approval queue from four days to one, and lead time from eleven days to eight.

• Remove the handover. Capture the goods-received confirmation at the moment of delivery, in the screen the warehouse already uses, so the invoice never goes back out and comes back. The five-day wait disappears. But the simulation also shows the approval queue growing from four days to five, because invoices now reach the manager faster and in tighter bunches. Net lead time: seven days.

So the handover is worth a day more than the extra approver, and it costs nobody's salary. Doing both lands on five days rather than the four you would get by adding up the two savings, because the second approver only partly absorbs the bunching that removing the handover creates. That interaction is what a simulation is for. No amount of staring at the event log hands it to you.

Checking the model against the past

A simulation nobody has checked is a drawing with numbers on it. The test is cheap: feed the model last year's parameters, run it, and compare the lead time it produces with the one you actually had. Compare the shape as well as the middle. If the real process had a median of eleven days and a tail of cases running past thirty, and your model gives eleven days with almost nothing past fifteen, then the volume is right and the variability is wrong, and every queue answer it gives you will be too optimistic. The usual cause is a duration entered as a flat average, or a person modelled as available all day.

Within a day or so on both the middle and the tail is good enough to rank two designs against each other. It is not good enough to promise a customer a date.

What to watch out for with process simulation

It is not a forecast. A simulation says what happens to this process under these assumptions, not what the market does next quarter. Change the arrival rate and it tells you the consequence of that arrival rate, which is a different thing from predicting it.

It is not evidence for a decision somebody already took. The parameters come from real data or they come from an opinion, and anyone can produce the answer somebody wants by nudging one duration and one probability. If you cannot get an event log yet, measure three timestamps by hand for a month before you model anything. Write down every parameter and where it came from before you run, and let a colleague change one to see how far the answer moves.

Small differences are noise. Every run uses random draws, so two runs of the same scenario differ. Run each scenario often enough that the gap between scenarios is bigger than the gap between runs, and stop reading half a day as a result.

The long-run average is not your Tuesday. Most output describes how the process behaves once the model has settled. If the question is about the next two weeks, start the model from the backlog you have today rather than from empty.

Simulate the agent before you buy it. An AI agent proposed for a step is another resource with its own speed, its own availability and its own error rate, plus the rework those errors cause. Put those numbers in the model and you see what it does to the queue, which is usually a smaller change than the demo suggests, because the waiting was never in that step.