Software that computes your process instead of drawing it

1. Which step limits throughput? Not the one people complain about loudest, and not the one that takes longest. The constraint is the step with the highest utilisation ρ = demand ÷ capacity. At 85 % utilisation a case already waits 5.7× its own processing time; at 95 % it waits 19× — the arithmetic is here.

2. How long does it take in the bad cases? An average answers no commitment. Promise "three days" because the median is three days and you break the promise half the time. What matters is the P90 — the value nine out of ten cases stay below.

3. Where does the constraint move once I fix it? This is where spreadsheet business cases fall apart. While review runs at 114 % utilisation, the approval behind it looks relaxed — it barely receives anything. Fix review, and approval takes the full volume. The saving that was in the spreadsheet never arrives.

4. What is a change worth in money? Not "faster", but a number with provenance: staff cost per case, cost of waiting, cost of rework — before against after, with a range.

When you are in the wrong place here: designing a production line, a warehouse, an emergency department or a terminal calls for a simulation lab. Transport logic, setup matrices and experiment designs are deliberately absent. Governing 300 processes with approval workflows calls for a BPM suite.

The full comparison, including the limits of each category, is in the article Process simulation software: four categories.

Cases arrive one at a time. Not 120 a day as a flat number, but drawn from a distribution with variation, peak probability and peak factor. The damage happens on the five worst days of the quarter, not in the mean.

Every step has capacity and a processing range. Capacity either as people × hours per day, or as a flat takt where a machine sets the limit. Processing from–to, not as a point value — the spread is the actual information, because it is what creates the queue.

The run is repeated hundreds of times. Each repetition draws fresh random values. The distribution of results becomes the band: P10, P50, P90. Why a single number is useless here is covered in Understanding P10, P50 and P90.

Coupling is part of the calculation. A step never sees more cases than the slowest step ahead of it lets through. That is exactly why the constraint moves once you fix it — and exactly what no spreadsheet can do.

Utilisation  ρ  =  demand ÷ capacity
Waiting time Wq ≈  ρ/(1−ρ)  ×  (ca² + cs²)/2  ×  te

The second line is the approximation every simulation result can be checked against. If simulation deviates strongly from it, the difference sits in the coupling or in the calendar — and that belongs in the explanation, not swept aside.

• No process mining. FlowVisual does not measure the past from system logs. It computes an assumption — which is why it needs no event log, and equally why it says nothing about what actually happened. If you have an event log and want to know what happened yesterday: mining tool. If you want to know what happens once step 3 is automated: simulation.
• Not a BPMN tool. Six building blocks instead of a notation. Anyone who needs standards-compliant process documentation will not get it here — see BPMN simulation for the boundary.
• Not an architecture repository. One process per model, not the whole organisation at once.
• No factory design. No transport logic, no setup matrices, no experiment designs, no shift models with handover rules.
• No prettier picture. It does not draw better than Visio. It computes.

1. Open a template instead of starting empty. Quotation, invoice approval, complaints, onboarding and IT ticket ship with the app. Thirty seconds to see what a finished model looks like — which saves you from building your own too finely.
2. Draw the flow. Start, steps in real sequence, decisions only where a case genuinely branches, an abort for everything that leaves the process.
3. Enter volumes, durations and costs. Daily volume with variation, per step capacity and processing from–to, plus role, system and hourly rate. Compute a fully loaded rate: gross salary × 1.5 to 1.8, divided by roughly 1,500 productive hours.
4. Watch before you compute. Does it really work like this? Those two minutes with the department save the argument about the result.
5. Run the stress test. The top bar is your constraint; one click opens that step in the inspector.
6. Save the baseline, change exactly one lever, compare. Without a baseline there is nothing to compare, and with three simultaneous changes nobody knows which one worked.
7. Export. Proposal (PDF) for the decision maker, documentation (PDF) for traceability.

Steps 1 to 6 are free. The long version with checklists and the five expensive mistakes is in the guide.