Changeover Matrix: Build and Read Your Setup Data

Home » Resources » Changeover Matrix: Build and Read Your Setup Data

Estimated reading time: 8 minutes

A changeover matrix is a from-to table showing how long a machine needs to switch between products or setup states. Each cell answers a specific question: if the machine is set up for this product now, how much time will it need before it can produce that product next?

The direction matters. Moving from a light colour to a dark one may need a short flush, while returning to the light colour requires a much longer clean. One average setup time hides that difference. The schedule can then reserve too little time for a difficult change and too much for an easy one.

A useful matrix makes those differences visible before they disrupt the plan. It also helps you identify which product characteristics are worth grouping in SkyPlanner, so you can reduce unnecessary changes without rebuilding machine queues by hand every time priorities move.

How to read a changeover matrix

Read the row as the state you are changing from and the column as the state you are changing to. Keep those labels on the table, even if everyone currently knows which way it works. Reversing them gives you the wrong planning assumption.

Imagine a coating machine running three colour families. The following times are illustrative, not customer results or recommended cleaning standards.

From current family / To next family	A: light	B: medium	C: dark
A: light	0 min	12 min	18 min
B: medium	35 min	0 min	10 min
C: dark	50 min	28 min	0 min

To move from light to dark, read across row A to column C: 18 minutes. For dark to light, read row C to column A: 50 minutes. These are separate transitions, not two views of the same number.

The diagonal shows a continuation within the same family. Here it is zero because the example assumes no setup is needed between those jobs. Do not automatically copy that assumption into your own matrix. A change of fixture, a batch-release check or another preparation step may still be needed within a family.

The table becomes useful when you include the machine’s starting condition. Suppose it is currently set for dark, and the next jobs are light followed by medium. The setup allowance is:

• Dark to light: 50 minutes.
• Light to medium: 12 minutes.
• Total changeover time: 62 minutes, before adding the jobs’ running times.

Counting only the transition between the two new jobs would reserve 12 minutes and miss the initial 50-minute change. The first job in a plan does not necessarily begin on a clean, neutral machine.

How to build a changeover matrix you can trust

Start with a resource where setup assumptions genuinely affect delivery decisions. A focused matrix with traceable figures is more useful than a factory-wide grid filled with guesses.

Define the machine and the setup states

Name the machine or line the matrix describes. The same product pair can take different times on different equipment, so do not transfer a figure between machines without checking it.

Then identify what drives the change: tooling, material grade, colour, dimensions, fixture or another production characteristic. Use product codes where individual products behave differently. Use setup families where products genuinely share changeover behaviour.

A sales category is not necessarily a setup family. Two products that look similar in the catalogue may require different tools. Conversely, several customer-specific products may use the same machine settings. Group by what the operator actually has to change.

Agree on what starts and stops the clock

Choose a consistent timing boundary. For a capacity view, a useful measure is the elapsed time from the last good part of the previous job to the first acceptable part of the next. State whether the figure includes cleaning, adjustment, trial production and first-off approval.

Keep the components visible where they affect planning. If the machine stands waiting for an inspector, that waiting time consumes machine availability, but it is not the same problem as a slow tool change. Record the reason rather than quietly mixing every delay into one unexplained setup figure.

Distinguish elapsed machine time from labour effort, too. Two people working together for part of a changeover do not make the machine unavailable for the sum of their individual labour minutes.

When you later configure scheduling data, reconcile this boundary with any setup, teardown or other time already included. The same cleaning activity should not consume capacity twice.

Collect observations with enough context

For each observed change, record the resource, previous state, next state, elapsed time, date and any explanation that affects the result. Keep the observation behind the matrix value so the number can be checked later.

Repeated observations reveal whether a transition is reasonably stable or depends on another condition. If similar changes vary widely, look for the cause before compressing them into an average. Different fixtures, missing preparation or a recurring approval delay may need different responses.

Choose a representative planning allowance for the conditions you expect, and document how you chose it. A one-off breakdown should not silently become the normal changeover time; a recurring delay should not disappear simply because it is inconvenient.

Mark estimates, unknowns and prohibited transitions differently

An unmeasured cell is not a zero-minute change. Label it as unknown, or as an estimate with its basis and a person responsible for checking it. Start by validating transitions the current order book is likely to use, especially those where an error would threaten a delivery.

A prohibited transition is different again. It needs an explicit production restriction, not a blank cell or an enormous invented duration. The matrix records the planning consequences of your process rules; it does not decide whether a change is technically or safely acceptable.

Review family-level values against known exceptions. If one product needs an additional cleaning or tool-setting step, keep that difference visible instead of letting the family average erase it.

What the matrix should change in your production plan

Look for patterns, not just the smallest cell. An expensive column points to a state that is costly to enter. An expensive row points to a state that is costly to leave. A large difference between opposite directions tells you that the order of work deserves attention.

These patterns help you ask better questions. Can compatible jobs run together? Is a costly return to a previous setup avoidable? Does an apparently convenient family grouping hide an important exception? Which frequently used transition deserves a physical changeover improvement?

That last question belongs to SMED: reducing the work and time needed for the change itself. The matrix has a different role. It describes the transitions your schedule must allow for, and needs updating when the physical method improves.

A low setup total is still not a complete production plan. The next job also needs material, an eligible resource and completed preceding operations. Its delivery priority may justify breaking a convenient group. Compare the setup pattern with those requirements rather than rearranging the queue solely to chase the shortest change.

Turn setup patterns into a live schedule with SkyPlanner

The practical next step is to put meaningful setup assumptions into the scheduling process, not maintain a separate matrix and manually repair the plan beside it. SkyPlanner APS combines setup information, resource capacity, operation dependencies and delivery priorities in one production schedule.

For workstations where compatible product properties drive the opportunity to reduce changes, SkyPlanner’s property-based grouping is a direct way to act on what you have learned. Products carry properties and values, such as a tool family or material grade. A workstation can use the relevant property to group similar work orders.

The workstation’s Allow similarity rule includes a setup time for differing jobs and a choice of the property to consider. You also set the importance of running similar jobs in succession within Dynamic Priorities. That gives the scheduling calculation a reason to keep compatible jobs together while still considering the other priorities you have chosen.

For example, if your observations show that several part numbers use the same tooling and changes mainly occur between tool families, that tooling property is more useful than grouping by customer or product name. You turn shop-floor knowledge into a repeatable scheduling rule instead of relying on a planner to remember every compatible combination.

A directional matrix can also reveal a more demanding requirement. The coating example’s 18-minute and 50-minute transitions cannot be represented faithfully by one common differing-job time. If those pair-specific differences are decisive in your production, bring both directions and any exceptions to a SkyPlanner demo so the setup model can be checked against your actual process.

Arcturus, SkyPlanner’s scheduling AI, calculates the work sequence under your configured rules and priorities, and the Gantt timeline shows the result. With automatic rescheduling enabled, relevant changes to orders, completions or capacity can trigger a recalculation. You spend less time reconstructing queues and more time deciding which commitments need attention.

Start with the changes your next orders will need

You do not need to measure every possible product pair before making progress. Start with one important machine, its current setup and the transitions expected in the coming production plan. Check the expensive reverse directions and the cells that are still estimates. Those are often where a seemingly comfortable schedule loses its margin.

Then put that knowledge to work. Book a SkyPlanner demo with your setup families, a few measured transitions and a real order mix. You can examine how grouping, setup allowances and delivery priorities should work together in your production. If you prefer to explore the scheduling environment first, try SkyPlanner with demo data.