Sequence-Dependent Setup: The Changeover Matrix Explained

Sequence-dependent setup means the time it takes to prepare a machine for the next job depends on what ran on it last — not just on what’s coming next. A washdown between two food allergens, a solvent flush between a dark paint and a light one, a temperature ramp between two plastic resins: none of these costs a fixed number of minutes. They cost a number of minutes that depends on the pair — what you’re leaving, and what you’re walking into.

Most scheduling discussions treat setup as a flat tax: “every job needs 20 minutes of setup.” That’s true for machines where changeover really is constant — swap a tool, zero the fixture, go. But in a large share of real production — food, paint, plastics, pharma, printing, textiles — the changeover is a function of the transition, and ignoring that function is one of the most common ways a schedule quietly loses hours it never had to lose.

The From→To matrix

The standard way to model sequence-dependent setup is a changeover matrix: a grid where the rows are “coming from” and the columns are “going to,” and each cell holds the cost of that specific transition. If your shop tracks color, the matrix might have one row and one column per color; if it tracks allergen, one row and column per allergen category.

A few things distinguish a real changeover matrix from a rough approximation:

  • It’s per constraint dimension, not per item. You don’t build one matrix per product — you build one matrix per thing that requires cleaning or reconfiguration when it changes: color, allergen, resin family, spice level, whatever your shop actually washes down or retools for. A shop can track more than one dimension at once (color AND base, say), each with its own matrix.
  • Every cell is a real number, including the zero ones. A transition that costs nothing (white paint after white paint) is still a deliberate “0,” not a blank. Leaving a cell blank and letting the software assume zero is different from deciding it’s zero — the difference matters when someone audits the matrix six months later and can’t tell which was which.
  • It’s usually asymmetric. This is the detail that separates a matrix that reflects your shop from one that’s a rough guess, and it’s worth its own section.

Why the direction matters

Ask a planner to estimate “the changeover time between color A and color B” and most will give you one number. But walk the floor and you’ll usually find two different numbers depending on which direction you’re going.

Take a paint line running light colors and dark colors. Going from a light color to a dark one is close to free — a bit of the light pigment gets overwritten by the dark, and nobody notices. Going from dark to light is a different story: any dark residue left in the line shows up as a visible contamination in the light batch, so the changeover means a real solvent flush and often scrapping the first few liters that come through. Ten minutes one direction, thirty the other, on the same pair of colors.

The same asymmetry shows up everywhere sequence-dependent setup exists. A gluten-containing batch after a gluten-free one demands full sanitation before the gluten-free line can run again — but running a gluten product after a gluten-free one needs no special cleaning at all, because a trace of wheat flour in a wheat product isn’t a hazard. A mild spice blend picked up right after a hot one will taste of capsaicin residue; the reverse transition barely registers. In every one of these cases, treating the matrix as symmetric — assuming A→B costs the same as B→A — either wastes cleaning time it didn’t need to spend, or worse, understates a transition that actually needed a full sanitation cycle.

A matrix that only records “the changeover between A and B” and applies it in both directions isn’t a simplification of reality — it’s a different, less accurate model of a real phenomenon. The asymmetric matrix isn’t extra complexity for its own sake; it’s the minimum structure that reflects what’s actually happening on the floor.

Here’s what that paint-line example looks like once it’s actually written down as a matrix, with a third color added to show how the grid scales:

From ↓ / To →WhiteRedBlack
White0 min5 min (stir only)10 min (light overwrite)
Red30 min (flush + scrap first liters)0 min15 min (partial flush)
Black45 min (full solvent flush + scrap)20 min (partial flush)0 min

Read the grid by row, then column: the White row shows what it costs to leave white and move to each other color; the White column shows what it costs to arrive at white from each other color. The diagonal is always zero — a color never has to change over into itself. Every off-diagonal cell going “down and to the left” (into a lighter color) is expensive; every cell going “up and to the right” (into a darker color) is cheap. That lopsided pattern, not a single average number, is what a real changeover matrix looks like for any shop where contamination risk runs in one direction.

Why the savings compound

A single changeover looks like a rounding error next to an eight-hour shift. Thirty minutes here, ten there — who cares? The answer shows up when you count how many changeovers a bad sequence forces versus a good one across a whole shift, or a whole week.

Picture five orders on one line, each a different color, scheduled in whatever order they happened to arrive: red, then white, then black, then red again, then white again. That’s four transitions, and because the sequence bounces back and forth, several of them land in the expensive direction. Now sort the same five orders by color — all the whites together, then all the reds, then the blacks — and the same five orders might need only two transitions, both in the cheap direction. Nothing about the work changed. Only the order changed, and the shift picked up back an hour or more of run time that used to evaporate into washdowns.

That’s the case for sequencing at all. It’s also the trap sequencing alone falls into, which is where due dates come back into the picture.

The trap: optimizing sequence blind to due dates

A sequencer that only minimizes total changeover time will happily group every white job together and every black job together, because that’s the cheapest path through the matrix. But “cheapest changeover” and “meets every due date” are two different goals, and a plan that nails one can badly miss the other.

Picture one work center, one shift, and three orders: two are white, one is black. The black order is due today; the two white orders aren’t due for another week. A sequencer that only cares about changeover will run the two whites first — because white-to-white costs nothing — and push the black order to the end. Total changeover for the day: one transition. Total damage: the order that actually needed to ship today doesn’t, because it got scheduled last for a purely cosmetic reason.

Flip the priority the other way and you hit the mirror-image trap. Schedule strictly by due date with no color awareness, and the solver might sequence white, then black, then white again — because on paper, due date alone doesn’t care about color. That’s two full transitions instead of one, double the washout time, for no schedule benefit at all: the due-today order still ships today either way.

Only a plan that weighs both objectives at once — capacity and due dates together with changeover cost — can find the sequence that protects the due date and keeps changeover low, because that sequence usually exists. In the three-order example, running the black order first (hitting the due date) and grouping the two whites afterward is only one changeover, not two — the schedule that a due-date-only planner and a changeover-only planner would each individually miss. A tool that locks in the changeover-optimal order before it knows about due dates can’t discover that trade; a tool that schedules by due date with no color model can’t see it either. Only a solve that holds both at once can find it — and can only find it because it’s looking at both together, not because either objective is secretly more important than the other.

This is why sequence-dependent setup belongs inside the same solve as capacity and due dates, not off to the side as a separate pass that runs first and locks in an order nothing downstream can reconsider.

Sequencing as a routing problem

Under the hood, minimizing total changeover across a set of jobs on one machine is structurally the same problem as the classic “traveling salesman” puzzle: given a set of stops and a cost to travel between any pair of them, find the order that visits all of them for the least total travel. Replace “stops” with “jobs” and “travel cost” with “changeover cost” and it’s the identical shape — which is useful to know, because it means sequencing inherits both the good and bad news that comes with that problem. The good news: it’s well-studied, and exact solvers handle real-world-sized versions of it comfortably. The less convenient news: it’s the kind of problem where “obviously group similar things together” isn’t always the best answer once due dates, multiple machines, and shift boundaries all apply pressure at the same time — which is exactly why the trap above catches shops that sequence by hand or by simple sort.

Building a matrix your shop will actually trust

The math only helps if the matrix behind it is honest, and matrices go wrong in a small number of predictable ways:

  • Filling in the direction you think about and skipping the reverse. It’s natural to fill in “dark after light” because that’s the changeover everyone complains about, and to leave “light after dark” blank because nobody thinks about it. A blank cell reads as zero cost, so the sequencer will cheerfully alternate back and forth through the direction nobody bothered to price — the exact ping-pong pattern the matrix was supposed to prevent.
  • Tagging the finished good and forgetting the semi-finished item that actually touches the machine. If a mixing station blends a colored base before it ever becomes a labeled product, the base needs the same color tag the finished item carries — otherwise the changeover cost at the point where the color actually changes is invisible to anything reading the matrix.
  • One matrix trying to do the job of two. A shop that changes over on both color and allergen status needs two independent matrices, not one combined guess — color drives a stir-versus-flush decision, allergen drives a rinse-versus-full-sanitation decision, and collapsing them into a single number hides whichever dimension is cheaper to check.
  • Treating the matrix as something you fill in once. A process improvement that cuts a changeover — a new nozzle, a faster-draining tank — is real information the matrix should capture; a matrix from initial setup that’s never revisited quietly overstates changeover cost forever and biases every sequencing decision after it.

None of this is exotic. It’s the same discipline as any lookup table anyone depends on: fill in every cell deliberately, keep the dimensions that behave differently in separate tables, and revisit it when the process changes.

Where SmartFlow fits

SmartFlow APS ships a standalone Sequence Optimizer today: you declare the constraint dimensions your shop tracks (color, allergen, resin, whatever applies), tag each item with its attribute values, fill in the From→To changeover matrix — asymmetric, cell by cell — and the optimizer reorders jobs on a work center to minimize total changeover. It’s a real, working tool for the changeover half of the problem described above.

See Sequence Optimization and Changeover for how the tool works today, and Set Up Constraint Types, Product Attributes, and the Changeover Matrix for the field-by-field walkthrough.

This page explains changeover elimination inside the finite solve as a scheduling concept. Changeover elimination inside the finite solve is on the SmartFlow APS roadmap and is not enabled in the current production release. For what SmartFlow APS does today, see the User Guide.

Ready to see finite scheduling on your own data?

Support: support@dynamicspro.ca · 416-843-6575

Get SmartFlow APS on AppSource