When Operators Don't Trust the Data: Getting IoT Adopted on the Floor
DBR77 Team · Published
Operators start trusting IoT data when it matches what they see at the machine, when their input visibly changes something, and when the numbers are used to help them. If any one of these is missing, they ignore the screen, pick "other" as the stop reason and keep their own notebook.
Distrust in the first weeks is normal, and it is useful. It usually points at a real problem in the data or in how the data is used. This article shows how to find that problem and fix it.
Why operators distrust machine signals
On a typical brownfield line, distrust comes from a few sources. Each one has a cause you can fix.
| Operator concern | What is behind it | What to do |
|---|---|---|
| "The screen says we were down, but we were running." | Wrong state logic, e.g. a break counted as downtime | Validate states with operators before publishing numbers |
| "None of the reasons fit what happened." | Reason list written in the office or copied from the ERP | Rewrite the list with operators, in their words |
| "This is just to check on us." | Data shown per person, or used in a disciplinary talk | Agree in writing what the data is for; report per line and shift |
| "We said it before, nothing happens." | Inputs disappear and nobody reports back | Show each fix that came from operator input |
An IoT rollout is a change project, and the floor decides if it works. Prosci found that projects with excellent change management were about seven times more likely to meet objectives than projects with poor change management.
Fix the data before you ask for trust
Wrong numbers burn credibility you will need later, so fix the signal before you publish anything.
A machine counts as "running" because motor current is above a threshold, while it idles without material. A changeover shows up as unplanned downtime. Slow cycles stay invisible because only the stack light is read.
For example, the system might show 40 minutes of downtime on a press while the operator remembers 15. The difference is a 25-minute break nobody entered in the shift calendar (illustrative numbers). One wrong figure like that on a board makes the whole system look unreliable.
A short validation routine prevents this:
- Run the system for one to two weeks without publishing numbers.
- Each shift, the operator and shift leader compare the machine timeline with what happened.
- Every mismatch becomes a correction: a threshold, a calendar entry, a missing signal.
- Publish only when operators agree the timeline looks like their shift.
Our article on why machine data is useless without context explains which context to add.
See what operators see
In a 30-minute online demo we show the operator screen, reason capture at the stop and how the line owner edits reason lists without IT.
Let operators write the reason list
Downtime reasons written in an office rarely match the floor. Operators then choose "other" or the first item, and the Pareto fills with noise.
Sit with two or three operators per machine type for an hour and ask what actually stops the machine. Keep 10 to 15 reasons, in their words. "Waiting for forklift" works better than "Internal logistics delay".
There is evidence for this outside IoT. In a shift handover project described by The Keil Centre, the people using the new logs co-designed them, and the author credits that involvement with the scheme's success (Lardner, 1999).
Review the list monthly. If "other" is above about 10% of downtime, a reason is missing. In the DBR77 IIoT operator app, the line owner changes the list without a ticket to IT.
Show operators the wins from their own input
Operators trust the system much sooner once they see their own input lead to a fix, and they stop giving input when it disappears.
Take a typical situation. Operators on a packing line keep tagging short stops as "film jam". After three weeks, the data shows it is the largest loss on the line by minutes, although each stop lasts under two minutes. Vorne notes that most companies do not accurately track such small stops. Maintenance changes the film guide and the stops drop (illustrative example).
Then tell the shift. Put it on the board at the line: "You tagged 'film jam' 140 times in three weeks. The guide was changed on Tuesday. Here is the chart since then." Operators learn that their two seconds at the stop were worth it. Toyota puts it plainly: machines stop on an abnormality, but "only humans can implement kaizen".
How to review operator overrides
Sooner or later operators override the system. They change a reason later, mark a stop as planned or acknowledge an alert without acting. The first reaction is to call it cheating, and that reaction is usually wrong.
An override is information about a rule that does not fit the real process. The UK Health and Safety Executive notes that deliberate deviations from procedure often occur where the task has been poorly designed, and prefers redesign of the task or equipment as the fix.
Review overrides weekly with shift leaders:
- Group them by rule. Ten overrides of one alert threshold are one finding.
- Ask the operator why. The answer is usually simple: the alert fires during planned cleaning, or a common case is missing.
- Change the rule or explain it. If it is wrong, change it and say so at the next shift start.
- Track the override rate. It should fall over time.
Noisy alerts are a common trigger; see why IIoT alerts fail on the shop floor.
Use data for help, not for punishment
The fastest way to lose the floor is to use the first month of data in a disciplinary talk. After that, reasons get vaguer and overrides go up.
People also change behaviour when they know they are measured. A systematic review in the Journal of Clinical Epidemiology concluded that being studied does affect the behaviour being studied. Operators who feel watched will make the data show how they want to look.
Write down a few rules before go-live: data is reviewed per line and shift, with no ranking of individuals; a stop leads to a question about the process; operators see the same screens as managers; employee representatives see the rules first.
FAQ
How long does it take before operators trust IoT data?
Expect four to eight weeks on one line. Trust follows a timeline that matches their shift and at least one visible fix from their input.
Should operators be allowed to change a stop reason later?
Yes, within the same shift and with a log of the change. Blocking corrections pushes people to "other". Logged changes show where the reason list or state logic is weak.
Should we show OEE per operator?
We advise against it in the first months. Performance depends on material, maintenance and planning as much as on the person.
What if one shift keeps rejecting the system?
Spend a shift with them. Usually they have found a real fault in the data, or numbers were used against them. Fix that first.
Conclusion
Expect four to eight weeks before operators on a line trust the numbers, and most of that time goes into getting the timeline right. Pick one line and run it for one to two weeks without publishing anything. At the end of every shift, have the operator and shift leader compare the machine timeline with what happened, and turn each mismatch into a threshold, calendar or signal correction before the first number goes on a board.
Plan a pilot the floor will accept
We set up validation weeks, operator-written reason lists and an override review with you before any number goes on a board.
Sources
- Prosci, The Correlation Between Change Management and Project Success, 2023
- The Keil Centre (R. Lardner), Safe Communication at Shift Handover: Setting and Implementing Standards, 1999
- Vorne, The Six Big Losses
- Toyota Motor Corporation, Toyota Production System
- UK Health and Safety Executive, Managing human failures, 2024
- McCambridge J., Witton J., Elbourne D., Systematic review of the Hawthorne effect, Journal of Clinical Epidemiology, 2014