Your Changeover Saving Is a Claim Until You Can Point at the Column

A sequence-dependent setup matrix can be completely configured, saved, and doing nothing at all, and there is no error message when that happens. The lookup finds no cell, falls back to the old flat number, and the schedule looks exactly as it did before. Anyone who reported a changeover saving after installing it reported an estimate, not a result.

EDGEBIC by User Solutions writes the reason for every setup time onto the scheduled row, which turns that estimate into something you can audit in a couple of minutes. This post covers what the column records, the specific misconfiguration it catches, how to run a coverage audit on a month of work, and what the audit does and does not prove. It sits under the EDGEBIC results guide.

Why setup savings are unusually hard to verify

Most scheduling improvements announce themselves. Move a job and the Gantt moves. Add a shift and capacity goes up. The change is visible.

Changeover is different for two reasons. The first is that a setup time is not a thing that happens on a report, it is a number added to an operation, and the operation looks identical whether the number came from a matrix or from a field somebody typed in 2019. The second is that changeover savings are usually claimed as a difference from a counterfactual: what the sequence would have cost if we had not sequenced it. Counterfactuals are exactly the kind of number that survives review without being true.

So the useful question is not how much did we save. It is a narrower one that can actually be answered: for how many of our scheduled operations is the setup time now the real transition rather than an average?

What the column records

When the engine schedules an operation on a work center that has a setup matrix, it looks at the job that last ran on that machine, looks up the cell for this work center and that from-product to this to-product, and adds the result. Then it records why, in the Setup Reason column of the Job View.

There are seven values, and each one means something different about your data:

The two rows that decide whether your project worked are Matrix (family) and BOR default. The first says the machine is being scheduled against real transitions. The second says it is being scheduled against a number that predates the whole exercise.

The silent failure the column exists to catch

There is one documented condition that produces a fully configured matrix which never fires: a family cell only applies when both the previous product and the next product have a setup family assigned.

Assign Widget-A to Light Colors and forget Bracket-B, and the Widget-A to Bracket-B transition finds no cell. It does not error. It does not warn. It falls back to the routing step's setup time, and the row reads BOR default.

This is easy to create by accident and effectively invisible without the column. The families tab shows your families. The matrix tab shows your cells. Both look complete. The gap is on the Product Families tab, one dropdown at a time, and it only shows up in the plan.

The fix is either to assign the family on both sides or to add a product-level override for that specific pair. The point here is not the fix, which takes seconds, but that nothing else in the system will tell you it is needed.

The audit, in about twenty minutes

Pick one matrixed work center and one month of scheduled operations.

1. Open the Job View and show the Setup Reason column.
2. Group the month's rows on that work center by the column's value.
3. Read three shares: matrix-driven (Matrix product, Matrix family, Same product), legitimately cold (Cold start, which should be rare and should appear at the beginning of a plan or after a genuine gap), and fallback (BOR default, WC default).

Suppose the booth ran 60 operations. Forty-one read matrix-driven, six read Cold start, and thirteen read BOR default. Those thirteen are the finding. Each is being charged an averaged number rather than its real transition, which as the documentation puts it makes the schedule wrong in whichever direction you did not average for. Thirteen of sixty is 22 percent of that machine's operations, and repairing them is a data-entry job measured in minutes.

Now take the correction on the rows that do fire. On the documented paint booth day, three jobs charge 30 minutes cold start, 60 minutes for Light to Dark, and 240 minutes for Dark to Light: 330 minutes of changeover in a day. The flat plan it replaced claimed 90 minutes and promised a 12:45 finish. The missing four hours did not vanish when the matrix arrived. They were always being worked. They were simply appearing on the floor rather than on the plan, which is why the booth had a reputation for overrunning and the schedule had a reputation for being fiction.

What the audit proves, and what it does not

It proves coverage, not savings. A high matrix-driven share means your setup times are now real. It does not by itself mean you are working fewer changeover hours. That comes from sequencing, which is a separate decision covered in how EDGEBIC cuts changeover hours and in the generic treatment at setup family sequencing in a job shop.

It cannot validate your numbers. If somebody entered 60 minutes for a transition that really takes 150, every row will read Matrix (family) and every one will be confidently wrong. The column proves the lookup fired, not that the value was right. Checking the values is a floor conversation, ideally the same one that produced them: coming from X, how long to start Y.

It does not survive a routing change on its own. Add a product and nobody assigns it a family, and you are back to silent fallback for every pair it participates in. This makes the audit a recurring check rather than a one-time sign-off. Quarterly is usually enough on a stable catalog, and it belongs in the same review as work center rates.

Historical rows are not evidence about the future. Completed operations keep the setup they actually had, which is correct and also means they tell you about the plan that existed then, not the configuration you have now. Audit scheduled work, not finished work.

Why this is worth doing at all

Because improvement projects that cannot be checked get abandoned, and usually for the wrong reason. A plant that collects changeover data, builds the matrix, sees no change in the schedule, and concludes that sequence-dependent setup was overhyped has almost always hit the family-assignment gap and never found out. The data collection was the expensive part and it is now sitting in a table that nothing reads.

Two minutes with one column separates that outcome from the one where the work pays off. User Solutions has been building finite capacity schedulers since 1991, and the recurring lesson is the same in every module: the number a plant trusts is the one it can trace. The setup ladder in full, with the configuration steps, is in how to set up sequence-dependent setup times.

The takeaway

Read the Setup Reason column before you report a changeover saving. Matrix-driven rows mean the transition is real, BOR default rows mean it never left the old flat number, and the gap between those two shares is the honest status of your project. If you want a second opinion on your own data, bring a month of scheduled operations from your worst changeover machine to a walkthrough of EDGEBIC and we will run the coverage split with you.