How to Reduce Changeover Time with SMED

What SMED really means

SMED stands for Single-Minute Exchange of Die—a lean method developed by Shigeo Shingo to dramatically reduce the time a machine is idle between production runs. The core idea is simple: not all changeover tasks actually need the machine to be stopped.

SMED splits every changeover task into two types:

• Internal tasks can only happen while the machine is stopped—physical swaps, mechanical adjustments, cleaning that requires access.
• External tasks can happen while the machine is still running—gathering tools, preparing settings, printing work orders, staging materials.

In most operations, a surprising amount of what happens during a changeover stop is actually external work that no one moved earlier. That's where the time is hiding.

External reference links: Lean Lexicon: SMED · LeanProduction: SMED overview

Agree on what "changeover time" actually means

Before you measure anything, your team needs to agree on a definition—otherwise your "improvements" might just be measuring different things differently over time.

The most reliable definition used in SMED work is:

If capturing first-good-unit is difficult at the start, use a temporary definition you can actually track (like "stop to quality release") and upgrade it once you have the right data infrastructure in place. Just don't let a weaker definition become permanent.

A practical 5-step SMED implementation

You don't need a formal kaizen event to get started. Here's a sequence that works for real teams with normal constraints.

1. Baseline one full changeover. Time each step of a real changeover—not your best one, a typical one. Capture waiting, searching, adjustments, and rework, not just active work. A stopwatch and a notes app is enough to start; video is better if you can manage it.
   Output: a timeline of tasks with gaps, so you can see where time actually disappears.
2. Label every task as internal or external. Go through your timeline and mark each step. Then ask: what would it take to move this internal step to before the stop? Staging, kitting, parameter prep, and printing work orders are almost always convertible.
   Don't overcomplicate it. A simple spreadsheet or task list with two columns is all you need at this stage.
3. Convert internal tasks to external—this is where the biggest gains are. Pre-stage tools and materials at the line. Load parameters ahead of time. Have quality documentation ready before the stop. The goal is that when the machine goes down, execution starts immediately instead of preparation starting.
   In most facilities, 30–50% of machine-stop time is actually external work nobody moved. This step is where you recover that time.
4. Simplify what has to stay internal. For tasks that genuinely require the machine to be stopped, focus on removing the "try, adjust, try again" loops. Reduce fastener types, standardise tooling functions, add quick validation checkpoints so operators know they're right the first time.
   One clear owner per step also helps here. Ambiguous handoffs create silent queues that don't show up in your headline number.
5. Standardise the sequence and review it weekly. Write one guided procedure with roles, timing targets, and a clear escalation path. Then review your slowest changeover every week—not just the average—and remove the most common bottleneck. One fix per week compounds quickly.
   Goal: consistent execution across shifts, not just a good result when the right person is on.

Where teams actually lose time

When you map changeover timelines across different lines and shifts, the same patterns show up. Most lost time isn't a technical problem—it's an execution gap.

• No pre-staging: tools, parts, or gauges aren't at the line when the stop happens. Someone goes to find them. Ten minutes disappear.
• Unclear ownership: two roles each assumed the other was handling a step. The gap sits there quietly until someone notices.
• Searching for setup information: the setup sheet is in a shared drive folder, or it's a version from six months ago. Operators work from memory instead.
• Parameter entry errors: a wrong value causes a failed first piece, which means rework and a delayed restart.
• First-piece approval delays: quality isn't available, or acceptance criteria aren't clear, so the line sits waiting for a green light.
• No visibility during execution: roles can't see where blockers are building until they've already cost minutes.
• No review loop: the same bottleneck happens every week because no one is tracking which delays recur most often.

How to know if SMED is working

One good changeover doesn't tell you much. What you want to see is the trend improving and the variation narrowing—that's the signal that the process has genuinely changed, not just that you had a good day.

Track these metrics weekly:

• Total changeover duration — median and 80th percentile, not just the average. Outliers matter.
• Internal vs external time split — are you successfully shifting more work to before the stop?
• Top delay reasons — count and minutes per cause: missing tooling, waiting for sign-off, rework, etc.
• First-piece pass rate — how often does the first unit after changeover pass quality without rework?
• Variation by shift or team — high variation signals that the standard isn't being followed consistently, or isn't clear enough.

Turning SMED into a daily habit, not a one-time workshop

The most common failure mode with SMED is running an event, seeing a good result, and then watching performance drift back to where it was within a few months. The process improved; the operating rhythm didn't.

Sustainable gains need a lightweight cadence around every changeover:

• Before: confirm staging is complete, owners are confirmed, and quality coverage is arranged.
• During: follow the standard sequence and log any blockers as they happen—not from memory at the end of the shift.
• After: spend five minutes reviewing what slowed you down. Capture one fix and assign it to someone before the debrief ends.
• Weekly: look at your slowest changeover from the week. What was the top recurring cause? Fix that one thing.

SMED isn't a project. It's a system—standard work plus visibility plus a regular review loop. Start small, prove that the cadence works, then expand it.

The gap between knowing SMED and doing it every day

Most teams understand SMED. The harder part is making the standard stick across shifts, capturing the task-level data that shows you where time is going, and maintaining the weekly review loop without it becoming another meeting that gets skipped.

ProChangeover is built around that gap. It gives teams a single place to run guided changeovers, log delays in real time, and review bottleneck trends without manual data collection:

• Guided digital task sequences replace paper sheets and shift memory with one clear procedure anyone can follow.
• Ownership and timing targets built into every step so handoffs are explicit, not assumed.
• Live progress view shared across production, maintenance, and quality so everyone can see where the changeover stands.
• Timestamped execution data automatically feeds your bottleneck analysis and continuous improvement reviews.
• Gantt-style analytics let you compare performance across lines, shifts, and product families to see where standards are holding and where they aren't.

For a closer look at how teams are using it in practice, see our guide to eliminating the most common changeover delays.

See how live task tracking and role-level visibility work in practice: Live operator visibility.