Flow Analytics
Flow Analytics answers the two questions a Lean review starts with: is this process keeping up, and where's the constraint?
Start with the verdict
The banner at the top gives the whole process one verdict, with how many replications agree. An activity gets a verdict too, using the same words.
| Verdict | What it means | What to do |
|---|---|---|
| Kept pace | Output matched demand throughout; backlog stayed bounded. | The process copes. Check that cycle time is acceptable too. |
| Spare capacity | Kept up easily with the system near-empty. | Look for capacity you could release. |
| Fell behind | Backlog only cleared after work ran out, not by keeping pace. | Treat it as a warning. The process only recovered because demand stopped. |
| Overloaded | Output never caught up; backlog never cleared. | Look at the constraint table before anything else. |
| Inconclusive | Not enough signal to judge keeping-up vs. draining. | Try a longer run or more replications. |
Keeping up is judged up to the last arrival: what arrived before then against what had left by then. The order that arrives last is still being worked on at that moment, so it doesn't count against the step. A steady process reads Kept pace or Spare capacity however few orders it handles (changed 2026-11-03: before, a steady step that saw fewer than 20 orders could read Fell behind).
Read the agreement count too, such as 4 / 5 runs. Low agreement means the picture changes from run to run, so don't act on one verdict alone. If your model has more than one entity type, the banner names the type that set the verdict, and that's the one to look at first.
Where's the constraint?
This table ranks activities, worst first. Rank 1 is the place to look first.
| Column | How to read it |
|---|---|
| Rank | Worst first. Activities with an identified constraint come before the rest. |
| Verdict | Whether this activity kept up with the work sent to it. |
| Constrained by | What limits it. See the next table. |
| Time per visit | Average time an entity spends at this step, request to release. |
| Reps agreeing | How many replications gave this verdict. Higher means a more reproducible finding. |
| What if? | A Study button that sweeps the capacity behind this constraint. |
Constrained by: the column that saves you money
This is where simulation earns its keep. A step can look like the bottleneck when the real limit is the staff or equipment it needs.
| Constrained by shows | What it means | What will help |
|---|---|---|
| A resource name, then (resource) | Entities held a slot here while waiting for that resource. Adding capacity to this step will not help. | Add capacity to the resource, or reduce the demand on it. |
| Own capacity | The step's own capacity is saturated, at 85% utilization or above, and the resource has slack. | Add capacity at the step, or shorten its processing time. |
| Own capacity + a resource name | Both limits hold. Relieving one alone will not move throughput. | Change both together. Use a study with See changes combined. |
| — | Nothing here is saturated. | Look elsewhere. A capacity sweep here may not move the result. |
When rank 1 is limited by a resource, a headline above the table names the resource and the share of time entities spent waiting for it.
Three kinds of waiting
An entity can lose time at an activity in three ways. Each points somewhere different. You can see them on a Data table card for activities.
| Metric | What it says | Where to look |
|---|---|---|
| Queue time, per entity | Entities stand in line because this step is full. | This step is the limit. |
| Resource wait, per entity | Entities are in the step but waiting for a person or equipment. | The resource. More step capacity does nothing. |
| Blocked time, per entity | Entities have finished but can't move on, because the next step has no room. | The next step. This step is a victim, not the bottleneck. |
The throughput diagram
The chart beside the table is a throughput diagram. It plots cumulative arrivals into the process and cumulative completions out of it. The gap between the two lines is your work in process (WIP).
- Lines running together: the process keeps pace.
- Gap widening: work is piling up.
- Gap closing only at the end: the backlog cleared because arrivals stopped.
Hover over the chart for the arrived, completed and WIP counts at that moment. Where the chart can match them, you also see one entity's arrival, completion and cycle time.
Below it, the same chart appears for the top three ranked activities. Each one shows whether that step fell behind, and when.
Flow summary
| Row | What it means |
|---|---|
| Completed entities | Entities that reached the end of the process, per replication. Consumed, split and disposed entities are not counted. |
| Mean WIP | Average work in process: entities in the system, time-averaged over the run. |
| Flow time | Average time an entity spends in the system, arrival to exit. It's the same idea as cycle time for the whole process. |
More than one entity type
When a model has several entity types, an Entity type picker appears, and Flow by entity type shows how each one fared. This is how you see that routine visits are fine while urgent ones fall behind.
If a model joins, splits or creates entities, one combined curve would miscount. Quodsi then shows the entity type that set the verdict, and you can pick another. Helper entities are left out of the process verdict.
Go from finding to test
Press Study on a row. Quodsi opens a new what-if, pre-filled from the scenario you're viewing, and it follows the constraint:
- A row limited by a resource sweeps that resource's capacity.
- A row limited by its own capacity sweeps the activity's capacity.
- A row with both sweeps both.
The range comes from your lever if you've set one. Otherwise it starts one step above the current capacity and goes up to about double, and it stays small: at most about ten scenarios. The button is off for anything that follows a work schedule, because its capacity can't be swept.