What Is Business Process Simulation?

A process map shows the steps a case can take. It rarely shows what actually happens when a hundred cases arrive in a week, some at once and some spaced out, some straightforward and some full of exceptions. Business process simulation is the practice of building a model of a process, including how cases arrive, how long each task takes, who or what performs each task, and where decisions branch the flow, then running that model many times to see how it behaves under realistic conditions rather than under a single idealized run.

The result is not a single number. It is a distribution of outcomes: a range of cycle times, a range of queue lengths, a picture of which step tends to become congested and how often. That range is the point. A process rarely runs the same way twice, and a simulation is built to reflect that, rather than to describe one clean pass through the flowchart.

The building blocks of a simulation model

A useful process simulation is built from a small set of ingredients, and getting each one reasonably accurate matters more than making the model elaborate. Arrivals describe how new cases enter the process: a steady trickle, a morning spike, a weekly batch. Task durations describe how long each step takes, usually as a range rather than a fixed number, because a claims review that takes eight minutes on a simple case might take forty on a complicated one. Resources describe who or what is available to do the work, and how many of them there are at a given time. Decision points describe where a case branches, such as an approval that is granted most of the time but escalated in a minority of cases. Rework describes the loop back to an earlier step when something fails a check and has to be redone.

None of these ingredients need to be perfectly precise to be useful. A rough but honest estimate of how long an approval step usually takes, and how often it gets kicked back for correction, produces a far more useful model than a process diagram with no timing information attached to it at all. The value comes from combining these ingredients into a coherent run of the process, not from getting any single number exactly right.

Why a single run through the process is not enough

If you walk a process through once, on paper or in a workshop, you get a single story: this case arrived, took this path, and finished in this many days. That story is true, but it is only one of many possible stories, and it is not necessarily a representative one. A process simulation deals with this by running the model repeatedly, often hundreds of times, each time with slightly different arrival patterns, task durations, and decision outcomes drawn from realistic ranges. Across those runs, patterns emerge that a single walkthrough could never reveal: how often the approval queue actually backs up, what proportion of cases hit the rework loop, and how far the slowest cases lag behind the typical ones.

This is what separates simulation from mapping. A map is a static description of the possible paths. A simulation is a dynamic test of what happens when a realistic mix of cases moves through those paths under realistic constraints, including limited staff, shared queues, and the knock-on effect of one busy step slowing down everything after it.

What a simulation can actually tell you

A well-built simulation gives a team several specific things. It gives a baseline for cycle time, expressed not as a single average but as a spread, showing what a typical case experiences and what a slower case experiences. It gives a picture of throughput, how many cases the process can realistically complete in a given period given its current staffing and step durations. It gives a view of utilization, showing which roles or steps are consistently busy and which have spare capacity. And it gives a way to spot where queues build up, which is often more revealing than looking at which step takes the longest in isolation.

• A distribution of cycle times, not a single average figure
• An estimate of throughput under current staffing and demand
• Utilization levels for each role or resource in the process
• Visibility into where queues form and how large they typically get
• A view of how often rework or exceptions occur across a realistic case mix

What simulation does not do

It is worth being clear about the limits. Simulation does not tell you whether a proposed automation is technically feasible against your systems and data. It does not read historical event logs from your systems the way process mining does, it works from a model built with clarifying input from the people who run the process. It does not guarantee a saving or a specific improvement figure, because any projected outcome depends on the assumptions fed into the model, and those assumptions should be treated as estimates that a team has reviewed and approved, not as facts.

Where Processfix fits

Processfix builds this kind of model from a plain-language description of a process or from an existing SOP or process definition document, using clarifying questions to fill in the gaps and an editable swimlane editor so the process owner can correct anything the initial draft got wrong. Once the model reflects reality, Processfix runs a discrete-event Monte Carlo simulation across hundreds of cases to establish a locked baseline, then lets a team test Improve and Add AI scenarios against that baseline and compare cycle time, throughput, utilization, bottlenecks, and estimated value before anyone commits to a change. The answer that comes out of that comparison is not always AI, and it is not always automation either. Sometimes it is a smaller process fix that the simulation makes visible for the first time.