Changeover Time Reduction: What Software Can Actually Do

Author Michał Dorna
Published on October 20, 2026
Read time ~ 13 min read

TL;DR

A changeover can run 80% over its costed time without the tooling ever being the problem. The line stands waiting for a signature, a material check or last run’s paperwork.
Three vendors of changeover software end the clock at four different moments. If two of your shifts pick different ones, their numbers don’t compare.
Operators who put a roll change at 10–15 minutes were measured at 4.5–7. The machine keeps better time than memory, and you can read it without writing a byte to the PLC.
Put the clock on operators and they start under-reporting. Put it on the machine and the order instead. In Poland, staff are also owed two weeks’ notice before such monitoring starts.

Where does software actually help in changeover time reduction?

Picture the last pallet of a run leaving the line. The setter has the change parts on a trolley. The material for the next product is already beside the machine. And nothing moves, because the supervisor who signs off the cleared line is on another line, and nobody has told her this one is ready.

That wait is not in the SMED playbook, and it rarely shows up in the changeover report. In one well-documented case, it was the whole problem.

At a ready-meal factory in South Yorkshire, researchers Garcia-Garcia, Singh and Jagtap (2022) found changeovers running 80% longer than costed and overall equipment effectiveness (OEE) at around 60%. The tooling was not the culprit. The waiting sat “at various sections of changeover”, and it had grown with in-depth cleaning and with material and line sign-off procedures.

The plant tried the obvious fixes first. Moving the crew straight to the next line did not end the wait: paperwork from the previous run was still open, and so were the checks for the next product. Running products in a smarter order was not viable either: with stock accuracy and delivery times as they were, nobody could count on materials arriving in sequence. Team leaders were filling in the Short Interval Control board in the middle of the stop. When that job moved to after the changeover, the board got better, because nobody was rushing it anymore.

What finally worked was method. Single-minute exchange of die (SMED) plus a reorganization took the changeover from 29 to 20 minutes and OEE to an average of 71%. But look at what stood in the way: a signature, a material check, open paperwork, a board filled in under pressure. Almost all of it was information.

A worker wiring components on an electrical control cabinet frame in a factory

The same gap shows up in the numbers plants keep. At Duraco, operators described roll changes as a 10 to 15 minute job. Measured from the machine, they took 4.5 to 7 (Factbird case study, 2026). Nobody was lying. Shift logs get written from memory, and memory is a poor stopwatch.

That is where software belongs in changeover time reduction. Not inside the stop, cutting minutes, but around it, making the information trustworthy: what is ready, when the machine really stopped, when quality accepted the first good part.

Check your own line

That factory isn’t yours. Four questions show whether the same problem sits on your line:

Do you know how long your last changeover took from the machine, not from the shift note?
Who decides when a changeover ends, and does every shift count it the same way?
How often did a line stand last month waiting for a signature, material or paperwork rather than tools?
Does your planner know the real changeover time for each product pair?

If two answers are “not sure”, the problem is information, and that is where software helps. To size it, multiply: changeovers per month × minutes of waiting per changeover × the cost of one minute of line time.

Our view

Before buying software that promises a faster changeover, make the information around the stop trustworthy. A tool that starts by timing operators makes your data worse, not your changeovers shorter. One downtime-tracking vendor says it plainly: track downtime against individual operators and under-reporting becomes incentivised. The method is your team’s work. Reliable information around it is ours.

Where we would start

We would start narrow, on the machine where waiting hurts most:

a read-only signal for when the machine really stops and restarts;
one readiness view showing what each department has prepared for the next changeover;
one definition, set by quality, of when a changeover ends;
data that names the machine and the order before it names a person.

That’s the short version. Below are the details.

Book a conversation

Read the details

The details

Who holds the information a changeover waits for?

Rarely one person. Follow the UK changeover from the end of one run to the start of the next, and the information changes hands four times:

Information before the stop	Held by	Needed next by
Line cleared and signed off	Supervisor or QA operative	Servicers bringing components
Components right for the next product	Two independent checkers	The line, before restart
Paperwork for the last run, checks for the next	Team leader	Crew on the next line
Material at the line in time	Servicers	The two checkers

Source: Garcia-Garcia et al., 2022.

Each row is a hand-over, and each hand-over is a place where the line can stand still while everyone involved is doing their job well. The supervisor is signing off another line. The checkers are waiting for material. The servicers are waiting for the sign-off. Nobody is idle. The line is.

That is why a changeover report rarely shows this wait: it records the stop, not who was waiting for whom. Evocon describes a checklist that must be complete before a changeover may start. Turn that checklist into a shared view tied to the schedule, and the missing signature shows up while the previous run is still going, not after the machine has stopped.

When does a changeover really start and end?

Picture two shifts on the same line. The morning shift’s changeovers look much shorter than the night shift’s, and a meeting is called to find out why. Then someone notices that the morning shift stops the clock when the new product’s first cycle runs, and the night shift when quality accepts the first good part. Both are right, and their numbers mean nothing side by side.

The start is the easy half. The machine knows when it stopped, and reading that does not mean writing to it:

OPC UA: access levels separate reading from writing (OPC 10000-3, 8.57).
MTConnect: the standard defines reading data only (MTConnect).
Current draw: Tractian’s sensor detects run, idle and stop without PLC access (Tractian, 2026).

Mixed fleets raise a problem familiar from IoT products: older device generations have to work alongside new ones, and each needs its own way in. That is an engineering question, not a reason to wait.

The end is harder, because it is a definition, and the market has not agreed on one:

Changeover ends at	Used by	Moment confirmed by
First cycle of the new product	SYMESTIC	The machine
First good part	Tractian guide, 2026	Quality
First good part at full speed	Tractian	Quality, after ramp-up
First confirmed on-spec sample	iFactory	Quality or the lab

None of the four is wrong. A line that makes packaged food may care about the first part that passes quality; a cement mill, about the first on-spec sample from the lab. What matters is that the plant picks one, every shift uses it, and every record says which one it is. That is quality’s call. Software’s job is to record it the same way every time.

Industrial control desk with buttons, indicator lights, screens and papers

What can software record around a changeover?

Walk through one changeover, from the last good part of one run to the first good part of the next, and five facts appear. Each has its own source and someone who confirms it:

Recorded	Comes from	Confirmed by	Feeds
Readiness of each department	A readiness view tied to the schedule	Setup, materials, quality	Planner, shift lead
Start of the stop	Read-only signal: OPC UA, MTConnect, current draw	The machine	OEE availability
End of the changeover	First part quality accepts, by the plant’s definition	Quality	Time per product pair
Why it ran long	Two-level reason list, “unknown” flagged	Operator, then shift lead	Pareto, next SMED round
Effect on the sequence	Product-pair times, confirmed material	Planner	Changeover scheduling in the existing ERP

The first row is what the UK plant was missing. The last row is what planners are often missing. More than 90 percent of scheduling research ignores setup times, according to Ali Allahverdi’s 2015 survey of about 500 papers. The UK plant’s attempt to resequence failed on material data, not on the idea. With product-pair times and confirmed material, sequencing stops being a guess: in a Siemens case study, ROJ uses machine data to avoid unnecessary changeovers.

None of this needs a new system of record. Each row feeds a tool the plant already runs.

How we do it

DO OK builds IoT and cloud systems on AWS and Azure, with data pipelines from equipment into the systems a business already runs.

We already have OEE software. Why add anything?

Keep it. OEE and SMED tools are good at the stop itself: SYMESTIC, for example, holds every product change against a target changeover time, and setup counts against availability in OEE. What they don’t hold is the preparation that happens before the stop, across setup, materials and quality. One vendor’s own page says changeover times are recorded, if at all, in the shift note.

Some will say

The large documented cuts came from method, with no software: a CNC workstation in Poland went from 186 to 72 minutes (Hys and Domagała, 2021), a welding station got 61% shorter (Ocieczek et al., 2025). That is true. Software doesn’t make those gains. It keeps them measured the same way on every shift and stops the next changeover waiting on a missing signature or material.

So the right move is to feed the MES, ERP or OEE tool you already run, not to replace it.

What can software not do, and what should it never judge?

Software cannot choose the technology, heat a tool faster or know the machine like the setter.

The UK factory shows where that line runs. A sealing head took between 7 and 11 minutes to reach its optimum temperature (Garcia-Garcia et al., 2022). The fix was physical: pre-heating, and it worked only where a spare sealing machine was available. Software could show that wait on a screen. It could not shorten it by a second. The exception is a changeover that is itself a paper-heavy procedure, like the pharmaceutical line clearance Tulip describes: there, digital instructions sit inside the stop.

The second limit is about people. Put a stopwatch on operators, and the data starts protecting them instead of describing the line.

Watch out

Tractian notes that “under-reporting is incentivised” where downtime is tracked against individual operators. In Poland, Article 22(3) § 4 of the Kodeks pracy (Polish Labour Code) applies the e-mail monitoring rules to other monitoring where needed for its listed purposes, and staff must be told at least 2 weeks before launch (PARP, 2022). GDPR Article 5(1)(c) adds data minimisation. Whether machine data that names people counts as monitoring is for your legal team and works council to decide.

Two people in hard hats and high-visibility vests looking at a tablet on a building site

What this means for the next changeover on your line

Go back to the line from the start of this article: change parts on the trolley, material beside the machine, everyone waiting for one signature. SMED won’t find that wait, and a stopwatch on the setter won’t either. A shared view of what’s ready, a read-only signal from the machine and one agreed definition of “done” will.

Changeover time reduction stays your team’s work. What software adds is information you can trust before, during and after the stop. If the four questions above left you unsure, start there: one machine, one read-only signal, one readiness view. A first step can be scoped in a discovery sprint.

Frequently asked questions

Can you track machine downtime on old machines without touching the PLC?

Often, yes. One vendor’s current-draw sensor reads run, idle and stop without PLC access or changes to the machine. OPC UA separates read from write access, and MTConnect defines reading only. Whether a given machine fits is checked on site.

Why do operators’ changeover estimates differ from machine data?

Because logs are often written from memory at shift end. In a case study Factbird published in 2026, roll changes believed to take 10 to 15 minutes measured 4.5 to 7. The fault lies in the method, not the people.

Is SMED software worth it if we already run SMED?

Where waiting and inconsistent records are the problem, yes. SMED made the large cuts in the published studies, without software; a software layer around the stop keeps the measurement consistent and the preparation visible. Where the stop is mostly process time, it adds little.

Can changeover scheduling software reduce the number of changeovers?

Only if the data behind it is reliable. In the UK food case, better sequencing failed because materials could not be counted on to arrive in order; ROJ, in a case Siemens published, uses machine data to avoid unnecessary changeovers. The planner decides the sequence; software shows product-pair times and confirmed material.