Multi-Site IoT: What to Standardize and How to Prove Value Across Plants
DBR77 Team · Published
Across several plants, standardize only what makes numbers comparable: the machine state model, the top-level loss categories, KPI definitions, the data model and the security baseline. Leave detailed downtime reasons, alert thresholds and meeting rhythm to each plant, and prove value by tracking every site's change against its own baseline.
Forcing one full template on every site tends to fail in two ways: local teams stop owning the system, and the headline numbers still do not compare, because each plant counts planned time differently.
Why one template across plants rarely works
A template is usually designed at headquarters, around the flagship plant. Then it meets a site with older presses, or one where operators speak another language. Reason lists stop matching the machines, and thresholds tuned for one line create noise on another. Soon the plants keep a parallel spreadsheet "for real use".
The opposite mistake costs as much. If every plant builds its own setup, the board gets five definitions of OEE and no way to add them up. McKinsey describes how many companies stay in "pilot purgatory" and names a clear owner, design for scale and interoperability as conditions for value at scale. What works better is a thin standard: a small core fixed at every site, with the plants free to set up everything around it.
What to standardize and what to leave local
Fix centrally whatever the group numbers depend on, and leave to each plant whatever its daily work on the floor depends on.
| Element | Standardize across all sites | Leave to each plant |
|---|---|---|
| Machine states | The same state model: running, planned stop, unplanned stop, no order | Which signal detects each state on each machine |
| Loss categories | Top-level categories mapped to availability, performance and quality | Detailed reasons, 10 to 15 per machine type, in the local language |
| KPI definitions | Formulas for OEE, response time and repair time, and what counts as planned time | Targets for each line |
| Data model | Asset hierarchy (site, area, line, machine), naming, time stamps | Extra fields and local dashboards |
| Security baseline | Network segmentation, access roles, remote access rules | How each plant implements them on its network |
| Alerts and meetings | Every alert has an owner and an escalation rule; a daily loss review exists | Thresholds, escalation minutes, meeting time and format |
The six big losses are a practical set of top-level categories because they map directly to the three OEE factors. The equipment hierarchy in ISA-95 gives IT and production a shared vocabulary for the data model. ISO 22400 offers a framework for defining manufacturing KPIs. The security baseline should follow ISA/IEC 62443, written for industrial control systems.
How to compare sites fairly
Most cross-site comparisons go wrong on definitions. Vorne's guide to calculating OEE excludes breaks from planned production time but counts changeovers as stop time. If one plant also excludes changeovers, its availability looks better with nothing changed on the floor. Ideal cycle times work the same way: set one too low and performance looks better than it is.
Four rules keep the comparison honest:
- Same definitions everywhere. One written definition of planned time, stop time and ideal cycle time, under central change control.
- Normalise by planned time. Report downtime minutes per 100 planned hours and stops per planned hour. A three-shift plant will always log more stops than a one-shift plant.
- Compare trends, not absolute OEE. Vorne advises not to fixate on the absolute value of OEE and warns against comparing dissimilar processes. A high-mix plant with many changeovers will show lower OEE than a plant making one product.
- Show the split. Report availability, performance and quality separately, so a quality drop cannot hide behind an availability gain.
An illustrative example: Plant A holds a steady 72% OEE for two quarters. Plant B moves from 58% to 65%. A ranking puts Plant A on top. The trend shows that Plant B added seven points from the same machines, and its methods are worth copying.
Planning a rollout to a second or third plant?
Tell us how your sites differ today. In a short call we sketch which elements to fix centrally and which to leave to the plants.
What belongs on the executive scorecard after scale-up
An executive scorecard should fit on one page and show whether each plant is improving against its own starting point, and what that is worth. For each site, include:
- Change in OEE points against the site's baseline, with availability, performance and quality shown separately.
- Median response time from a stop to the first action, which usually moves first.
- Share of downtime with no reason. A rising share means data quality is slipping, usually before the results drop.
- Coverage: the share of in-scope machines connected and with reasons captured at the stop.
- Value in money, using each site's own value of one OEE point.
- Top-loss actions closed in the quarter.
Leave these out, because they start the wrong conversation:
- a league table of plants by absolute OEE;
- alert counts and dashboard logins, which measure activity, with no link to results;
- machine-level detail, which belongs in the plant's own reviews.
Where cameras and cloud analytics fit across sites
Every plant has stations without a usable signal, such as manual assembly or packing. A camera can act as the sensor there. DBR77 processes data on site at the edge. For multi-site analytics, IRIS Vision AI can also run inference in the cloud with the same application and models. Every plant then measures a manual station the same way.
The scorecard also shows where a loss is structural. If a site's top loss is a manual palletising step, the next move may be an automation project. Plants can publish that challenge on DBR77 Marketplace and compare integrator offers in one format.
Who owns what between headquarters and the plants
Headquarters owns the thin standard: definitions, data model, security baseline and scorecard. Changes go through change control, as described in IoT governance after the first year.
Plants own reason lists, thresholds, alert routes, meetings and improvement work. Each new site follows the path from one successful pilot to a plant standard and builds its own rhythm, as described in turning IoT into a repeatable operating system.
FAQ
Should all plants use the same downtime reason list?
No. Standardize the top-level categories and let each plant keep its own detailed reasons. Map every local reason to one category, so the group view adds up.
Can we compare OEE between plants at all?
Only between similar processes with identical definitions of planned time and ideal cycle time. Even then, the change against each plant's baseline says more.
How do we put a group-level value on IoT?
Calculate the value of one OEE point for each site separately, using its own margins and planned hours. Multiply by that site's change in points, then add the sites together.
Where should the data be processed?
On site, inside each plant's IT/OT boundary, for the line itself. Aggregated results and, where needed, Vision AI inference can run centrally for comparison across plants.
Conclusion
Before the next plant goes live, write down the shared definitions of planned time, stop time and ideal cycle time, and map each site's local reasons to the top-level categories. Then record every site's baseline and its own value of one OEE point, so the first scorecard shows the change in money as well as in points. The change control that keeps those definitions stable is covered in IoT governance after the first year.
Build a scorecard your board can trust
We help you define the shared core, the site baselines and a one-page scorecard before the next plant goes live.
Sources
- McKinsey & Company, IoT value set to accelerate through 2030: Where and how to capture it, 2021
- Vorne, World-Class OEE
- Vorne, Calculating OEE
- Vorne, The Six Big Losses
- ISA, ISA-95 standard
- ISO, ISO 22400-1: Key performance indicators for manufacturing operations management, 2014
- ISA, ISA/IEC 62443 series of standards
- DBR77, IRIS
- DBR77, Marketplace