How to Choose the First IoT Use Case in Your Plant
DBR77 Team · Published
The right first IoT use case is a loss that repeats every week, can be measured today, has one owner and can be acted on within a shift. If the data needed to see it is reachable in weeks rather than months, you have a strong candidate.
Why most first IoT projects stall
At the ITM Industry Europe 2026 panel on why AI in factories ends at the pilot stage, Paweł Dera, CTO of DBR77 IIoT, said that most technology and AI projects in factories do not stall because the model is too weak. They stall because nobody defined the decision it should improve. The panel recordings are available in Polish.
A typical project starts with "we want to be more data-driven". Six months later nobody can name one decision that changed. A model that changes nobody's decision is a pretty demo.
In McKinsey's survey of more than 700 manufacturing experts, less than a third had moved critical use cases into large-scale rollout. Its advice is to start from bottom-line value and work backward to the technology. Deloitte's smart factory study adds that when and how use cases are launched can decide whether they succeed.
Start by writing down the decision
Value appears when data is wired to a specific decision with an owner. Before you look at machines, write the decision in one sentence: "When X happens on line Y, role Z does this, within N minutes."
Examples that are specific enough:
- When the bottleneck filler stops for more than 3 minutes, the shift technician gets a task with the machine and the reason.
- When a changeover on press 4 runs 15 minutes over standard, the shift leader decides whether to move the next order.
- At the start of each shift, maintenance decides which three machines to look at first, based on yesterday's stops.
Each one names a trigger, a person and a time frame. A model that shortens a supervisor's response time or tells maintenance what to look at first is value you can count. "Better visibility" fails this test because it names none of the three.
Five criteria for a good first use case
Test each decision statement against five criteria. Weak candidates usually fail on owner or baseline.
| Criterion | Question to ask | Red flag |
|---|---|---|
| Repeated loss | Does this loss happen every week, ideally every shift? | It happened twice last year, but it was expensive |
| Measurable baseline | Can we measure the current state in two weeks? | "We think it is about an hour a day", with no data behind it |
| Clear owner | Is there one named role who acts on it? | The answer is "production and maintenance together" |
| Short response loop | Can someone act within the same shift? | The decision is made once a month in a meeting |
| Data reachable in weeks | Can we get the signals from existing PLCs or simple sensors? | It needs a new MES, ERP integration or six months of history first |
The first two protect the business case, and the last three make sure someone can act on the data within the same shift.
Test your candidate use cases with us
Bring two or three candidates. We score them together and agree a baseline, an owner and success criteria for a pilot on one line.
How to score candidates: an illustrative example
Score each candidate from 1 to 3 per criterion, maximum 15. The scores below are illustrative, for a typical mid-size plant.
- Response to stops on the bottleneck line: 14 of 15. Stops happen every shift, the shift leader owns the response, and the PLC already reports run and stop states.
- Changeover time on the press line: 12 of 15. A clear weekly loss and owner, but changeover start and end are not yet recorded consistently.
- Scrap on the extrusion line: 10 of 15. A real, repeated loss. Ownership is split between quality and production, and scrap counts are entered by hand.
- Plant-wide energy monitoring: 7 of 15. Easy data, but nobody owns a shift-level decision and the response loop is monthly.
- Predictive maintenance on the main compressor: 6 of 15. Failures are rare and there is no failure history to learn from.
The first candidate wins, and its machine states and stop reasons become the history that later use cases need. The use cases page shows where each typically fits.
Use cases that look attractive but make poor first choices
These sound strong in a board presentation. Most make good second or third steps.
Predictive maintenance. Prediction needs a clean history of states, stops and failures that most brownfield plants do not have yet.
Plant-wide dashboards. Connecting everything at once leaves no line where results can be proven. McKinsey's IoT research notes that there is no silver-bullet use case and that IoT must be grounded in business outcomes.
AI on messy data. If downtime reasons are guessed at the end of the shift, a model trained on them learns the guesses. Our article on CMMI and data maturity explains why process discipline comes first.
See also 7 mistakes factories make when implementing IoT.
What to do once you have picked one
Before the first device goes in, agree on:
- A baseline from two weeks of data, for example response time and the share of downtime with no reason.
- Success criteria, for example response time below 10 minutes by week eight.
- Who decides what happens after the pilot, and by when.
On one corrugated-packaging line, the pilot built around stop response followed this pattern. Average response time fell from 24 to 9 minutes and OEE rose from 61% to 70%. Vorne notes that most manufacturers run closer to 60% OEE, so the starting point was typical.
Next, turn the use case into a business case for IoT and plan the first 30 days.
FAQ
Should the first IoT use case be on the bottleneck line?
Usually yes, because every minute gained there is output gained for the whole plant. The exception is a bottleneck without a supervisor willing to own the project. A less critical line with a committed owner will prove the case faster.
How many use cases should we start with?
One, on one line. A second can follow once the first has a baseline, an owner and a measured result. With several at once, it is hard to tell which one created the value.
How long until we know whether the use case works?
For a response-time use case, the first signal comes in week one, because every stop and every reaction is time-stamped. Allow six to eight weeks before judging the effect on OEE.
Is predictive maintenance a good first use case?
Rarely. It needs a clean history of machine states and failures. Most plants build that history only after live monitoring is in place.
Conclusion
In the scoring example, response to stops on the bottleneck line came out on top because stops happen every shift, the shift leader owns the response and the PLC already reports run and stop states. If one of your candidates looks like that, write its decision sentence first, then collect two weeks of response-time data as the baseline before the first device goes in.
Plan your first use case on one line
We help you pick the use case, set the baseline and success criteria, and connect the line without stopping production.
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
- Deloitte Insights, Driving value from smart factory technologies, 2019
- Vorne, World-Class OEE, 2026
- DBR77, CMMI and data maturity, 2026
- DBR77 IIoT pilot data, corrugated-packaging line (client anonymous), 2026