Process flow analysis and queueing theory — how work moves through a system, what determines its throughput, and why waiting lines form even when a process isn't "overloaded" on average. These are interactive versions of the calculators I built for this course, with the idea behind each one, not just the formula.
The single most useful identity in process analysis: it relates how much is in a system, how fast things move through it, and how long each one stays — and it holds true regardless of variability, arrival patterns, or how complicated the process is inside.
It's really just a units identity — jobs = (jobs/time) × time — but its power is that it holds for any stable process, no matter how messy the internals are. Know any two of the three and the third is fixed.
The rate at which jobs enter and exit a process (jobs/time).
How long a single job spends in the process, start to finish.
How many jobs are inside the process at any given moment — accumulated work, not yet finished.
The maximum average throughput the process can sustain — set by its slowest resource.
Throughput ÷ Capacity. Always less than 1 for a stable process — a system run at exactly 100% utilization has no slack to absorb any variability.
Choose which quantity to solve for, then edit the other two — the third updates instantly.
When stages run one after another, the whole process can only go as fast as its slowest stage — the bottleneck. Everything downstream of the bottleneck ends up starved, and everything upstream ends up backed up.
Capacity is set entirely by the bottleneck stage — speeding up any other stage does nothing for throughput. Cycle time, on the other hand, is the sum of every stage, bottleneck or not, since a job has to pass through all of them.
Add a row for every stage in the line and enter its processing time. The bottleneck stage is highlighted automatically.
Two ways multiple resources can sit side by side in a process: an AND split, where every job needs work from both resources before it can move on, and an OR split, where each job is routed down exactly one of several paths.
Both resources work on the same job at once (e.g. two technicians prepping different parts of one unit in parallel). The job can't move on until both finish, so the slower of the two sets both the pace and the wait.
Each job takes exactly one path, never both — so the two resources' capacities simply add together. Jobs are assumed to be routed in proportion to each path's share of total capacity, which keeps both paths equally utilized; in steady state with both paths always busy, there's always exactly one job in each path, so Little's Law gives cycle time as 2 ÷ capacity.
Useful whenever arrivals and processing don't happen at the same time — a delivery truck unloads all at once, then a warehouse works through the pile at its own pace. Plotting inventory over time turns "how much backlog builds up, and for how long" into a simple area-under-the-curve question.
Inventory accumulates at the build rate while building, drains at the process rate once processing starts, and never goes below zero. Edit the rates and timing to see how the curve — and the backlog it implies — changes.
Average inventory = area under the curve ÷ total hours shown — the same trapezoidal-area logic as the spreadsheet, just computed continuously.
Little's Law tells you WIP once you know throughput and cycle time — but it can't tell you cycle time from scratch. Queueing formulas fill that gap for processes with randomness: even a resource running at 70% utilization can develop a long line, purely because arrivals and service times aren't perfectly regular.
The number of customer arrivals per unit time.
The average time between arrivals. .
The maximum number of customers one server can process per unit time.
The average time to process one customer. .
The percentage of available capacity actually being used: , where m is the number of servers.
Variability of arrival times (Ca²) or service times (Cs²), relative to their mean: . Higher SCV means less regular timing — and, all else equal, longer queues.
This is the "VUT equation" in disguise: expected wait = a Variability term (how irregular arrivals and service are) × a Utilization term (how close to capacity you're running — this term explodes as ρ → 1) × a Time term (how long service itself takes). The core insight of queueing theory lives in that utilization term: waiting time doesn't rise proportionally with utilization, it rises explosively as utilization approaches 100%.
The m = 1 case of the same formula — this is the standard Kingman approximation. Setting Ca² = Cs² = 1 (both arrivals and service exponentially distributed) recovers the classic M/M/1 queue exactly.
Once you have the wait in queue, total cycle time just adds the service time itself, and Little's Law converts each time quantity into the corresponding inventory (jobs waiting, or jobs in the whole system — waiting plus the ρ·m jobs expected to be in service at any moment).
Works for a single server (m = 1, the G/G/1 / Kingman formula) or multiple identical parallel servers (m > 1, the G/G/m approximation). Set both SCVs to 1 to see the classic M/M/1 / M/M/m result.
The (1−ρ) term in the denominator means wait time isn't linear in utilization — it curves sharply upward as ρ approaches 1. Going from 80% to 95% utilization hurts far more than going from 50% to 65%, even though both are +15 points.
The Ca² and Cs² terms mean that even a lightly loaded resource can develop meaningful queues if arrivals or service times are irregular — variability, not just average load, drives congestion.
Combining separate queues into one shared line feeding multiple servers (m > 1) generally reduces average wait versus the same servers each running their own separate queue, because idle time at one server can absorb a spike at another.