SMED or Product Mix Design? Fix Long Changeovers

The first mistake is treating every long changeover like a SMED problem#

A 42-minute changeover can be a setup problem, or it can be a product mix problem wearing a setup problem’s clothes. That distinction matters because SMED work only helps if the time is actually inside the setup, not buried in a schedule that keeps forcing the same resets over and over.

That is the real question operations teams keep circling: How do you tell whether a long changeover should be fixed with SMED-style work or whether the real issue is product mix design that forces too many unavoidable resets? If you get that wrong, you can spend weeks shaving minutes off a changeover and still miss output every Friday because the line is being asked to bounce between incompatible products.

In Remote / nationwide plants, and in places like Danville, California where a lot of small and mid-sized manufacturers run lean staffing and tight schedules, this shows up the same way. The supervisor sees downtime, the CI lead sees waste, and the plant manager sees missed ship dates. Everyone is looking at the stopwatch. Fewer people are looking at the product family logic.

Start by splitting the changeover into three buckets#

Before you run a SMED workshop, map one real changeover at the floor level and split every minute into one of three buckets:

1. Internal setup work
   The machine is stopped, and something has to be done while it is stopped.

2. External work that is being done internally
   Material staging, paperwork, tools, labels, QA signoff, cleaning supplies, first-piece paperwork. This is classic SMED changeover analysis territory.

3. True resets
   Purges, sanitation, recalibration, recipe changes, fixture swaps, label verification, line clearance, vision system re-teach, temperature stabilization, or any step that exists because the next product genuinely cannot run under the previous settings.

That last bucket is where people get fooled. A lot of teams label something “necessary” because it has always been there. That is not the same as unavoidable.

Key takeaway: If the “necessary” reset is not tied to a machine limit, a quality rule, or a documented customer/spec requirement, treat it as a design problem until proven otherwise.

The fastest way to tell if the reset is real is to ask for the source#

When half the changeover is spent on unavoidable resets, don’t ask the operator if it is necessary. Ask where the requirement comes from.

The answer usually falls into one of four places:

• Machine constraint
  Example: a filler, die, mold, cutter, or printer physically cannot transition without a purge, recalibration, or tooling change.

• Quality or regulatory requirement
  Example: FDA, SQF, HACCP, allergen control, GMP, lot traceability, or a customer spec that requires line clearance, documented first-article approval, or sanitation verification.

• Product design constraint
  Example: different bottle necks, carton sizes, film gauges, resin types, colors, viscosities, or tolerances that force real setup changes.

• Historical habit
  Example: “We’ve always done a full clean between these two SKUs,” even though the spec, risk, and equipment have changed.

That fourth category is where long changeover reduction usually hides. If you hear “that’s just how we run it,” keep digging. In manufacturing, “just how we run it” often means nobody has challenged the sequence since the last capital project.

If you want a clean way to structure that review, the operations diagnostic guide approach is useful because it forces the team to separate observed work from assumed work before anyone starts proposing fixes.

The real test is not whether the reset exists, it is whether the reset changes with mix#

A good SMED changeover analysis does not stop at “this step takes 6 minutes.” It asks whether that 6-minute step appears on every product, only on certain families, or only when the schedule bounces between incompatible SKUs.

That pattern tells you a lot.

If the reset happens on every job#

You probably have a true setup problem. That is where SMED methodology pays off:

• pre-stage tooling
• convert internal to external work
• standardize clamps, fittings, and change parts
• use checklists and point-of-use storage
• parallelize tasks between operators

If the reset happens only on some products#

You may have a product mix design issue. The line is being asked to absorb the cost of too many variants, or the portfolio has too many one-off specs that create unavoidable resets.

If the reset only gets worse when the schedule alternates back and forth#

That is often sequencing, not setup. The line may run fine in family batches, but the planning logic keeps alternating difficult products because the scheduler is chasing due dates, not setup efficiency.

That is the point where the question becomes: How do you tell whether a long changeover should be fixed with SMED-style work or whether the real issue is product mix design that forces too many unavoidable resets? You look for repeatability. If the reset cost moves with the sequence more than with the machine, the schedule is part of the problem.

Use three numbers, not one stopwatch#

Stopwatch data matters, but it is not enough. Experienced teams usually need three measurements before they decide whether to spend on setup work or product mix redesign:

Metric	What it tells you	What to watch for
Changeover time by SKU family	Whether a reset is tied to product design	Large swings between families point to mix issues
Changeover time by sequence	Whether the schedule is creating the pain	A-B-A is often worse than A-A-B
Output lost per changeover per week	Whether the downtime is actually costing throughput	Shorter setups that still create the same number of resets may not improve output

If you only measure average changeover time, you can fool yourself. A plant can cut the average from 38 minutes to 29 minutes and still lose the same number of hours if the schedule keeps forcing 14 changeovers instead of 8.

That is the most common mistake I see in long changeover reduction work. The team optimizes the process inside the changeover, but the product mix still creates the same reset count. The stopwatch looks better. Throughput does not.

The question to ask about every “necessary” reset#

When a team says a step is unavoidable, I want them to answer this:

What would have to be true for this reset to disappear?

That question forces specificity. It usually produces one of these answers:

• “Nothing, the machine needs it.”
  Fine. That is a real constraint.

• “We would need to run the same family together.”
  That points to product mix design or sequencing.

• “We would need to change the spec.”
  That is a product design or customer-commercial issue.

• “We would need to get QA to approve a different control method.”
  That is a quality process issue, not a setup issue.

• “We have never tried.”
  That is not a constraint. That is an assumption.

If you want a practical litmus test, compare the reset against the six stages in SCOR, especially Make and Enable. If the reset exists because the process itself requires it, that is one thing. If it exists because the information flow, approval flow, or change control flow is bloated, that is a different fix entirely.

Don’t confuse SKU proliferation with hard setup#

This is where plants waste the most time.

A line with 120 SKUs is not automatically a changeover problem. Sometimes it is a portfolio problem. Too many variants, too many low-volume orders, too many custom labels, too many packaging combinations, too many special runs. The machine is only the place where that complexity cashes out.

The same thing happens in light manufacturing and in multi-site fulfillment operations. A production supervisor sees repeated resets, but the root cause is often upstream, in demand planning or commercial promises. The product mix has been designed to satisfy every customer request individually, so the floor inherits a schedule full of resets it cannot escape.

That is why I would not decide on SMED alone. I would ask:

• Which SKUs account for most of the changeover minutes?
• Which SKUs account for most of the changeover count?
• Which resets are tied to actual technical limits?
• Which resets exist only because the schedule alternates incompatible products?
• Which variants could be batched, standardized, or eliminated?

If the answers point to the portfolio, you have a product mix design problem. If they point to the machine, you have a setup problem. Sometimes it is both, but one usually dominates.

The schedule can make a good line look broken#

A line that runs A-A-A-B-B may look stable. The same line running A-B-A-B-A can look like a disaster. Same machine. Same operators. Same change parts. Different mix logic.

That is why the question is not only How do you tell whether a long changeover should be fixed with SMED-style work or whether the real issue is product mix design that forces too many unavoidable resets? It is also, “What did the scheduler do to create this pattern?”

If the answer is poor sequencing, the fix may be as simple as family batching, frozen windows, or a rule that groups high-reset products together. If you need a framework for that decision, Freeze vs Flex: When to Lock the Schedule is the right companion piece. A lot of changeover pain is really schedule churn in disguise.

A simple decision rule that holds up on the floor#

Use this when you are standing in front of the line with the supervisor and the planner:

Choose SMED when:#

• the same reset appears on most or all products
• the task can be standardized, staged, or parallelized
• the machine is waiting on people, tools, or information
• the changeover steps are real, but they are not all truly internal

Choose product mix redesign when:#

• the resets are tied to product families, not the machine itself
• the schedule alternates incompatible SKUs too often
• the line is carrying too many low-volume variants
• the customer promise or commercial policy is forcing one-off runs

Choose both when:#

• the line has genuine technical resets, and
• the planner is making those resets happen more often than necessary

That last one is common. The plant in Danville, California may have a perfectly reasonable changeover for each family, but if the schedule is bouncing between families every few hours, the operation still loses.

What experienced teams do before they spend capital#

Good teams do not jump straight to a new machine or a six-week SMED event. They run a short diagnostic first. In operations consulting work, that usually means looking at the changeover map, the SKU mix, the sequence, the output loss, and the actual source of each reset.

If the issue is mostly setup, the work belongs on the floor. If the issue is mostly portfolio complexity, the work belongs with planning, product management, and sometimes commercial leadership. If the issue is mixed, the fix has to cross those boundaries or it will stall.

That is also where Operations Diagnostics earns its keep. It is useful when the team already knows there is a problem, but not whether the cost is coming from setup, mix, or both. The point is not to produce another report. It is to pin the findings to a dollar figure and a SCOR stage so the plant stops arguing about symptoms.

The practical next step#

Pick one line and pull the last 20 changeovers. For each one, record:

• product family
• sequence position
• total downtime
• internal setup minutes
• true reset minutes
• whether each reset is machine, quality, product, or habit

Then sort the data two ways: by SKU family and by sequence. If the pain follows the family, you are looking at product mix design. If it follows the sequence, the scheduler is creating avoidable resets. If it follows neither and stays tied to the same steps every time, SMED is probably the right lane.

If you want help doing that faster, Operations Consulting is built for exactly this kind of diagnostic work, finding what is actually slowing the operation down and staying until the fix sticks.