A pilot that works is a good problem to have, and a surprising number of rollouts stumble right after that point. The instinct once a pilot proves itself is to connect everything at once, every machine, every line, every shift, and hand the plant manager a finished plant-wide dashboard. That instinct usually backfires. The plants that get a clean rollout follow a specific order, and skipping steps in that order is where most of the trouble starts.
Rates before dashboards
The first thing to lock down after a pilot, before adding a single new machine, is the plant’s own cost rates: downtime dollars per hour, scrap cost per part, whatever inputs turn raw stop and cycle data into a number that means something. This is boring work, and it’s tempting to skip it and just turn on more dashboards while the rates get sorted out later. Don’t. A dashboard built on placeholder rates trains the floor to distrust the numbers before it’s even seen a real one, and once that distrust sets in, it’s expensive to undo. Get the rates right on the pilot’s line first, confirm them against a supervisor who already knows roughly what things cost, and only then extend the same rate structure to new machines as they come online.
Decide who owns coding a stop, before more machines make it harder
A pilot on one line usually has one obvious person coding downtime reasons, an operator, a supervisor, whoever’s closest to the machine. Rolling out to ten lines means ten times the decision points about who’s responsible for that, and it’s a decision worth making up front instead of letting it default differently on every line. Some plants put it on the operator, closest to the cause and fastest to log it. Some put it on a shift lead reviewing stops after the shift wraps, slower but more consistent. Either can work. What doesn’t work is leaving it unspecified and discovering three months in that half the plant’s stops are uncoded because nobody was ever told it was their job.
This decision also determines what a rollout actually costs in training time. An operator-coded system needs a short, repeatable training moment on every new line, ideally taught by someone who already does it well on the pilot line, not by whoever installed the gateway. A shift-lead-coded system needs fewer people trained but a tighter review habit built into the end of each shift. Pick the model before scaling, not line by line as new supervisors ask how it’s supposed to work.
Write the decision down the same way a pilot’s success criteria get written down, and hand it to whoever’s running point on the next line before they start, not after they’ve already improvised their own version. A plant that lets each new line invent its own coding habit ends up with ten slightly different definitions of the same stop reason, which makes a plant-wide Pareto worthless even when every individual line’s data is accurate.
Extend the reason codes, don’t reinvent them
A related trap: letting each new line define its own list of downtime reasons instead of extending the vocabulary the pilot already proved out. A shared reason list, changeover, tooling, material wait, planned maintenance, quality hold, lets a plant manager compare across lines using the same words. A list that grows differently on every line, because nobody owned keeping it consistent, produces reports that can’t be compared to each other without a manual translation exercise nobody has time for. Keep one list, add a new reason only when none of the existing ones fit, and review the list on a regular schedule instead of letting each new supervisor bolt on their own.
Add machines by network cluster, not by importance
The instinct is to roll out to the most important machines first, the bottleneck, the highest-value line. That’s a defensible strategy for value delivery, but it should stay secondary to a more practical rule: add machines in the groups that already share a network connection. A cluster of machines already reachable from one gateway is a cheap, fast addition. A single important machine sitting on its own network segment across the building is a full new installation, wiring and all, no matter how much it matters. Sequence by what’s cheap and fast to connect first, building momentum and credibility, then spend the harder installation effort on the important-but-awkward machine once the rollout has proven itself repeatedly on easier ground.
When the second gateway actually earns its place
A second gateway isn’t about running out of capacity on the first one. It’s about reach. One gateway covers whatever it can physically get a wire, or a clean wireless connection, to on its own network segment. The moment for a second gateway is when the next cluster of machines to add sits somewhere the first gateway’s network can’t reach, a different building, a separated network zone, a floor with no existing path back to the first switch. Don’t add a second gateway preemptively assuming the first will run out of room. Add it when a specific group of machines is otherwise stuck waiting on cable that was never going to get run.
What to leave until the floor is ready
Not everything belongs in the first wave past the pilot. Advanced features, predictive alerts, AI-driven insight, cross-line benchmarking, work best once there’s real history behind them and a floor that already trusts the basic numbers. Turning those on too early risks the same problem a rushed dashboard creates: a claim with no track record yet, introduced before anyone has a reason to believe it. Let the core numbers, rates, stop reasons, a trustworthy Pareto, run long enough to earn trust on each new line before layering anything more ambitious on top.
What a good rollout order actually buys
None of this is about moving slowly for its own sake. A rollout done in this order, rates locked first, ownership decided up front, machines added by what’s cheap to connect, a second gateway added only when reach demands it, moves faster in the end than one that tries to do everything at once and spends months untangling confusion about whose numbers mean what. Every step in this order builds on something already trusted instead of adding a new source of doubt on top of an unproven one.
The plants that struggle most with a rollout are rarely the ones that moved too slowly. They’re the ones that connected everything in the first week, skipped the rate and ownership decisions, and spent the following quarter fielding the same “is this number right” question from every new line instead of building on an answer that already worked once.
Quick recap
- Lock down cost rates and confirm them against a supervisor before adding new machines, not after
- Decide who owns coding a stop, operator or shift lead, before scaling makes it a different answer on every line
- Add machines by which network cluster they already share, not strictly by importance, to keep the rollout cheap and fast
- Add a second gateway when a specific cluster of machines is out of the first gateway’s reach, not preemptively
- Hold advanced or predictive features until the basic numbers have earned trust on each new line
- A deliberate order moves faster overall than trying to roll out everything at once