Process mapping or process simulation? What each one can do

Table of contents+

What a process map achieves

It is usually underrated by people who want to compute. A shared picture:

• ends arguments about reality. Two departments describing the same process differently only notice at the diagram.
• makes responsibility visible. Swimlanes show handovers, and handovers are where cases get stuck.
• is the basis for documentation, training, audit and software development. A computational model is useless for that.
• costs almost nothing and comes out of a workshop, not a project.

The common forms differ less than their advocates claim:

The value stream comes closest to computation: it carries waiting times and inventories. But it measures them on one day for a typical case and therefore says nothing about the peak day.

What appears in no map

Four inputs, regardless of notation:

1. Arrival volume and its variation. "120 cases a day" and "180 on the first of the month" appear in no diagram.
2. Spread of processing durations. A box labelled "10 min" is an average. The queue, however, comes from the range, not the mean.
3. Capacity per role. Three people times seven productive hours. Without that number there is no utilisation.
4. Calendar and cost. When work happens, and what an hour in that role costs.

Without these four, no diagram can be computed, whichever tool opens it. That includes BPMN with a simulation module: there too you enter these values in separate dialogues, see BPMN simulation.

The four questions a picture fails

"Where is the constraint?" In a diagram every box looks the same. The constraint is the step with the highest utilisation, and utilisation is not a property of the picture.

"How long does it take in the bad cases?" A diagram has no distribution. It cannot know the difference between P50 and P90, and commitments are made against the P90.

"What happens if we automate step 3?" In the picture a box disappears. In reality the full volume hits the next step, and the constraint moves there. This knock-on effect is the most common reason automation projects miss their numbers.

"What is that worth in money?" That needs volumes, durations and rates, plus the queue, which holds a large part of the cost.

When a map is enough

Not every process needs a computational model. A map suffices when:

• nobody waits. If the process runs well below capacity, processing time is lead time. Then addition is more honest than simulation.
• the goal is documentation. Audit, training, onboarding, evidence obligations.
• the process is being newly designed and nobody has numbers yet. Draw first, collect numbers, then compute.
• the decision is already made. A model built to justify a decision already taken is not analysis but decoration.

From picture to model: the route

The transition costs less than most assume, provided you resist the urge to transfer the diagram one to one.

1. Consolidate coarsely. A documentation-grade map has thirty activities; a computational model needs five to ten. Merge what the same role does in sequence.
2. Reduce branches to the real ones, with a share per edge, not with every special case.
3. Add aborts. Everything that leaves the process (rejected, withdrawn, abandoned). Maps almost always omit them; in computation they are decisive.
4. Obtain the four missing inputs. This is the actual work: about two hours for a mid-sized process.
5. Compute and check with Little's Law. Work in progress ÷ daily throughput against the computed lead time.

Budget twenty minutes for the transfer and two hours for the data. Anyone who knows those proportions stops treating the diagram as the expensive part.

Side by side

The practical rule: both, but in sequence and not in the same artefact. A diagram meant to be documentation and computational model at once is too fine for one and too coarse for the other.