The Changeover Debt Hiding in Your SKU List

The line that could not justify its own upgrade

A national deli-meat processor came to the table to decide whether to automate a part of the business that had been struggling for years. On paper the case looked obvious: a chronic second-shift crewing problem in a union plant, real demand, and equipment that could carry the load. Then the operations lead said the quiet part out loud. "We have such a broad variety of products that all the parts needed for all the changeovers makes it not make any sense." The ROI would not pencil. Not because the machines were expensive, but because the new line would spend its added hours in setup.

So the plant was doing the opposite of buying capacity. A side team was working to consolidate products and cut variation, specifically so they would need fewer changeovers and less tooling. They had reached the right instinct from the floor: the constraint was not horsepower. It was the number of times the line had to stop being one product and start being another.

Changeover is a loan, and the sequence signs for it

Here is the mechanism. Every product a line runs leaves it in a state the next product has to undo. In food that state is concrete: an allergen flush, a sanitation cycle, temperature recovery on an oven or a fryer, a CIP loop, a tooling swap. That undoing is the debt. SKU variety is how a plant borrows against it, and a schedule with more transitions borrows more. The interest comes due as throughput you never see on a nameplate, because the machine was busy becoming the next product instead of making the current one.

This is why a faster machine so often leaves total output flat. Capacity was added to the run, not to the changeover, and the changeover is where the hours actually went. The three levers a plant thinks of as separate line items, changeover time, yield loss on the ramp back to rate, and the sequence that orders the day, are not separate at all. They multiply. Optimize one in isolation and the other two absorb the win. Injection molders know this as mold-change proliferation; commercial printers know it as plate and ink washouts between short runs. Same debt, different floor.

Price the interaction before you price the machine

The fix is not a better machine. It is a model that holds all three levers at once before any capital moves. When the same processor's line was put through an OEE simulation with changeover, yield ramp, and run sequence in a single model, it found roughly 14% throughput and $1.4M a year. The lever that produced it was sequencing and variation, not added speed. Run each factor separately and that number disappears, which is exactly why the standalone automation case had failed.

Three things a plant can do this week. First, total the changeover and post-changeover ramp hours straight off last quarter's run log, and put that number next to the capacity gain you are about to buy; if they are close, you are about to automate the wrong constraint. Second, count your tooling variants and ask which SKUs actually drive them, because a small tail of low-volume products usually carries most of the changeover load. Third, test a consolidated sequence inside the schedule before you test it with a purchase order. The same processor kept circling back to a 12% to 18% packaging-spend opportunity, and that was the identical insight from the input side: the product spec, not the machine, is what moves the floor. A second co-packer, a chicken-sausage and meatball maker that grew from small to large, was earlier on the same path, standing up line tracking to see its OEE for the first time. The first thing that data shows is almost never machine speed.

What a well-run sequence looks like

Changeover plus ramp runs under 12% of scheduled hours. Tooling variants are counted, owned by a named person, and trending down quarter over quarter. A new SKU carries an explicit changeover cost on the P&L before it is granted a line. And no capital request clears the gate without a sequence model behind it, so the plant never buys speed to solve a scheduling problem. When those four conditions hold, the schedule stops quietly borrowing against next month's throughput.

The automation was never really the question. The schedule had already decided the answer. The model just made the debt visible before the check was written.