How Finite Capacity Scheduling Handles a Shared Bottleneck

Finite capacity scheduling handles a shared bottleneck by booking it one job at a time, so every order that needs the constraint queues behind the ones already booked, in priority order, and the true wait to reach it becomes visible. The engine tracks the bottleneck's real capacity per shift and never double-books it, which turns a hidden pile-up into a queue you can plan around. EDGEBIC by User Solutions also identifies the constraint mathematically and can pin it with Theory of Constraints anchor scheduling so the rest of the plant subordinates to its rhythm.

Why finite capacity matters at the constraint

A bottleneck is the resource whose capacity is lowest relative to demand, and it sets the pace of the whole plant. What you do with a shared bottleneck depends entirely on whether your scheduler respects capacity.

Infinite capacity scheduling assumes a machine can run unlimited work at once. It stacks every job onto the bottleneck's timeline without checking whether the hours exist, so the plan looks feasible and the real queue is invisible until the shop floor discovers it. Finite capacity scheduling respects that a machine runs one job at a time. Contention surfaces as a real queue, and the constraint stops being a surprise.

Finding the constraint with a load factor

The engine does not guess which resource is the bottleneck. It computes a load factor for each work center in a routing:

load factor = demand hours / daily available capacity
            = (hours per unit x qty + setup) / (shift hours x instances x utilization)

The highest load factor is the constraint for that job. In a real five-step routing the numbers separate cleanly:

HeatTreat: (0.10 x 200 + 2) / (8 h x 1) = 2.75   <- the constraint
Mill:      (0.05 x 200 + 0.5) / (8 h x 1) = 1.31
Lathe:     (0.08 x 200 + 1) / (8 h x 2) = 1.06
Grind:     (0.06 x 200 + 0.5) / (8 h x 2) = 0.78

A load factor above 1.0 means the resource cannot absorb the day's demand in a single day; the oven at 2.75 needs nearly three days of capacity for one day of demand. That is the drum the plant marches to. For the fuller method, see production bottleneck identification.

How jobs queue on a shared constraint

Once the engine knows the constraint has finite capacity, the queue forms naturally. The engine sorts all orders once, by priority, then start date, then due date, and processes them in that order. The first job to need the oven claims the earliest available oven slot. The second queues behind it. The third behind that. Because a slot consumed by one job is gone for the others, the wait to reach the constraint is honest.

Say five jobs route through a single oven this week. Job with priority 1 hits it first; the priority-2 jobs follow in start-date order. The Gantt shows a real staircase of oven bookings, not five overlapping bars pretending to run at once. A planner can look at that staircase and know exactly which order will wait, and by how long, which is precisely the visibility a spreadsheet cannot give. The sequencing logic is covered in how a scheduler decides which job runs first.

Subordinating the rest of the plant

Seeing the queue is half the value. The other half is keeping the constraint fed so it never idles while work piles up in front of it. This is where Theory of Constraints subordination comes in.

You mark the bottleneck and set a target start date on its step. The engine then pins the constraint operation at maximum priority with a capacity-packing strategy, so no other job can steal the pinned slot. It back-schedules the upstream steps so they finish just in time to feed the constraint, and forward-schedules the downstream steps from the constraint's end. Optional buffers protect the plan: a constraint buffer before the anchor absorbs upstream variation, and a shipping buffer after it protects the due date.

The effect is that the whole routing serves the bottleneck's rhythm rather than each machine running at its own maximum. Upstream stops flooding the constraint with work in process; downstream picks up a steady feed. The difference between anchoring the constraint and simply right-aligning the order is covered in anchor scheduling vs plain backward scheduling.

When the constraint moves

A bottleneck is not permanent. Once you protect one resource and raise its throughput, a different resource often becomes the tightest. The load factor recomputes every run against the current quantities, so the engine flags the new constraint as it emerges. Chasing that moving constraint is the planner's ongoing job, and raising bottleneck utilization covers the levers, from instance counts to authorized overtime via a capacity override.

The takeaway

A shared bottleneck is only a problem when it is invisible. Finite capacity scheduling makes it visible by booking the constraint one job at a time and forming a real queue, then lets you protect it with an anchor so the rest of the plant subordinates to it. The full mechanism, from the shift-by-shift capacity search to the anchor path, lives in the scheduling engine guide. See your own constraint surface in the first scheduling run in EDGEBIC; the shops that watch that queue and plan around it are the ones that turn a bottleneck from a recurring crisis into a managed resource.