7 Mistakes Factories Make When Implementing IoT
DBR77 Team · Published
The seven most common mistakes factories make when implementing IoT are: no decision defined, IT-only ownership, too many lines at once, no baseline, alerts without owners, reason codes copied from the ERP, and a program that depends on one champion. None of them is about sensors or software.
Each one turns IoT into an expensive reporting system. Below: how to spot each mistake and what to do instead.
The question that shows whether IoT is working
When a client tells Paweł Dera, CTO of DBR77 IIoT, "we already have IoT", he asks one question: "What did you change in the process last month based on data from the system?" Often nobody can name anything.
The dashboards look impressive, but decisions are still made on experience. Usually nobody answered three questions at the start: which five metrics matter, who acts on each one, and which threshold triggers an action.
In a McKinsey survey of more than 700 manufacturing experts, less than a third had moved critical use cases into large-scale rollout. The World Economic Forum described 70% of manufacturers as stuck in "pilot purgatory".
Mistake 1: No decision defined
At the ITM Industry Europe 2026 panel on why AI in factories ends at the pilot stage, Paweł Dera traced most stalled projects to the same gap: nobody had written down which decision the model was supposed to improve. The recordings are available in Polish.
"We want to be more data-driven" names no trigger, owner or time frame, and a decision needs all three. Before go-live, write a short decision contract for the line:
- Five metrics that matter, for example availability, response time, top stop reasons, output per shift and scrap.
- One role that acts on each metric, per shift.
- One threshold per metric that starts a specific action by that role.
If you cannot fill this in, the project is not ready to connect machines. Our guide on how to choose the first IoT use case shows how to find a decision worth starting with.
Mistake 2: IT owns the rollout alone
IoT touches networks and security, so it often lands in IT. IT delivers connected machines and dashboards, and nobody on the floor changes how they work.
McKinsey's IoT research found that many deployments are run by IT rather than as business transformations, and that companies that succeed assign a clear owner.
Split the ownership instead. Production owns the rollout and the results: a line owner who decides what matters and who acts. IT and OT own the network, access and security. Maintenance owns the response to technical stops.
See how decisions, owners and alerts look in practice
In a 30-minute online demo we show how DBR77 IIoT links each stop to a reason, an owner and a response time on a live line.
Mistakes 3 and 4: Too many lines, and no baseline
Connecting the whole plant at once feels efficient. In practice, effort spreads thin and no line gets enough attention to change habits.
The fourth mistake usually comes with the third: there is no baseline, so without "before" numbers the project is judged on opinion. Two weeks of data on one line is enough. Measure the minutes from stop to first action, the share of downtime with no reason, and the top three losses by minutes.
Mistakes 5 and 6: Alerts without owners, and reason codes from the ERP
Alerts sent to "maintenance" or to a group chat have no single recipient, and after a week people mute them. Every alert needs one role on the current shift, and an escalation rule, for example: no acknowledgement within 5 minutes and the shift leader is notified.
Reason codes copied from the ERP were written for cost accounting, and an operator at a stopped machine thinks in different words. Faced with dozens of codes in finance language, operators pick "other". Keep 10 to 15 reasons per machine type, in the words people use on the floor. Vorne's guidance on the six big losses gives an example of a clear policy: any stop longer than two minutes gets a reason.
On one corrugated-packaging line where alerts became tasks with an owner and operators picked the reason at the machine in about two seconds, average response time fell from 24 to 9 minutes. The operator app shows how reason capture works, and what data to collect from machines covers which signals to start with.
Mistake 7: The program depends on one champion
Many IoT programs run on one enthusiastic person. When that person leaves, reviews stop and the system becomes a screen on the wall. Make the program independent of any one person:
- Documented standards: state definitions, reason lists, alert routes and thresholds written down and versioned.
- Named roles: line owner, data owner and response owner per shift, with a deputy for each.
- A fixed cadence: a 10-minute review at the start of each shift and a monthly review of thresholds and reasons.
These three elements also turn a pilot into a plant standard.
The seven mistakes at a glance
| Mistake | Symptom on the floor | Fix |
|---|---|---|
| No decision defined | Nobody can name a change made last month based on the data | Decision contract: five metrics, one owner each, action thresholds |
| IT-only ownership | Machines connected, dashboards live, work unchanged | Production owns results; IT and OT own network and security |
| Too many lines at once | Many screens, no line with a proven result | One line first, then a repeatable rollout |
| No baseline | Results argued over in meetings | Two weeks of "before" data on the pilot line |
| Alerts without owners | Notifications muted within weeks | One role per alert, plus an escalation rule |
| Reason codes from the ERP | "Other" and "unknown" top the Pareto | 10 to 15 operator-language reasons per machine type |
| One champion | Program fades when that person leaves | Documented standards, named roles with deputies, fixed review cadence |
FAQ
How can we tell if our IoT system is only a reporting tool?
Ask what you changed in the process last month because of the data. If nobody can name a change, start with a decision contract for one line.
Who should own an IoT rollout in a factory?
Production should own the results, through a line owner who decides what matters and who acts. IT and OT own the network, access and security. Without a production owner, the project delivers dashboards and little else.
Can we fix these mistakes on a system that is already running?
Yes. Most of the fixes concern decisions, owners and reason lists. The hardware usually stays as it is. Pick one line, define the decision contract, collect a two-week baseline and rebuild the reason list with operators.
How many lines should a first IoT rollout cover?
One. Prove the result there, document the standard, then roll it out line by line.
Conclusion
If IoT is already running in your plant, go through the table above for one line, together with its line owner. Start with the first row: if nobody can name a process change from last month, write the decision contract described under Mistake 1 before changing anything else.
Check your IoT setup against these seven mistakes
Book a 30-minute demo. We show how DBR77 IIoT handles decisions, owners and reasons, and where your current setup could be losing value.
Sources
- DBR77, ITM Industry Europe 2026 conference recordings (in Polish), 2026
- McKinsey & Company, How digital manufacturing can escape "pilot purgatory", 2018
- McKinsey & Company, IoT value set to accelerate through 2030, 2021
- World Economic Forum, These 10 new 'Lighthouse' factories show the future of manufacturing is here, 2020
- Vorne, The Six Big Losses, 2026
- DBR77 IIoT pilot data, corrugated-packaging line (client anonymous), 2026