Menu
Mixed-Product Capacity Planning: A Framework for Plants Running 50+ SKUs

Mixed-Product Capacity Planning: A Framework for Plants Running 50+ SKUs

Single-product capacity math breaks past SKU 30. A changeover-matrix framework that captures the real binding constraint in mixed-product plants.
Mixed-Product Capacity Planning: A Framework for Plants Running 50+ SKUs

Key takeaways

See our guide to maintenance planning and scheduling.

  • Capacity planning in a single-product plant is straightforward arithmetic. Capacity planning in a 50+ SKU plant is a different exercise, the binding constraint is not throughput, it is changeover overhead and the cumulative penalty of running many short runs.
  • The right framework starts from the changeover matrix, not the throughput rate. A 30-minute changeover between SKU families and a 6-minute changeover within a family are not the same problem and cannot be optimised the same way.
  • The single biggest capacity gain in most mixed-product plants is not buying more equipment. It is sequencing the schedule to minimise high-cost changeovers and accepting slightly longer runs to amortise them.
  • The standard "OEE divided by ideal cycle time" capacity calculation systematically undercounts the mixed-product penalty, because it omits the cumulative changeover overhead entirely. Plants that plan against that number consistently miss schedule and blame execution when the math was never right.

Why single-product capacity math breaks at SKU 30

In a plant running one or two products, capacity is a tidy calculation: available time × OEE gives productive run-time, and dividing that by the ideal cycle time converts it to units. The number is reliable. Sales can sell against it.

At 30+ SKUs the same calculation systematically overestimates capacity. The reason is changeovers. Each SKU change consumes time, sometimes a lot of it. Each change also consumes some warmup and stabilisation time that does not appear in the changeover record. The plant's effective capacity is whatever is left after all the changeovers, in the actual sequence the schedule requires.

The naive fix, subtract average changeover time × estimated change count, gets the magnitude right but the variability wrong. A schedule that runs 10 changeovers between distant SKU families this week and 30 changeovers within a family next week has wildly different effective capacities, and the average hides it. The piece on manufacturing KPIs covers the related KPI families.

Start with the changeover matrix

The foundational artefact for mixed-product capacity is the changeover matrix: for every SKU pair, the actual time and cost to transition from one to the other. Most plants do not have this matrix explicitly. The maintenance lead and the production lead know it implicitly, but it lives in their heads.

Pull six months of changeover data from the OEE event stream. Group by from-SKU / to-SKU pair. The matrix that falls out usually has four clusters:

  • Within-family changes, same product family, different size or flavour. Often 3-8 minutes.
  • Family-to-family within product line, e.g. moving from one cleaning product family to another on the same packing line. Often 15-25 minutes.
  • Cross-line family change, significant retooling. Often 45-90 minutes.
  • Sanitation-required change, food/pharma, allergens, colour changes. Often 2-6 hours.

Once the matrix is explicit, the math gets honest. The article on production loss analysis covers how to attribute the changeover loss into the OEE framework cleanly.

Sequence the schedule against the matrix

The schedule that minimises changeover overhead is rarely the schedule that minimises inventory or matches order timing. The plant has to pick.

The practical rule that most plants land on: cluster within-family runs together, accept slightly higher inventory on within-family SKUs, do the expensive cross-family changes once per week at most. A schedule that respects the cost structure of the changeover matrix typically gains 8-15% in effective capacity over a schedule that sequences purely by order date.

The trade-off is real. Sales may push for a one-off run of an off-cycle SKU. Finance may push for lower finished-goods inventory. Both pushes have merit. The capacity-planning framework just makes the cost of each request visible, "this off-cycle run costs us a 90-minute cross-family changeover and 4 hours of effective capacity" is a different conversation from "can we squeeze it in."

The capacity calculation, corrected

The standard capacity formula becomes:

Effective run-time = available time × OEE − Σ(changeover time × scheduled changeover count), and dividing that run-time by the ideal cycle time gives effective capacity in units.

The second term is the one that gets skipped. Without it, the plant systematically over-promises against schedule. With it, the planner can model alternative schedules and see the capacity difference directly.

For a plant running 50-100 SKUs, the changeover term typically consumes 12-25% of available time, which is the same magnitude as the OEE losses themselves. Optimising one without the other leaves half the gain on the table. The article on the work order management system covers how PM scheduling interacts with the changeover-dense windows.

The leading indicator

For ongoing operation, the metric that ties this together is changeover-time as a percentage of available time, tracked weekly. It moves with three causes: the SKU mix, the schedule sequencing, and the actual changeover execution.

A weekly trend isolates them, if the SKU mix is stable but the percentage is rising, the planner is sequencing worse. If the sequencing is stable but the percentage is rising, the changeover execution is degrading. The piece on root cause analysis covers how to investigate each direction.

How Fabrico fits

The framework works in any plant with a CMMS and an OEE system. Where a unified platform helps is in two places: the changeover matrix is auto-derived from the OEE event stream rather than reconstructed manually, and the per-changeover cost stays current as the SKU mix evolves.

Fabrico is built so the planner sees the changeover-cost picture against the schedule before commitments are made, rather than after the schedule has missed. The connection to the preventive maintenance schedule matters because PM windows are easiest to slot during natural changeover gaps.

To see how the changeover matrix would look against your live data, book a demo .

Frequently asked questions

What if our SKU mix changes monthly?

The matrix gets refreshed monthly. The clusters (within-family, family-to-family, cross-line, sanitation) tend to stay stable even as individual SKUs come and go, so the structural picture holds even when the entries shift.

How accurate does the changeover matrix need to be?

Within 20% per entry. The framework is about sequencing decisions, not point-precise capacity claims. Spending months on perfect entries is the same anti-pattern as spending months on the perfect loss taxonomy.

Who owns the matrix?

The planner. The OEE system feeds it, the production team validates it, but the planner is the one who uses it for sequencing decisions. Without a single owner the matrix goes stale.

What about CBM-driven changeover reduction (SMED)?

SMED reduces the cost of each entry in the matrix. The framework is complementary. SMED on the most-common high-cost changeovers, sequencing on everything else. They are not substitutes.

What is the most common implementation mistake?

Building the matrix once and treating it as fixed. Changeover times drift as operators rotate and as equipment ages. A matrix that is reviewed quarterly is useful; a matrix that is set once and trusted for two years quietly becomes wrong.

Latest from our blog

Define Your Reliability Roadmap
Validate Your Potential ROI: Book a Live Demo
Define Your Reliability Roadmap
By clicking the Accept button, you are giving your consent to the use of cookies when accessing this website and utilizing our services. To learn more about how cookies are used and managed, please refer to our Privacy Policy and Cookies Declaration