From One Pilot to a Plant Standard: Rolling Out IoT Across Lines
DBR77 Team · Published
To turn one successful IoT pilot into a plant standard, freeze the parts that made the pilot work: the state model, reason categories, alert routes and review cadence. Adapt only what has to differ per line, such as machine connections, detailed reasons and thresholds, and roll out line by line from a written playbook with one owner.
"One line, one pilot: measured, not promised," as Paweł Dera at DBR77 puts it. Once that first line has shown results, the work is to make the response systematic across the whole plant, so the result does not depend on the people who ran the pilot.
Why good pilots stall at one line
McKinsey describes the "pilot purgatory" that afflicts many companies: pilots work, but value at scale never arrives. An assessment of more than 1,000 manufacturing sites by the World Economic Forum and McKinsey found 44 leading companies, with 10 more added in 2020, that were adopting such technology at scale. Even those leaders now face what the WEF calls a "Scaling Slump" when they try to spread impact across whole networks.
In a mid-size plant the usual reason is that the pilot's rules lived in one champion's head and nobody wrote down why it worked. Line two then starts from zero with new definitions, and the numbers stop being comparable.
What to freeze from the pilot
Freeze the parts that decide how people respond. These should be identical on every line:
- State model. The same definitions of running, stopped, changeover, waiting for material and planned stop.
- Reason categories. A shared top-level list, for example eight categories such as mechanical, electrical, material, quality and organisational.
- Alert routes and escalation. Each stop category goes to one role on the shift. No acknowledgement within 5 minutes means the shift leader is alerted.
- Review cadence. Ten minutes at the start of each shift on the top losses, plus a weekly review with maintenance.
- KPI definitions. One OEE formula and one definition of response time. Vorne's widely used benchmark, for example, builds 85% OEE from 90% availability, 95% performance and 99% quality. If two lines calculate OEE differently, comparing them is meaningless.
The Lean Enterprise Institute describes standardized work as the baseline for improvement. With a frozen standard you can tell whether a change on line four actually helped.
What to adapt per line
Some things cannot be copied, and forcing them causes resistance:
- Machine connections. A line with modern PLCs is read directly; an older line needs edge devices or cameras.
- Detailed reasons. Under each shared category, operators name the reasons in their own words, 10 to 15 per machine type.
- Thresholds. A minor stop on a press and one on a packing machine need different limits, so set them per machine type.
- Shift patterns and owners. Roles stay the same; names and shift times change.
If you run more than one site, the same split applies one level up. Our article on proving IoT value across sites without forcing one template covers that.
Turning a pilot into a standard?
Tell us what worked on your first line. In one conversation we help you separate what to freeze from what to adapt, and sketch the rollout order.
The rollout playbook
The playbook is a short document of a few pages. It answers who does what, in which order, on every new line. Each element has one owner.
| Playbook element | Content | Owner |
|---|---|---|
| State model and KPI definitions | Frozen definitions, OEE formula, response time | Owner of the standard (CI or operations excellence lead) |
| Reason categories | Shared top-level list, per-line detail | Owner of the standard with line owner |
| Connection survey | Machine list, connection type per machine, network | Maintenance with IT/OT |
| Alert routes and escalation | Role per stop category, escalation time | Line owner |
| Baseline | Two weeks of response time, "unknown" share, top losses | Line owner |
| Training | Reason capture at the machine, alert handling | Shift leaders |
| Review cadence | Daily shift review, weekly maintenance review | Production manager |
| Go-live decision | Checklist below, success criteria for week eight | Operations Director |
Before a new line goes live, check:
- Every machine in scope reports its state, verified on the floor.
- Operators reviewed the detailed reason list for their line.
- Alert routes were tested on every shift, including nights.
- The baseline is recorded and signed off.
- Success criteria are written down, for example response time below 10 minutes by week eight.
How to sequence the lines
Choose the next line by value, similarity and ownership. A bottleneck line returns the most value, and a line with the pilot's machine types reuses most of the work. It also helps a lot when the line owner asks for the system.
Avoid starting a line during a product launch. Roll out in waves of one or two lines, and do not run more lines in parallel than the owner of the standard can review each week. As a reference for pace, a modelled base case for a typical brownfield site shows 11 of 13 machines connected and visible in about three weeks; use it for planning and check it against your own lines.
Measure each line against its own baseline. The pilot line of one corrugated-packaging plant cut response time to a stop from 24 to 9 minutes; lines two and three will land at their own numbers. The first 90 days article lists what to track per line.
How to govern the standard
Name one owner for the standard and keep it versioned. Changes to frozen elements go through a short request: what changes, why, and which lines are affected. Review reason categories every quarter and remove those nobody uses.
DBR77's overview of CMMI and data maturity treats defined, standard processes as the entry point for automation at scale.
When several lines are visible, DBR77 IIoT hands off to DBR77 IRIS, which runs the response on all of them as one closed, repeatable execution loop. Our article on IoT as a repeatable operating system describes that step.
FAQ
How many lines should we roll out at once?
One or two per wave. The limit is not installation speed but the time the owner of the standard has to review each line weekly.
What if our lines are very different?
Freeze the state model, reason categories, alert logic and review cadence anyway. Differences belong in connections, detailed reasons and thresholds. That keeps the numbers comparable across lines.
Who should own the standard?
Someone from operations or continuous improvement. IT/OT owns connections and security; the standard is about how production responds.
How do we know the rollout is working?
Each line should beat its own baseline on response time and "unknown" downtime within a few weeks. If not, check alert routes and the daily review first.
When does IRIS come in?
When several lines are visible and the plant wants one execution loop for tasks, maintenance, quality and safety across all of them.
Conclusion
Most of the standard already exists on the pilot line, often only in the heads of the people who ran it. Before choosing line two, have that team fill in the playbook table above and name the owner of the standard. Then record two weeks of baseline on the next line and write down its week-eight target, for example response time below 10 minutes.
Plan your rollout across lines
We review your pilot results, draft the playbook with you and agree the order of the next lines.
Sources
- McKinsey & Company, IoT value set to accelerate through 2030, 2021
- McKinsey & Company, Lighthouse manufacturers illuminate path to the next normal, 2020
- World Economic Forum, Global Lighthouse Network: Adopting AI at Speed and Scale, 2023
- Lean Enterprise Institute, Standardized Work
- Vorne, World-Class OEE
- DBR77, CMMI and data maturity
- DBR77 IIoT pilot data and modelled base cases, 2026