When People Are the Constraint: Labor-Limited Scheduling

A capacity model that only counts machines is describing half a shop. The other half is the people who run those machines, and in a large share of real production environments, the people — not the equipment — are what actually caps how much work can get done in a day. A schedule that respects every machine’s calendar perfectly and has no concept of who’s available to run them isn’t a complete model of the plant; it’s a model of the equipment sitting idle in an empty building.

Two independent constraints, not one

The core idea in labor-constrained scheduling — sometimes called dual-resource-constrained scheduling in the operations-research literature — is simple to state and easy to underestimate: an operation needs both its machine and enough available labor, at the same time, for its full duration. Neither resource substitutes for the other. A free machine with no operator to run it can’t produce anything; a free operator with no open machine can’t either. Both conditions have to hold simultaneously, for the whole span of the operation, or the operation can’t run.

This is a genuinely different kind of constraint from the ones covered in Modeling Real Capacity, not a variation on them. Machine capacity and labor capacity are tracked independently, checked independently, and can each independently become the thing actually limiting the plant — sometimes on the same day, on different work centers.

Fractional operators

People rarely map to machines one-to-one. A common, entirely ordinary pattern: one experienced operator tends three ovens at once, checking each periodically rather than watching any single one continuously. Modeling that operator as “fully consumed” by any one oven would be wrong in both directions — it would overstate how much labor that oven actually needs, and it would hide the fact that the same operator is simultaneously a real constraint on the other two.

The honest way to model this is a fractional draw: that operator contributes roughly a third of their attention to each oven, so each oven’s operation draws 0.33 of an operator rather than a full 1.0. Fractional draws aren’t a simplification for the sake of easier math — they’re what’s actually happening on the floor, and modeling it any coarser (whole-operator increments only) either wastes labor capacity that was never really needed, or hides an overcommitment that whole-number rounding would paper over.

Crew pools shared across work centers

Labor rarely belongs to just one work center either. A more realistic model groups operators into a pool — a named crew whose headcount is available to be drawn against by every work center the pool is assigned to, rather than each work center having its own permanently dedicated staff. A five-person welding crew shared across three welding bays is a pool of 5, and any bay drawing from it competes with the other two bays for the same five people, not for a private allocation nobody else can touch.

This pooled structure is what makes fractional draws add up correctly: three ovens each drawing 0.33 of “an operator” only means something if all three are drawing from the same shared pool, whose total available headcount the fractional draws are checked against in aggregate — not three separate, disconnected 0.33 claims that never get reconciled against each other.

A worked example

Three ovens, one shared operator, each oven’s routing calling for 0.33 of that operator’s attention per bake. Individually, none of the three bakes looks like a problem: each one needs a third of one person, and one person is available. Run all three at overlapping times and the pool’s total draw is 0.33 + 0.33 + 0.33 = 0.99 — just barely inside the pool’s capacity of 1.0 operator. Add a fourth bake to the same window, on a fourth oven the shop happens to have spare, and the draw becomes 1.32 — over the pool’s capacity, even though every individual oven is still, on its own, “just fine.” The fourth bake doesn’t fail because of anything wrong with oven four; it fails because the shared pool it draws from is already fully committed by the other three.

A schedule built without a labor pool concept has no way to catch this. It sees four free ovens and four available time slots and calls the plan valid. Only a model that sums the pool’s draws across every operation touching it, for every overlapping moment, can tell the difference between “four ovens are free” and “four ovens are free, but only enough labor exists to run three of them at once.”

Why labor constraints hide until the whole schedule is viewed together

Here’s the trap that catches shops modeling labor for the first time: any single operation, looked at in isolation, can look perfectly fine. The oven exists, it’s free at the proposed time, the routing says one operator is needed — nothing about that one operation, viewed alone, raises a flag. The problem only becomes visible once every operation drawing from the same labor pool at the same time is added up together. Three ovens each individually “fine” can collectively demand 1.0 operator-equivalent’s worth of attention at a moment when the pool has only 0.8 available, because two other operations elsewhere — on completely different machines, in a completely different part of the routing — are drawing from the identical crew at the identical hour.

This is why labor constraints are, almost by nature, a whole-schedule phenomenon rather than a per-operation one. A planner scanning operations one at a time, machine by machine, can miss an overdrawn crew pool that becomes obvious the instant every operation’s labor draw is summed across the whole plant for that hour. It’s the same shape of problem as any pooled, shared resource — the individual draws look small; the aggregate is what actually binds.

Signs the real constraint is labor, not machines

A handful of symptoms point toward labor, rather than equipment, being the shop’s actual limiting factor:

• Machines sit idle with no mechanical reason. A press, an oven, or a cell goes quiet not because it’s broken or because there’s no work queued for it, but because nobody is free to run it. If idle time consistently correlates with crew availability rather than order volume, that’s a strong signal.
• Cross-training changes throughput more than equipment investment does. If training a second operator to run a machine measurably increases output faster than buying a second machine would, the constraint was never really the equipment.
• Overtime on people, not machines, is what actually expedites a rush order. If the honest lever for “can we pull this in” is calling in an extra shift of labor rather than running equipment harder or longer, labor was the binding resource all along.
• The bottleneck seems to move with the crew schedule, not the product mix. Bottlenecks and Theory of Constraints covers why the tightest constraint can wander — in a labor-constrained shop, it often wanders with shift coverage and vacation schedules rather than with which products are running.

None of this is a case against investing in equipment — plenty of shops genuinely are machine-constrained. It’s a case for checking the assumption rather than defaulting to it, because a schedule built only around machine capacity, in a shop whose real limit is people, will keep promising dates the crew — not the equipment — can’t actually deliver.

Related reading

• Modeling Real Capacity: Shifts, Calendars, Efficiency, and Parallel Machines — the machine-side capacity model that labor constraints sit alongside, not inside.
• Bottlenecks, Drum-Buffer-Rope, and Theory of Constraints — why the plant’s real constraint can be a resource other than a machine.
• Sequence-Dependent Setup: The Changeover Matrix Explained — another shared-resource cost, changeover time, that only adds up correctly at the whole-schedule level.
• In Microsoft Dynamics 365 Business Central: Work Centers, Machine Centers, and Shop Calendars: BC’s Capacity Model — standard BC’s capacity hierarchy stops at machines; it has no separate object for tracking labor as its own constrained resource.