Stage Interaction Is Why Local Dispatch Rules, and the Tools Built on Them, Fail in Hybrid Flowshops

Every stage's schedule can be defensible and the line can still finish late. The mixer runs the short jobs first because they clear the queue fastest. The filler follows the same logic on its own queue. The critical customer job waits behind short jobs at both stages, and nobody made a bad decision. Each local call was reasonable. The schedule the line ended up with is not.

This is the pattern that local dispatch rules cannot escape in a hybrid flowshop. The rule is not bad at its job. It simply cannot see the stages around the one it serves.

What a local dispatch rule actually decides

A dispatch rule, sometimes called a priority rule, answers one question at one queue: which job does this stage or machine take next? It can use the shortest processing time, the earliest due date, the sequence jobs arrived in, or any of the variants in the literature. The operations research literature catalogued over a hundred of them by 1977, and the list has grown since.

What makes them useful is also what limits them. A rule needs only the information visible at the queue it serves. It never sees downstream congestion, upstream material availability, or which machine at the next stage will be free when a job arrives. For a single machine with a single queue, that is often enough. For a line of stages, it is not.

The mechanism: stages interact, and local decisions do not add up

In a flowshop, one stage's output is the next stage's supply. The sequence in which jobs leave a stage sets when the next stage receives them and how much material it holds at any moment. A hybrid flowshop adds a second coupling: each stage may hold several parallel machines, so the line decides not only the sequence but also which machine each job runs on. These decisions are not independent. They pass effects into one another.

The flow shop anomaly literature makes the point directly. A 2020 analysis by Panwalkar and Koulamas showed that in a flow shop, reducing a single operation's processing time, removing a job, or even removing a machine can make the overall schedule worse. Schedules that forbid a machine standing idle, a job waiting between stages, or a stage delaying its start make these anomalies more likely. A local change sends its effect through the stages around it, so improving one operation in isolation is not a sound step.

A concrete example shows the effect. Two stages, one feeding the other. The downstream stage runs a shortest-processing-time rule, so it pulls the short jobs off its queue first. A long job waits while the short jobs cycle through. Upstream, the feeder keeps supplying whatever the downstream queue drains, because that is all its own rule can see. The long job slides later at every stage, and every job behind it slides too. Each stage is doing exactly what its rule says. The line is doing the wrong thing.

Changeover timing shows the same interaction. When changeover time depends on the sequence, a stage that sequences its jobs to minimize its own changeovers can hand the next stage a sequence that adds changeovers there. The first stage saved time it never sees again, and the second stage pays for it. Optimizing one stage's changeover time is not optimizing the line's.

The cost: a tool that ignores interaction inherits the blindness

A scheduling tool built on local dispatch rules does not fail because its rules are crude. It fails because it shows the planner the same queue-local view and calls it a finished schedule. The planner sees each stage's schedule, each defensible, and no place where the line's real problem shows up.

What the planner does not see is what the interaction costs. Downstream stages starve while a critical job waits upstream. Buffers grow because stages are fed in the sequence their own rules prefer, not the sequence the line needs. Total production time creeps up, and the schedule is committed before the pattern becomes visible.

The gap is measurable. In a 2020 study of a real two-stage hybrid flow shop with sequence-dependent changeovers, a simulation-based optimization approach produced better schedules than the standard dispatching rules that plants commonly run. The result is case-specific, and no general percentage should be read from it. That direction is what matters: on a real hybrid flowshop, coordinating decisions across the line beat deciding each queue locally.

What whole-line scheduling changes

Whole-line scheduling does the opposite of a dispatch rule. Instead of answering one queue at a time, it decides the production sequence, the machine assignment, and the timing together, and lets a simulation of the full route arbitrate the result. The simulation is the key. It walks each job through its stages and sees the interactions the rules cannot: when a downstream stage runs out of material, the schedule shows a wait-material pause instead of hiding the stall inside a defensible-looking queue.

This changes what the planner can see and do. Downstream starvation shows up as wait-material pauses on the schedule, so it stops being invisible. Changeover grouping now serves total production time rather than one stage's setup time. Machine assignment is coordinated per stage, and in a mode that fixes the production sequence it still optimizes assignment within it, so plants with an operationally fixed sequence are not forced to re-sequence to get the second axis.

It is not a general factory optimizer. The whole-line view lives inside a modeled constraint set: the stages, machines, calendars, changeovers, and transfer times the plant actually entered. The single objective is total production time. It does not weigh cost against time, it does not enforce due dates, and it does not model routes that converge or diverge. Within that modeled line, the decisions are made together, and the interactions between stages are part of the decision.

The takeaway

A local dispatch rule is a good answer to a single queue. It is not a good answer to a line, because in a hybrid flowshop the stages are coupled, and a queue-local decision cannot see the coupling. Tools that build their schedule from these rules inherit that blindness, and the cost shows up as starvation, buffers, and a longer total production time.

When you evaluate a scheduling tool, ask one question: does it see the whole route, or one stage at a time? If it schedules each stage against its own queue, it has already made the decision that defeats the schedule. The tool that coordinates the sequence, the machines, and the timing across the line addresses the problem the plant has.