Branches and loops: why simple sums are wrong
As soon as a process has a decision or a loop, not every case runs through every step, and some steps run more than once. The correct way is to give every step its expected number of visits per case and multiply its times by that number. Adding up every box overstates the lead time; following only the main path understates it.
The worked example
The invoice check example has 1,000 invoices a month. Accounts payable enters each invoice (6 minutes processing, 60 minutes waiting beforehand) and checks it (4 minutes). At the decision "Complete?" 80% go on and 20% go back to the supplier with a query. The supplier takes 2,400 minutes, five working days, to answer, after which the invoice is checked again: a rework loop. Complete invoices reach the decision "Amount above €5,000?". 30% need an approval by division management (5 minutes processing, 1,440 minutes waiting), 70% go straight to posting (5 minutes processing, 120 minutes waiting).
There are two common shortcuts for this process, and both are wrong. Before reading on, it helps to know the difference between processing, waiting and lead time from Lead time calculation.
Mistake 1: adding up every box
Adding all times on the diagram gives 20 minutes processing (6 + 4 + 5 + 5) and 4,020 minutes waiting (60 + 2,400 + 1,440 + 120), a lead time of 4,040 minutes or about 8.4 working days. This assumes every invoice goes back to the supplier and every invoice needs an approval. Neither is true.
Mistake 2: following only the main path
Ignoring the branches gives enter, check and post: 15 minutes processing and 180 minutes waiting, 195 minutes in total. This assumes no invoice is ever incomplete and none needs an approval. It is the figure a tidy happy-path diagram suggests, and it is far too optimistic.
The correct way: visits per step
Each step gets the average number of times a case passes it. At a decision the case splits by the shares; at a loop it can return. For the check step, every invoice is checked once, 20% are checked a second time, 20% of those a third time, and so on:
| Step | Visits | Processing per case | Waiting per case |
|---|---|---|---|
| Enter invoice | 1 | 6 min | 60 min |
| Check invoice | 1.25 | 1.25 × 4 = 5 min | 0 min |
| Query to supplier (wait) | 0.25 | – | 0.25 × 2,400 = 600 min |
| Approve invoice | 0.3 | 0.3 × 5 = 1.5 min | 0.3 × 1,440 = 432 min |
| Post invoice | 1 | 5 min | 120 min |
| Total | 17.5 min | 1,212 min |
Queries at a step versus rework loops
The app offers two ways to model "something is missing". A rework loop is a connection back to an earlier step, as in the invoice example; the steps in the loop are repeated, 1 ÷ (1 − q) times on average for a return share q. Every connection that closes a loop counts as a rework loop, no separate flag is needed. Use it when the case really goes back through steps that are drawn in the diagram.
A query at a step is quicker to enter: a query rate, the extra effort per query and the extra delay per query. The step is not repeated; it only costs more and takes longer. Each visit of the step then adds rate × effort to processing and rate × delay to waiting. In the request example, "Check request" takes 10 minutes after 240 minutes of waiting; in 25% of cases the clerk has to ask the applicant, which costs 8 minutes of work and 960 minutes (two working days) of waiting. Per case the step therefore takes 10 + 0.25 × 8 = 12 minutes of processing and 240 + 0.25 × 960 = 480 minutes of waiting. With the decision step (15 minutes, 60 minutes waiting) the request takes 27 minutes of processing and a lead time of 567 minutes.
Parallel branches
A parallel gateway is different from a decision: every outgoing branch runs, and the merge waits for all of them. For the lead time only the longest branch counts, because the others run at the same time; the processing time on this time-determining path also goes into the processing share. For the processing time per case and for cost every branch counts, because someone does the work in each of them. A process with parallel branches therefore has a lead time shorter than processing time per case plus waiting; without parallel branches both processing figures are the same. In the order processing template, picking and invoicing run in parallel.
Share without queries, and loops that never end
Besides times, loops change quality figures. The share of cases without queries or rework is the probability that a case passes without going back and without triggering a query at any step. In the invoice example it is 80%; on average there are 0.25 queries and loops per case. That metric adds visits × query rate over all steps and the passes of the rework loops.
A loop needs an exit. If the shares at a decision send cases back with 100%, no case ever leaves, and the process cannot be calculated. The checks report this as an error and point to the loop. Use the lead time calculator to see how a query share changes visits and lead time, and the process cost lesson for what the visits do to the cost per case.
Try it in the editor
Invoice check (worked example) · 1,000 / month
The worked example opens with exactly these steps, shares and times, so you can compare every figure in the table with the app.
Open the example in the editorFrequently asked questions
Why does the lead time use average visits instead of a worst case?
Weighted with the average number of visits, the figures describe the average case across all paths and add up correctly over many cases, which is what cost per year and staff demand need. Each step counts with its typical time. The range from best to worst case is calculated separately from the minimum and maximum times you enter; if the mean of the ranges shifts utilization, staffing or cost noticeably, the app shows it as a second figure.
Does a loop of 50% really double the work?
Yes for the steps inside the loop: 1 ÷ (1 − 0.5) = 2 visits on average. Steps outside the loop are not affected.
Can I check the numbers by hand?
Yes. The app shows the calculation for each metric, and the visits per step are visible on the step when they differ from 1. The table in this lesson is the same calculation the app performs.
Should I model a query as a loop or as a query rate?
Use a loop when the case visibly goes back through steps in the diagram. Use a query rate when the clarification happens within one step and only adds effort and waiting time.
Self-test
Keep learning
Would you like to map or improve a process together with us? Contact