How Much Does a Slow Changeover Really Cost?

What changeover downtime cost actually means

The instinct when thinking about changeover downtime cost is to look at operators on the clock during the stoppage. That cost is real. But it is usually the smallest component in the stack — and stopping there is what keeps most improvement business cases weaker than they should be.

The full cost of changeover downtime is a stack of four layers, and most of the stack is invisible unless you know where to look. Lost output value shows up as a throughput gap. First-run scrap hides in quality metrics. Overtime and expedite costs land in separate line items with no link back to the changeover that caused them.

This article walks through each layer with a formula you can apply to your own line. The goal is not a benchmark — it is a model you can fill in with your numbers, so the cost of your current overrun rate becomes a number rather than a feeling.

1) Lost output value: the cost most teams never calculate

When a line is stopped for a changeover, it is not producing. Every hour of downtime is an hour of output that does not happen — and that output has a value your finance team can quantify if asked.

The formula is straightforward:

Use contribution margin, not revenue. The question is not how much product you could have sold — it is how much margin you could have recovered if the line were running.

For many production environments, this number is 5–10× the direct labour cost on the same changeover. Most finance teams never see it framed this way. They see downtime hours. The output value lost is the number that turns a duration into a cost your organisation can act on.

It also means that a 30-minute overrun on a high-throughput line is not a minor inconvenience. On a line producing 300 units per hour at a $12 contribution margin, each 30-minute overrun costs $1,800 in lost output alone — before any other layer. Multiply that by your annual changeover frequency and the number becomes worth a conversation with management.

2) Labour during downtime: visible but not the biggest number

Operators are paid during the changeover. This is the cost everyone tracks — and in most improvement business cases, it is the only cost on the page.

The formula:

This is real and worth including. But on a line with five to eight operators, a four-hour changeover at a typical manufacturing wage is a few hundred dollars. Compare that to the lost output value on the same run, and labour is usually 10–20% of the total picture.

The reason to name it second is deliberate: most managers stop here. They see the labour cost as the changeover cost, make a decision about whether it is worth addressing, and miss the 80% sitting in the other three layers.

3) Three costs that do not appear on your changeover report

These are the layers that move off the changeover record and into other reports, which is why they are easy to miss when building a cost case.

First-run scrap and setup rejects. After every changeover, the line goes through a stabilisation period. Parameters settle. Temperatures equilibrate. The first units off the line after a product change are often not to specification. Some are reworked. Some are scrapped. The cost — material plus rework labour — is real, but it lands in the quality report, not the changeover record. To calculate it: count the average number of units produced before the line reaches steady-state quality on this product pair, and multiply by the cost per unit (material plus variable processing cost).

Overtime bleed. When a changeover overruns, the run that follows it is shorter. If the shift cannot absorb the compression, operators extend their hours, or the downstream job starts late into the next shift. The overtime cost is attributed to the shift, not to the changeover that caused it. This makes it invisible in changeover analysis but very visible on the payroll line — which is why plant managers often have a sense that overtime is high without being able to connect it to a specific cause.

Expedite and late-delivery exposure. A delayed changeover that pushes a committed order past its window creates a downstream cost: premium freight to make up time, or a service penalty if the customer has one in the contract. This is the highest single-event cost on a bad changeover, and it almost never appears in the changeover record. It shows up in the logistics budget or in a customer complaint — disconnected from the root cause.

This is a system problem, not an operator problem

Once you have a full cost picture, the next question is where the cost comes from. The answer is almost never operator speed. Changeover overruns accumulate for three systemic reasons:

• No step-level time visibility. You know the total. You do not know which step ran long. Without that, every improvement effort is aimed at the average rather than the cause. The step that adds 20 minutes to every run looks identical to the steps that ran on schedule — both appear as completed ticks.
• Operators waiting on the system. Tools not pre-staged. Parameters not displayed for this product. Approval needed before the next step can start. None of these are operator failures. They are gaps in the setup that show up as time on the clock.
• The task list is not the current version. Engineering updates the procedure. The update does not reliably reach all shifts before the next run. Operators follow the version they have. The results vary, and no one can explain why.

These are not problems you can fix by telling operators to work faster. They require visibility into what is happening at the step level — and a system that gives operators the right information at the right moment.

For context on why step-level visibility is the core requirement, see Lean Production's SMED overview — the methodology that makes separating internal from external work possible, which requires knowing what each step actually takes.

Related: Why Your Changeover Checklist Keeps Failing — the four structural gaps that let these problems propagate run after run.

Related: SMED Basics: Faster Changeovers — how the internal/external task split is where most recoverable time lives.

Building your own cost model

The goal is a single number: the annual cost of your current changeover performance on a given line. Here is how to build it.

Use averages where you have them. Use conservative estimates where you do not. The purpose of this model is not precision — it is order of magnitude. A number that is roughly right is more useful in a business case than no number at all, and most teams find the result is larger than the conversation they have been having.

If you do not have step-level data, your lost output and scrap numbers will be estimates. That is fine. Note them as such. The model still gives you a basis for the improvement case, and you can refine the numbers once you have actual execution data.

What 15 minutes recovered is worth

You do not need to eliminate the changeover. You need to find the overrun and fix it. Even a modest reduction has a compounding effect across a year.

At three changeovers per week, 15 minutes saved per changeover equals 39 hours recovered per year. To make it concrete: a line running at 250 units per hour with a $9 contribution margin recovers 39 h × 250 × $9 = $87,750 in output value per year from that single change. Your numbers will differ — the formula is the same, and the result is almost always larger than the conversation teams have been having about whether to invest.

The investment pays back on output value alone, before counting labour, scrap, or expedite savings. The question is not whether the ROI is there. It is which 15 minutes to target first — and that requires knowing which step runs long and why. Total changeover duration tells you that you have an overrun. Step-level data tells you where it lives.

Related: Changeover Gantt Chart: How to Track Performance Task by Task — what becomes visible once you have step-level timing on every run.

Related: OEE Changeover: Why Availability Is the Easiest Win to Close — how to connect the same time loss directly to your OEE availability number and calculate the ceiling your OEE cannot break until changeover is fixed.

How ProChangeover maps to each cost layer

Each cost layer above has a systemic cause. ProChangeover addresses them at the execution layer — the point where the changeover is actually happening.

• Lost output. Guided execution with a time target per step reduces total duration and, more importantly, makes it predictable. Predictable changeovers allow tighter scheduling — fewer buffer hours built in "just in case." That recovery happens every run, not just when something goes wrong.
• Labour on clock. Operators who have the right instructions in front of them at each step do not spend time finding the procedure, confirming which version to use, or waiting for a supervisor to answer a question. The time saving is not large per changeover, but it compounds across every run on every shift.
• First-run scrap. Parameters for each product are shown to the operator at the relevant step — not pulled from last run's binder or estimated from memory. Verification at each critical step before proceeding reduces the probability of running out-of-spec from the restart. See also: machine parameters per product.
• Visibility gap. Every changeover produces a timestamped record of each step: actual duration versus target, deviations noted, sign-offs confirmed. That record is the data you need to find the recurring overrun — the step that runs 18 minutes on a 5-minute target every third run — and fix it before the next cycle.