One Line Speed Is a Myth in a Hybrid Flowshop: Why Capacity Lives at the Stage Level

It is a familiar planning habit: one number per product, a rate in units per hour, applied unchanged to every stage of the route. The habit is understandable. On paper the machines of a line get lumped into a single pool, so a rate feels like a property of the line itself. But in a hybrid flowshop no single machine carries a product from start to finish, and no single number can represent the line. It survives on paper. It fails on the floor.

What the averaged plan gets wrong

A plan built from one average rate mispredicts. In the spreadsheet it looks feasible: the averaged number, scaled by the quantity, fits the available time. Then the floor disagrees. One stage sits with machines waiting, another stage grows a queue of work in front of it, and nothing in the model explains why. The reason is that flow time runs on utilization and variability, not on average processing time alone. Two lines can share the same average per-product rate and still behave differently, because their capacity is balanced differently across stages. The average hides the utilization of individual machines and the variability around their rates, and those are exactly the quantities that decide how long work really takes.

A hybrid flowshop has no single line speed

Here is the correction. In a pure flowshop, every product passes through one machine per stage in the same sequence, and a single rate per product is at least a plausible abstraction. A hybrid flowshop relaxes that structure: it is a sequence of stages, and at least one stage runs several machines in parallel. Capacity is therefore a per-stage property. Each stage owns its own machine pool, each machine runs a given product class at its own rate, and a schedule holds only when machine assignment is resolved stage by stage against each stage's actual capacity. Three consequences follow, and each one shows up on the floor.

Every stage owns its own machine pool

Consider a route that mixes, fills, and packs. The mixing stage might run two mixers, the filling stage four fillers, and the packing stage three packing machines. There is no line-level machine to assign work to. Assigning a job to a machine is a decision that exists only inside a stage, because every machine belongs to exactly one stage and does that stage's work. Machine counts differ from stage to stage. A filling stage might be sized for the variety of containers it handles, a mixing stage for the cycle of its mixers. The pool is a property of the stage, not of the line.

Rates belong to a machine and a product class, not to a line

Two machines in the same stage can run the same product class at different rates, and one machine can run two product classes at different rates. A stage's pool is really a set of class-restricted sub-pools: only the machines that can actually run a class are candidates for it, and a machine with no rate entry for a class is not a candidate. Per-machine changeovers make the differences operational: the time a filler takes to switch classes is specific to that filler and to the direction of the switch.

Take one filling stage with three machines running two product classes. The rates, in containers per hour, might look like this:

No single number survives. Class 1 runs at 120 containers per hour on one machine, at 90 on another, and not at all on the third. Class 2 runs on two of the three machines, at different rates on each. Any average across these cells is a number that no machine, no class, and no stage will ever actually produce. An averaged plan treats those differences as noise; the floor treats them as the schedule.

One nuance applies to every rate above: not every stage runs continuously. A batch stage produces in cycles, and its rate is a batch cycle: a batch size and a cycle time that together say how long one batch takes and what it yields. A batch reactor feeding a packaging line is a batch stage followed by a flow stage, and the two are not measured the same way. The per-stage story survives the nuance: a batch stage still has its own pool, and each machine in it still runs each class at its own cycle.

The constrained stage sets the pace

In a serial line, what the line can actually produce is governed by the stage whose pool and rates throttle the route. When the schedule does not match that stage's real capacity, work piles up at its machines and the stages downstream wait for material. Which stage binds is not a fixed fact about the plant. The constrained stage cannot be a label stamped on the line once. It is a property of a resolved schedule, and it has to come out of the assignment rather than sit next to it.

What a stage-level model looks like

A stage-level model stores exactly that structure, and nothing more. A flow stage carries a throughput in units per hour; a batch stage carries a batch size and a batch cycle time. Each machine belongs to exactly one stage, and batch or flow is a property of each stage, so one route can run a batch stage and a flow stage back to back.

The scheduling algorithm then resolves machine assignment stage by stage. In Auto mode it decides the production sequence and the machine assignments. In Semi-Auto mode it keeps a fixed production sequence and optimizes the machine assignments within it. There is no line-level number in this model: rates are entered per machine, per product class, at each stage, and nothing is entered for the line itself. The absence is the argument. A hybrid flowshop cannot be represented by a single speed, and the model does not pretend otherwise.

Where a single rate is legitimate

Where a stage's machines are genuinely identical and the line is balanced, a single rate is a legitimate simplification, and none of this critique applies.

What the planner does next

So here is what you do. Enter rates per machine and per product class at each stage. Keep batch and flow stages distinct, because they are measured differently. Then let the scheduling algorithm resolve machine assignment stage by stage. The schedule that comes out is built from the same structure the floor actually has: per-stage pools, per-machine rates, and a production sequence that respects both. It holds because it was never forced through one number.

What this means for the plant manager

For the plant manager, the practical difference is what the schedule is built from. A scheduler that models capacity stage by stage takes its timing from the stage whose pool and rates actually throttle the route, rather than from one number for the line. Which stage that is follows from the assignment and the mix, so it can differ between schedules. Capacity conversations stop being about a number on a spreadsheet and start being about which stage is binding in the current schedule, and why.