Step 3 of 8
FLOW · measure first
Observe — find the real bottleneck under stress
O is what separates this method from a costing exercise. L added things up; here the process is observed under load. The difference is not academic: a process whose mean handling times fit comfortably inside available capacity will still stall regularly at eighty to ninety per cent utilisation. Queues do not grow linearly.
The return on this step is often a correction. The step people complain about loudest is rarely the one that caps lead time — it is the one that hurts most visibly. Where the two coincide, that is a good sign for the model. Where they diverge, that divergence is the whole reason for simulating.
- Answers the question
- Which step actually blocks when things get tight?
- What the step produces
- A bottleneck probability per step, a lead time distribution (P10, P50, P90) for the process, and a utilisation figure per role. Exactly one step is named as the bottleneck.
How the step is carried out
Carry the model over from L
Same steps, same time ranges, same rate. A freshly built model makes the before-and-after in Y impossible, because two things would then have changed: the process and the way it is measured.
Enter capacity per role
How many hours is this role actually available to the process — not how many hours it works. This is the figure that later shows whether a person or a system is the limit, and the two cases call for completely different interventions.
Run the process hundreds of times
Monte Carlo: each run draws a duration for every step from that step’s range. After a few hundred runs you do not have a result, you have a distribution — and the distribution is the finding.
Count where it jams
For each run, record which step capped it. The share is that step’s bottleneck probability. One step at seventy per cent is the bottleneck; three steps at thirty per cent mean the model is too coarse.
Check it against expectation
Ask the people involved beforehand which step they believe is the bottleneck. If the simulation agrees, the model is corroborated. If it disagrees, explain the difference before going further — a contradiction nobody can explain is a modelling error, not a finding.
Finished when
- One step carries a markedly higher bottleneck probability than the others.
- P10, P50 and P90 of lead time exist, and P90 sits well above P50 — if it does not, the ranges collected in L were too narrow.
- Utilisation is known for every role.
- The question “why this step” can be answered in two sentences without opening the tool again.
The typical mistake
Working with averages
Assign each step its mean duration, add them up, and you get a lead time that almost never occurs in practice — and is usually far too short. The reason is queueing: when arrivals vary and handling times vary, work piles up even when there is enough capacity on average, and the closer utilisation gets to a hundred per cent the worse it gets. A spreadsheet cannot show this, because it holds one row per step.
No calculator for this step
There is no free calculator for this step, and that is not a gap in the range but a property of the task: a questionnaire can estimate, it cannot simulate. That is what FlowVisual is built for.
FlowVisual is the instrument this method uses where a questionnaire stops: draw the process, run it hundreds of times, read which step blocks. It is a separate product on its own domain — Flowrefy owns the method, FlowVisual owns the instrument.
The step, worked through
The sample analyses report a bottleneck probability per step — that column comes from this step. Read together with role load, it shows whether a person or a system would be the limit.
The analyses are constructed models, not client projects. Their figures show what a measurement would look like — they are not results achieved for anyone.
- Sample analysisAN-2026-08
The sales lead who shows up as two boxes
A packaging printer measures the path from incoming order to order confirmation. The bottleneck is the credit check. The second finding is a role two steps share, and it only becomes an action once the first one is dealt with.
- Sample analysisAN-2026-07
The loudest process in the building is not the most expensive
An engineering consultancy wants to digitalise leave requests. The measurement agrees with the complaint and still not with the investment. The process is slow, but cheap.
- Sample analysisAN-2026-06
The €500 approval limit nobody has touched since
A plastics processor has every purchase above €500 signed by the managing director. The limit is old, the prices are not. Four out of five orders pass through a gate that opens twice a week.
Questions
A few hundred are enough for the ranking of bottlenecks to settle; robust P90 values want a few thousand. The practical test is simple: two runs with different seeds must produce the same ranking and similar percentiles. If they do not, there were too few.
Then either the model is too coarse — too few steps, ranges drawn too wide — or the process genuinely has no single bottleneck but a uniformly high base load. The second case is rare and usually leads to a “do nothing” in W: fixing one of eight equally loaded points barely moves lead time.
Process mining reads what actually happened and needs system traces to do it. Simulation computes what would happen and needs only a model with ranges. For processes that run in spreadsheets and mailboxes — that is, most of the expensive ones — there are no traces to read. Where both are possible they complement each other: mining supplies the ranges the simulation needs.
If you want to know what your process costs: measure it.
Start with the free diagnosis or download FlowVisual. If you want to speak to someone afterwards, we're reachable.
Remote · fixed price · result in euros