Bottleneck-First Planning Only Works When the Bottleneck Is Modeled as Finite

"Find the bottleneck, then schedule around it." It is a common piece of scheduling advice, and the
load-bearing part is usually left out. The method comes from the theory-of-constraints tradition:
identify the constraint, exploit it, subordinate everything else. That tradition is not the problem.
The problem is what happens when the constraint stage has no numbers behind it.

The method already presumes a quantified constraint

Bottleneck-first planning was never "pick a stage and call it the constraint." The exploit step only
means something when you know the constraint's rate, its available time, and what disrupts it. The
drum in drum-buffer-rope is the constraint stage, and its rate sets the pace for the plant. The
buffer is a sized quantity, computed from the disruption it has to absorb. The rope controls what
is released into the system. Every moving part of the method is a number.

A planner who cannot answer "what is the constraint stage's real capacity, and when can it run?" is
not practicing the method. They are applying a label to a guess.

The spreadsheet load plan treats the constraint as infinite

The place where the premise usually breaks is the planning surface. A spreadsheet load plan
aggregates demand onto each stage at an average rate. It has no working windows, no downtime, no
per-class cycle, and no state for upstream material. Demand is stated without regard to the stage's
capacity limits. In the industry's own vocabulary, that is infinite loading: requirements computed
without regard to what the work center can actually do.

Infinite loading is latent while load sits under real capacity. It becomes visible exactly when load
approaches that capacity. Work arriving at a stage whose real service rate is below the arrival rate
accumulates, and queues and wait-material pauses grow where the plan was not looking. The bottleneck can also
shift: when product mix changes, or a different stage's availability drops, the real constraint
moves. A plan that fixes the constraint from average load or memory can point the whole method at a
stage that stopped being the constraint long ago.

What "modeled as finite" actually requires

A bottleneck-first schedule survives contact with real load when four questions are answered about the
constraint stage, plus a fifth that is easy to overlook.

First, what is the stage's real rate or cycle? Not an average across products, but the rate for the
products actually running: a flow stage at its true line speed, a batch stage at its true batch
cycle time.

Second, when can the stage actually run? Working windows come from calendars and their exceptions,
and the schedule should advance by working time, so a job that cannot finish before a shift ends resumes
next shift rather than running through the night.

Third, what removes its capacity? Downtime for maintenance, breakdowns, and outages should be
subtracted from working capacity before the schedule is built, so the timing routes work around the
outage instead of pretending the stage ran through it.

Fourth, does upstream material arrive in time? When a downstream stage runs out of material before
more arrives, the schedule should show the wait-material pause where the starvation sits, not silently extend a
bar. In a hybrid flowshop, where some stages run several machines in parallel, the same question
applies at every handoff between stages.

The fifth term is changeover. On a crowded constraint stage, the setup time between consecutive jobs
is part of the load. Sequence-dependent changeovers on a specific machine fold into each operation's
start time, so the changeover load on the constraint stays visible.

Where these are modeled, the planner can read occupancy and waits directly off the schedule and perform
the locate-the-constraint step on evidence. Where they are not, the schedule is a wish about a stage that
was never quantified.

What this means for the planning tool

The planning surface either carries the constraint's finite capacity or it does not. That decision,
not the advice, is what carries the promise.

A tool that models each machine's per-class rate or batch cycle, that schedules against real working
windows, that subtracts downtime before scheduling, and that shows wait-material pauses when upstream
supply starves a stage, gives the bottleneck-first planner what the method presumes: a constraint
with numbers. The planner's job becomes deciding which stage is the constraint, and the schedule makes
that decision testable, because occupancy, queues, and idle time at every stage are visible.

No tool identifies the bottleneck for you. The step stays with the planner, and that is fine. What a
tool can do is stop the identification from being a guess about a stage that was never modeled.

Keep the method, verify the model

None of this says bottleneck thinking is wrong. Constraint focus is a legitimate way to direct
improvement where it pays first. The claim is narrower: the method's promise depends on the model
behind the bottleneck.

So before trusting the plan, check your planning surface against the questions above. Does it carry
the constraint stage's real rate or cycle? Its working windows? Its downtime? The supply that feeds
it? The changeover load on it? If the answer to any of them is no, the bottleneck-first plan you are
looking at is only as good as the spreadsheet it was loaded into. When the constraint is modeled as
finite, the method finally has something to work with.