Plan your rollout

Take a plant from a boxed sensor to a shop floor that acts on its own data, in four phases.

Rollouts stall in the same place. The pilot produces numbers nobody trusts, so nobody acts on them, and the project is judged on that. The sequence below is built to close that gap in the first two weeks.

Each phase ends at a gate. Do not start the next phase until the gate closes, even if the hardware for it is already on site.

The four phases

The four rollout phases and the gate that has to close before each one ends.A left-to-right timeline of four rollout phases, each box naming the phase and its duration: 1. One line, 2 weeks; 2. Operator adoption, weeks 3 to 6; 3. Downtime reasons, weeks 6 to 12; 4. Scheduling and maintenance, month 3 onward. An arrow runs left to right beneath the boxes and passes through four diamond gate markers, one under each phase. The gate under each phase reads, in order: a supervisor agrees with yesterday’s numbers; 95% of stops classified within 24 hours; top three categories have an owner and a date; jobs and work orders live in IoTFlows. The arrow only continues past a gate once that condition is met.

Phase 1: one line, two weeks

Pick one line and monitor three to five machines on it. Choose the bottleneck and the machines whose problems you already argue about, because those are the ones a supervisor can check the data against from memory.

Choose a pilot line with a single-shift schedule and a stable part mix. A three-shift cell with changeovers will produce data you cannot yet explain, and the pilot will be judged on that.

Set the organization timezone and the shift schedule before the first sensor reports. A shift is a named window of the working day, and every number IoTFlows reports is bucketed into one. Shift changes do not apply to data already recorded, so a shift set wrong in week 1 leaves week 1 permanently unreadable. See Set shifts and the organization timezone.

Then bring up the hardware. Quickstart covers one machine end to end: mount the device, get it on Wi-Fi, create the asset, and confirm data is arriving.

Spend 15 to 20 minutes calibrating each device rather than five. A SenseAi on the machine housing can read the machine well, but only calibration tells you whether it does.

Run the machine cutting and then idle, and adjust the thresholds until the two read differently. Until someone does that, a device can report a cutting machine as stopped, and every number built on it is wrong.

Set a first uptime goal 5 to 10 points above the current average, not at the number you wish you had. Uptime is the share of scheduled time a machine spent running; see the metrics reference. If the line runs at 55% today, set the goal at 60%.

The gate. A supervisor opens yesterday on the assets overview and agrees with what it says. If they can point at a stop that the system missed, fix calibration before going further.

Phase 2: operator adoption

Phase 1 tells you a machine stopped. Only an operator can tell you why. This is the phase most rollouts skip, and skipping it is what leaves you with months of unclassified downtime.

Put a screen next to each monitored machine. In Devices, open Assign to Local Device and use Assign Asset to tie the tablet to its machine, so the operator sees their own line and nothing else. See Set up operator stations.

Train on the why before the how. Operators need to hear that the data is used to remove the obstacles that slow them down, and that it is not used to rank people. A system introduced as a scoreboard gets gamed within a week.

Turn on alerts in this phase, not at the end. An alert that reaches a supervisor's phone while the machine is still down is what turns a report into a response. Start with one rule on the pilot line, for example a stop longer than 15 minutes on the bottleneck. See Alerts overview.

The gate. 95% of downtime events on the pilot line are classified within 24 hours, for two consecutive weeks.

Phase 3: downtime reasons that mean something

A downtime category is the reason an operator assigns to a stop, for example Tool change or Waiting on material. The category list is the single largest lever on whether the data is worth reading.

Keep the list short. Eight to twelve categories that map to an action beat forty that map to a feeling. An operator facing a forty-item list picks the first plausible one, and a Pareto chart built from that answers nothing. See Set up downtime categories.

Automate the stops that have only one possible reason. Rules can classify micro-stops under two minutes, shift changeovers, and scheduled breaks without an operator touching them, which leaves the operator's attention for the stops that are actually ambiguous. See Classify downtime automatically.

Review the data on a fixed weekly slot with supervisors, maintenance, and continuous improvement in the room. Sort Downtimes by total duration for the past week, take the top three, and give each one a name and a date.

The gate. The top three categories each have an owner and a deadline, and last week's top three were reviewed against this week's.

Phase 4: scheduling and maintenance

Once downtime data is trusted, the same machine records can carry the work. Production Scheduler plans jobs against real cycle times instead of estimates, and Maintain turns a recurring downtime category into a preventive maintenance schedule.

You do not need phase 4 if your goal was to find out where the hours go. Phases 1 to 3 answer that on their own, and a plant that adopts scheduling before its operators classify downtime is planning against numbers it does not believe.

Add these one product at a time, on the pilot line first, for the same reason phase 1 started with one line.

Pitfalls

Monitoring the whole plant in week 1. Forty machines produce forty calibration problems at once, and nobody can tell a bad sensor from a bad shift schedule. Start with three to five.

Setting the goal at the industry benchmark. A team that starts 30 points below its target stops looking at the target. Raise it as the line improves.

Using the data to punish. Operators who are measured rather than helped hide problems, and the classification rate collapses. The gate in phase 2 is the first thing to go.

Installing and forgetting. Devices drop off Wi-Fi and calibration drifts. Check Devices weekly for anything offline or reconnecting repeatedly.

Growing the category list to cover every case. Every category added past roughly a dozen dilutes the ones that matter. Add a category only when someone would act differently because of it.

A readiness checklist

Before you call a phase done:

1. The organization timezone matches the plant, and every shift is defined with its real start and end times.
2. Each monitored machine reads as running when it is cutting, and stopped when it is not.
3. Each machine has an uptime goal set from its own history.
4. Every monitored machine has a screen an operator can reach without leaving the machine.
5. Operators have been told what the data is for, by their own supervisor.
6. At least one alert rule reaches a phone or a chat channel.
7. The category list is under a dozen entries and every entry names an action.
8. A weekly downtime review is on the calendar with named attendees.

See also

• Set shifts and the organization timezone
• Set up downtime categories
• Alerts overview
• Quickstart: see your first machine's data