Capacity vs Throughput in Manufacturing Scheduling

Capacity is how many hours a shop could run; throughput is how many good units it actually ships. They are not the same number, and the gap between them is where most scheduling confusion lives. In EDGEBIC by User Solutions, capacity is what a work center offers and throughput is what the whole shop delivers, gated by its single slowest resource and eroded by setup and scrap along the way. A plant can be swimming in capacity on paper and still unable to ship more, because output is set by the constraint, not by the total. Knowing which number you are looking at is the difference between a fix that works and one that just grows work in process.

Capacity is an input, throughput is an output

Capacity is a property of a resource. A work center offers a certain number of hours per shift, and the plan draws against them. It is an input you configure and the engine reads.

Throughput is a property of the whole system. It is the rate of finished, good units leaving the shop, and it emerges from how all the resources interact. You do not set throughput directly. It falls out of the plan, limited by whichever resource is tightest.

The two get conflated because both are measured in the same breath, hours and pieces, but they answer different questions. Capacity answers "how much could we run?" Throughput answers "how much do we actually finish?" A shop that manages capacity as if it were throughput will keep adding hours in the wrong places and wondering why output stays flat.

Real capacity is already less than nameplate

Before capacity even meets throughput, it is smaller than it looks. Nameplate capacity is shift length times the number of machines. Effective capacity, the number the scheduler actually uses, is less.

A utilization percentage throttles how much of each shift is genuinely available for production, accounting for breaks, minor stops, and normal slack. Downtime and holidays subtract on top of that. So a work center with three machines and an eight-hour shift has 24 nameplate hours but, at 80 percent utilization, offers roughly 19 effective hours to the plan. That is the figure your schedule is built on, and it is the honest one. The mechanics are in how a scheduler calculates work center capacity, and the danger of pretending otherwise is in why 100 percent utilization is a trap.

Throughput is set by the bottleneck

Even effective capacity overstates what you can ship, because throughput is capped by the single most-loaded resource. That resource is the bottleneck, and it sets the pace for everything, as why the bottleneck sets the pace explains.

This has a blunt consequence. Adding capacity to any resource that is not the bottleneck does not raise output. It only lets that resource produce more parts that then queue in front of the constraint, which cannot process them any faster. Work in process grows, throughput does not. The only capacity that increases throughput is capacity at the constraint. A finite capacity plan makes this visible: it shows the constraint saturating while other resources sit with spare hours, which is the signal that tells you where a machine purchase would actually pay off. Finite vs infinite capacity scheduling covers why an infinite plan hides this entirely.

Setup and scrap eat the rest

Two more forces shrink capacity into throughput. Setup time is capacity that produces nothing: every changeover is hours the machine is occupied but not making good parts. On a busy resource, and especially a bottleneck, an hour of setup is an hour of throughput lost forever, which is why sequencing to reduce changeovers converts directly into output.

Scrap and yield loss shrink it again. If parts fail inspection, the good output is less than the units started, so some of the hours you spent produced nothing shippable. To ship the quantity you promised, you have to plan to make more than that, which consumes still more of the constraint's hours. Between setup and scrap, the finished throughput coming off a work center is meaningfully less than its effective capacity, before the bottleneck cap even applies.

A worked example

A four-step line, releasing plenty of orders, has these effective capacities per week:

Total capacity across the shop is 220 hours. It looks abundant. But the oven offers only 40 hours and is loaded to 40. It is the bottleneck, and throughput is set there.

Buy a second saw and Cut jumps to 120 hours of capacity. Output does not move, because every part still has to pass the oven, which is unchanged at 40 hours. All the second saw did was pile parts in front of the oven faster. Now add oven capacity instead, from 40 to 50 hours, and throughput rises, because the constraint loosened. Same money, opposite results.

And even the oven's 40 hours do not become 40 hours of finished output. If a changeover eats 4 hours and 5 percent of parts scrap, the good units shipped come off 36 productive hours minus the yield loss. Capacity of 40 became throughput of noticeably less. That gap is invisible in a capacity report and obvious in a shipment count.

Use the right number for the decision

The practical rule is to match the number to the question. When you ask "can I take this order?" you care about throughput at the constraint, not total hours, so look at the bottleneck's load. When you ask "where should I invest?" the answer is the constraint, because that is the only place capacity turns into output. And when you read a capacity report showing room while the shop cannot ship more, look past the aggregate to the bottleneck, the setup, and the scrap that are quietly converting your capacity into a smaller throughput.

Capacity tells you what the shop could do. Throughput tells you what it does. A good finite capacity plan shows you both and, crucially, shows you the one resource where the two meet. See where your own throughput is set in EDGEBIC, and follow how the engine builds capacity into a plan in the scheduling engine guide.