Freeze the Sequence, Optimize Around It

The sequence was decided before the software arrived

The day's production sequence is usually settled before any scheduling tool is opened. The planner already knows what follows what, and in which direction: the changeover from a light shade to a dark one is quick, the reverse takes much longer; the allergen-free families run first, then the rest; orders that share a delivery window stay together. Most of this never lives in the planning system. It is operational knowledge held by the planner, and on a changeover-heavy line with parallel machines per stage, it is not a preference; it is the working plan.

Software that wants your sequence

The mainstream pitch for scheduling software is re-sequencing: hand over the plant and the tool will find a better sequence, one that reduces total production time. On the lines this post is about, that pitch collides with three realities.

The changeover matrix is directional, per-machine knowledge the planner carries: the time from any product to any other. Some sequencing is a compliance decision: allergen-free runs before allergen-containing runs, validated washes between families, cleaning windows that no one schedules across. And grouping runs into family campaigns amortizes cleaning between incompatible products. A tool that reorders jobs freely can improve its own view of the schedule and still produce one the planner cannot run, because the reorder breaks the constraints that make the line legal, clean, and committed to its customers.

Freeze the sequence, optimize around it

The claim this post defends is simple: on these lines, the right test for scheduling software is not how well it reorders your jobs. It is how well it minimizes total production time within the sequence you hold. Keep it. Let the software own machine assignment and timing around it.

Freezing the sequence has a real downside. The scheduling literature exists because reordering saves time, sometimes a great deal of it. Those gains are real, and freezing a weak sequence gives up part of them. The planner holds the sequence anyway, because they own the constraints that cannot be computed: compliance sequencing, campaign structure, commitments to customers sharing a line.

"Freeze" needs to be precise, because three different things get called frozen:

The master-schedule horizon has been frozen for decades as production-planning doctrine. The execution sequence is what this post argues the planner keeps. Machine assignment and timing, by contrast, is exactly what should stay open: it is the part software is good at.

The real risk is a frozen-but-untimed sequence

The obvious counter-argument: freeze the sequence and you build hidden idle time. A sequence that looks good on one bottleneck can strand parallel machines: a line left waiting for work while a parallel line queues. The answer is that this is exactly why the boundary sits where it does. The planner freezes the sequence; the software owns assignment and timing. A frozen-but-untimed sequence is a risk; a frozen sequence with software-owned timing is the point. Parallel machines per stage are what make the split non-trivial: with several lines or filling heads per stage, the sequence does not decide the timing. Who runs what, when, and on which machine is a second decision, and that is where the optimization lives.

How much time is on the table

To make the trade-off concrete: a published study of a herring-salad line measured changeovers at 28 percent of annual available line time: 536 of 1,928 hours, against 47 percent actual production. The same study reports that a Single-Minute Exchange of Die (SMED) program cut changeover time by 34 percent and gained about 11 percent of line capacity. No source contains a controlled frozen-versus-free comparison, so read this as the size of the prize, not a verdict on freezing.

The point is simple. On a line where changeovers consume more than a quarter of the available time, the sequence, which product follows which, and the timing, when each job runs and on which machine, can each move total production time materially. That is why the boundary between them is the decision that matters, and why "who owns what" is the question to ask of any scheduling tool.

One honest note: that same plant reported excess capacity of 49 percent at peak demand and 75 percent in normal periods, a demand-side measure, not a share of line time. Slack can reduce the urgency of sequencing decisions, but it does not settle them. The plant still made changeover reduction its first lever, because its slack was seasonal: short shelf life meant it could not simply build inventory.

The governance dial: Semi-Auto in the middle

This is where the mode model comes in, and it is the answer to the governance question this post started with: the planner decides whether the sequence is a constraint at all. Schantt implements that decision as a dial with three positions.

At one end, Auto mode. The sequence is not a constraint: the scheduling algorithm decides it, the machine assignment, and the timing, with the objective of minimizing total production time.

In the middle, Semi-Auto mode. The planner enters products and quantities in a fixed production sequence, and the algorithm preserves it exactly. It optimizes machine assignment and timing around it, deciding which machine runs each job and when, to minimize total production time. Sequence-dependent changeovers, entered as directional per-machine times from one product to another, are folded into that objective. In Semi-Auto the algorithm manages them by moving jobs across machines, never by reordering. A per-job earliest start is a planner lever that does not break the sequence, and machine eligibility keeps assignment limited to machines that can actually run the product.

At the other end, Manual mode. Every decision is user-authored: position, product, quantity, stage, machine, start, and end. No optimization runs.

Choosing the mode is drawing the governance line. Nothing here enforces an allergen sequence, a family block, or a color ladder; those are the planner's rules, and the modes implement the boundary the planner chooses. A one-way preference such as light-to-dark sequencing is encouraged, not enforced, through asymmetric changeover times: the discouraged direction carries a longer changeover, so the objective rewards the preferred sequence without commanding it.

Freeze length and cadence are the planner's dial

How long to freeze and how often to refresh are planner decisions, not software settings. In practice that means re-running the schedule with an updated fixed sequence at a cadence the planner chooses: daily, per shift, or whenever the sequence changes materially. The freeze is the sequence you hand over; everything else re-optimizes on each run.

Not every line needs this argument. On near-sequence-independent lines, where changeovers are quick and uniform, neither freezing nor sequencing carries much weight. This post is deliberately scoped: changeover-heavy, sequence-dependent flowshops and hybrid flowshops, with parallel machines per stage. Convergent and divergent topologies, where products merge or split across the line, are a different problem and are not covered here.

What to ask your scheduling software

When you evaluate scheduling software for a changeover-heavy line, the questions follow from the argument:

• Does it preserve the sequence you give it, or treat it as a suggestion?
• Within that sequence, does it own machine assignment and timing, minimizing total production time?
• Can you draw the governance line per situation, with the sequence fully free, fully fixed, or fully manual, without changing tools?
• Can you refresh at your own cadence, feeding in an updated fixed sequence whenever you choose?

The claim this post defends is a single one: the planner decides whether the sequence is a constraint at all. Software that optimizes around that decision, handling assignment and timing within a sequence the planner owns, earns its place on the line. Software that insists on taking the sequence away is asking for a job the planner is not giving up.