How Setup Families Cut a Combinatorial Problem Down

Setup families reduce scheduling complexity by collapsing a product-by-product changeover matrix from thousands of cells to dozens: instead of one changeover value for every ordered pair of products, you maintain one value for every pair of families. A hundred products need about 10,000 pairwise cells, which nobody keeps accurate. Eight families need 64. EDGEBIC by User Solutions looks up the sequence-dependent changeover by family, with product-level overrides where a specific pair genuinely differs, so the changeover data stays small enough to maintain and accurate enough to schedule against. The families are what make sequence-dependent setup practical at all.

The plain definition is in the flagship what is a setup family. This post is about why the grouping matters mathematically, because the number of cells is the difference between a matrix you keep and a matrix you abandon.

The square-law problem

Sequence-dependent setup means the changeover time depends on what ran before. Going from white paint to black is quick; going from black back to white needs a long solvent flush. To capture that, you need a value for each ordered pair: from-product to to-product. With N products, that is N times N cells, minus the diagonal where a product follows itself.

The trouble is the square. Ten products is 100 cells, which is manageable. A hundred products is 10,000 cells. A thousand products is a million. The matrix does not grow with your product count; it grows with the square of it. Every new SKU adds a full row and a full column. At real product counts, filling in and maintaining that matrix by hand is impossible, so shops either skip sequence-dependent setup entirely (and lose the throughput) or build a matrix that rots because nobody can keep a million cells current.

Families collapse the square

A setup family is a group of products that change over the same way. Paint colors group by shade; alloys group by composition; parts group by the tooling they share. Changeover behavior is driven by these shared attributes, not by the individual SKU, so products in the same family really do behave alike at changeover.

Once products are grouped, you build the matrix between families, not between products. The changeover from any light color to any dark color is one value, filled in once, applied to every product in those families. The square law still applies, but now it applies to the family count, which is small and roughly constant even as your product count grows.

The right column barely moves while the left column explodes. That flat right column is the entire value of families: your changeover data does not grow with your catalog. Add your 501st product, assign it to an existing family, and you have added zero cells to the matrix.

The override keeps the accuracy

The obvious worry is that a small matrix loses the special cases. Families handle that with product-level overrides. The family matrix sets the default for the 95 percent of pairs that follow group behavior, and a specific from-product to-product override captures the handful of pairs that genuinely differ. So a family of "dark colors" might all behave alike except that one particular pigment needs an extra flush, and you record that one exception at the product level without rebuilding the whole matrix.

This is the resolution order the engine follows: check the product-level override first, fall back to the family default, and fall back again to the step or work center default if no family value exists. You get a maintainable matrix for the bulk of pairs and pinpoint accuracy for the exceptions.

Why this also helps the optimizer

The complexity reduction is not only about data entry. Finding the sequence that minimizes total setup across a queue of jobs is a genuinely hard combinatorial problem, closely related to the traveling salesman problem, where the "distance" between jobs is the changeover between them. The optimizer searches for a low-setup order, and it needs a changeover cost for every pair it considers. Families give it that cost cheaply and consistently, because the family membership is exactly the grouping signal that "run like with like" depends on. How the optimizer uses a changeover matrix to minimize setup is covered in how mathematical optimization improves a schedule and in campaign sequencing to minimize changeovers.

Without families, the optimizer would either need a full million-cell matrix it cannot trust or fall back to a single flat setup time that hides the sequence dependence entirely. Families are the middle path that makes least-setup optimization both accurate and tractable.

A worked example: paint booth with 80 SKUs

A paint booth runs 80 SKUs. A full matrix is 80 times 80, about 6,320 off-diagonal cells, which no planner will maintain. Sorted by shade, the SKUs fall into 8 families: whites, creams, light grays, mid grays, blues, reds, dark colors, and blacks. The matrix becomes 8 by 8: light-to-light is near zero, light-to-dark is short, dark-to-light is long. Sixty-four cells, filled in once, capture the sequence-dependent behavior of all 80 SKUs. Two special pigments that need an extra flush get product-level overrides. The engine now schedules changeovers accurately, and the optimizer can hunt for the light-to-dark ordering that minimizes total booth setup, all from a matrix a planner can actually keep current.

How that sequence-dependent setup then shapes the placed schedule is the subject of how sequence-dependent setup shapes a schedule, and the role of setup in overall lead time is in lead time as the sum of its parts. This is the same practical discipline behind 35-plus years of User Solutions schedules: keep the data small enough to trust, because a schedule is only as good as the numbers feeding it. The full engine pipeline is in the scheduling engine guide, and the basics of the schedule itself are in what is production scheduling. To build a family matrix against your own SKUs, see EDGEBIC on your data.