Changeover time is the interval from the last good part of the old product to the first good part of the new product, both at rate. Measuring that window, and only that window, is what makes the number comparable across shifts. Change the endpoints and you change the answer.
Ask three shifts how long a changeover takes and you will often get three numbers for the same job, because they are timing three different things. One starts the clock when the machine stops, another when the operator picks up a wrench, a third when the last order finishes. One stops it at "machine running," another at "first part out," another at "back to full rate." None of them are lying. They are measuring with different rulers, and a metric measured with different rulers cannot be improved, only argued about. This post pins the definition down so every changeover is timed the same way, then shows what to record so the numbers are worth keeping.
Once the measurement is solid, the reduction work in SMED quick changeover and changeover loss reduction has a stable baseline to push against. Without it, every improvement claim is contested.
Where do you start and stop the changeover clock?
Start at the last good part of the outgoing product and stop at the first good part of the incoming product, both running at normal rate and quality. Those two endpoints are deliberate. Starting at "machine stopped" hides the ramp-down, the slow last minutes where the line coasts down and starts making marginal parts. Stopping at "machine running" or "first part out" hides the trial parts, the tweaking, and the scrap on the ramp-up, which on a bad setup is the largest piece of the whole event.
The "at rate" qualifier on both ends is what stops the number from being gamed. A machine can be technically running and producing parts that are out of spec or coming out at half speed. That is not the end of the changeover; it is the middle of a slow one. The changeover is over when the line is making good product at the rate the schedule assumes. Anything before that is still cost, and an honest clock counts it.
Why do inconsistent definitions wreck the data?
Because changeover time is a comparison metric, and a comparison is only valid when both sides used the same ruler. The whole point of measuring is to answer questions like "is this line getting faster," "which product pair is worst," and "did the SMED project work." Every one of those is a subtraction between two changeover times. If the two times were measured with different start and stop rules, the subtraction is noise. You cannot tell a real twenty-minute improvement from a shift that simply started its stopwatch later.
Inconsistent definitions also poison the OEE number downstream. Changeover feeds the availability term of OEE calculation as setup and adjustment loss, and it is usually one of the largest of the six big losses. If half your changeovers undercount the ramp and half count it honestly, the availability term wobbles for a reason that has nothing to do with the equipment. Then people chase phantom problems. A single, written, enforced definition is worth more than a fancier tracking tool.
How do you measure changeover time the same way every shift?
Standardize the measurement before you standardize the method. Run this sequence and the number stops depending on who is holding the clock:
- Write the two endpoints down. Last good part of the old product at rate, first good part of the new product at rate. Post the definition at the machine so every shift sees the same rule.
- Define "good" and "at rate" in numbers. Good means passing the first-piece check; at rate means hitting the scheduled speed, not merely moving. Vague words are where the ruler drifts.
- Timestamp the two events, not the duration. Capture the clock time of the last good part and the clock time of the first good part. Let the system subtract. People estimating durations from memory round to the nearest tidy number.
- Attach a reason code and the product pair. Record which product you left and which you entered. A changeover from A to B is a different job than B to A, and both differ from A to C.
- Capture at the station, not at end of shift. Log the changeover when it happens. End-of-shift reconstruction is where the ramp quietly disappears from the record.
- Separate planned from unplanned interruptions. If the line goes down for a breakdown in the middle of the swap, tag that time separately so it does not inflate the changeover number, but do not delete it.
- Audit the definition monthly. Watch a few changeovers against the written rule. Drift is normal; a periodic check is what keeps the ruler the same length over time.
What should you record for every changeover?
Record enough to compare like with like, and no more. The minimum useful set is the timestamps, the product pair, the crew or shift, and a reason code, plus the ramp scrap count if you want the full loss picture. That gives you a table you can slice: worst product pairs, worst shifts, trend over time. Without the product pair you cannot tell whether a line is getting worse or simply running a harder mix this week.
How do you compare changeovers fairly?
Compare within a product pair and within a like-for-like job, never across the whole raw list. A five-minute label change and a two-hour tooling swap are both "changeovers," and averaging them produces a number that describes nothing. Group by the from-and-to product pair first, then look at the spread within each group. A pair that takes twelve minutes on the best crew and forty on another is not a hard changeover; it is an unstandardized one, and the fix is standard work not more machinery.
Watch the distribution, not just the average. The mean hides the story that the spread tells. If a changeover ranges from twelve to forty minutes, the opportunity is closing the gap to the best repeatable time, which is usually a training and staging problem. If it clusters tightly at thirty-five minutes, the opportunity is method and hardware, which is where SMED comes in. Reading the spread tells you which kind of problem you have before you spend a dollar.
How does changeover time feed OEE and scheduling?
Two ways, and both need the number to be honest. In OEE, changeover is setup and adjustment loss inside the availability term, and it usually sits near the top when you rank machine downtime by reason code. An undercounted changeover inflates availability and hides the single biggest planned loss on many lines. In scheduling, the changeover time is the switching cost the planner uses to decide run length and sequence. If the recorded time is fiction, the schedule is built on fiction, and the plant defaults to long runs it does not need.
The industrial context is worth keeping in view. The international KPI standard for manufacturing operations, ISO 22400-2, defines OEE and the supporting time model precisely, so that setup, downtime, and production time mean the same thing across sites (ISO 22400-2:2014). And with U.S. manufacturing capacity utilization running in the mid-70s percent range, most recently about 75.7 percent (Federal Reserve, G.17), the changeover hours you can recover by shortening runs are capacity the plant already pays for. A standardized changeover time lets the OEE-versus-TEEP gap tell you how much of that idle capacity is switching cost rather than genuine demand shortfall.
How do you keep the measurement honest over time?
Automate the capture and audit the definition. Paper changeover logs are filled in at end of shift from memory, which is exactly when the ramp gets rounded away and the tidy number gets written. Tablet capture at the station timestamps the last good and first good part as they happen, so the duration is computed, not remembered, and a supervisor sees drift the day it starts instead of in next month's report. That move from paper logging to real-time capture is the same one CLS made across its shops (see the CLS case study). Pair it with a monthly definition audit and a way to model the payback of a faster changeover, such as the OEE calculator and the metric stays trustworthy long enough to actually improve. If you want a starting point for the log itself, a downtime tracking template gives you the fields to adapt. No rip-and-replace, just one ruler, used the same way, every shift.