Connect two or three machines in week one, not the whole floor. The first thirty days of a rollout are mostly about building trust in the numbers and agreeing on definitions. Full coverage is a second-month problem. Rush it, and you'll usually end up re-doing the first month's work once people stop believing the dashboard.
Start with the machines everyone already agrees matter
Pick the two or three machines where there's already informal consensus: the one that's the bottleneck, the one with the worst downtime, the one everyone already has an opinion about. Those machines give you a built-in test. Does the data match what people on the floor already believe? If it roughly does, you've earned the right to show people numbers on machines they don't have strong opinions about yet. If it doesn't match, that disagreement is the most useful thing you'll learn all month — either the informal belief was wrong, or the measurement is, and either way you want to know now.
Resist the urge to connect every machine at once just because the hardware makes it technically easy. Connectivity was never the constraint in the first thirty days. Trust and agreed definitions are, and neither scales by adding machines faster.
Don't put dashboards on the wall yet
The single most avoidable mistake in a rollout is putting a live dashboard on the shop floor wall before anyone has explained to the people working at those machines why the data is being collected. Skip that conversation and a dashboard reads as "now they're watching us" — and that impression is sticky. It's much easier to introduce monitoring as a measurement tool from day one than to walk it back from a surveillance tool after the fact.
The conversation that needs to happen first is simple and specific:
- What is actually being measured (machine state and cycle time, not operator behavior)
- What it will and won't be used for in the first month (finding bottlenecks and recoverable hours, not individual performance reviews)
- Who gets to see what, and when the floor itself will see it too — not just management
This doesn't need to be a formal meeting. It needs to happen before the first dashboard is visible, from someone the floor already trusts, and it needs to be honest about what the data will eventually be used for once the pilot period ends.
Establish what "normal" looks like before calling anything abnormal
A number without a baseline isn't information yet. Treat the first one to two weeks on a newly connected machine as a baseline-gathering period, not a performance period. The goal is finding out what normal availability, normal cycle time, and normal stop patterns look like on that specific machine, with its specific operators and its specific part mix, before anyone tries to improve anything.
This matters because the same raw number means something different on different machines. A machine doing frequent short tool changes will show a different availability baseline than one running long, uninterrupted cycles. Neither is wrong. But treat week-one data as immediately actionable instead of the baseline it is, and you'll end up chasing noise instead of real losses.
On one installation, the machine connected first wasn't the bottleneck — it was the one running the final operation, the step that converts straight into a shipped, invoiced unit. The bottleneck would have taught the team more eventually, but it also carries the steepest learning curve for a floor that's being monitored for the first time. The final-operation machine ties directly to a number everyone already tracks, so there's less to argue about before the baseline even starts. The bottleneck stayed on the list — just second, not first, since it takes longer to diagnose and fix whatever's actually wrong with it.
What the baseline turned up wasn't quite what people expected. The floor's instinct was that the final OEE number looked too low to be real. Whether that's a planning problem or a micro-stop problem turns out to depend on one thing: does that machine run the same part every cycle, or does the part mix change shift to shift? Change the mix often and bad scheduling shows up directly in the OEE number — a planning issue wearing an OEE costume. Get the planning right, and the same low number starts pointing somewhere else entirely: micro-stops nobody had been counting.
Who was running the machine mattered too. Operators running the same part day after day, generally less experienced, rarely pushed back on what the baseline showed — there wasn't much yet to disagree with. Turnkey, mixed-part work drew more scrutiny, and the operators on that work tended to be more experienced — they were the ones raising real process questions once the dashboard started surfacing stops nobody had been logging.
None of that got settled in an afternoon. Trusting the number enough to stop re-arguing it took several days, not one conversation. And once it was trusted, the data mostly didn't contradict what the floor already suspected — it mostly confirmed it, turning an assumption into something closer to proof.
Widening rollout after the first few machines prove out
Once the first few connected machines have a believable baseline and the floor-conversation has happened, widening to more machines goes faster — mostly because the definitions (what counts as planned downtime, what the rated cycle time is, when a stop counts as downtime at all) are already settled rather than being re-litigated on every new machine. That's the theory. On the installation above, widening past the first machine ran into exactly the re-litigating-definitions problem this guide warns about — the new machines didn't share the first one's part mix or operators, and some of what had been settled had to be argued through again rather than just carried over.
A practical sequencing pattern for weeks two through four:
| Week | Focus |
|---|---|
| 1 | Connect 2–3 consensus machines; baseline only, no judgments yet |
| 2 | Floor conversation happens; first real comparison against what people already believed |
| 3 | Widen to the next tier of machines using the now-settled definitions |
| 4 | First real decision made off the data — one loss identified, one cause addressed |
That last step matters more than it looks. The point of the first thirty days isn't data collection for its own sake — it's reaching the first decision the data actually changed. If day 30 arrives and nothing's been decided differently because of the dashboard, the rollout hasn't really started. It's just instrumentation sitting unused.
Give one person ownership, not just a sponsor
Rollouts that stall at thirty days often have an executive sponsor but no single person whose job it is to look at the data daily, answer floor questions about what it means, and decide when to widen coverage. A sponsor approves the budget. An owner is the person operators go to when a number looks wrong, and the one who notices if week three's baseline doesn't match week one's.
This doesn't need to be a full-time role in the first month. It needs to be one named person — not "the team," not "whoever has time." Diffuse ownership is how a rollout quietly stops being anyone's priority once the initial setup is done.
What "ready to widen" actually means
Before moving past the first few machines, check for three specific things instead of just a calendar date.
The baseline should have stopped moving. Availability and cycle-time numbers on the first machines ought to look similar week-over-week by the end of week two — still swinging significantly means unresolved definition drift, not real variation, and widening now just multiplies the confusion. At least one floor conversation should have actually happened, not just been scheduled; widen before operators on the new machines have heard the same explanation the first group got, and you've reintroduced the trust problem on a fresh set of people. And one decision should already have come out of the data on the first machines. A rollout that's only ever produced dashboards, never a decision, isn't ready to scale — it's ready to be asked what it's actually for.
Skip these checks in favor of a fixed "connect five more machines in week three" schedule, and you get the most common failure pattern there is: a rollout that started well, ten connected machines by day sixty, and zero changed decisions to show for it.
Keep the first month's definitions written down somewhere
Whatever gets agreed in week one or two — what counts as planned downtime, the rated cycle time for each part, when a short stop counts as downtime at all — write it down somewhere the whole team can see, not just in the head of whoever worked it out. Every new machine added after the first few raises the same definitional questions again, and a written answer from round one is faster and more consistent than re-deciding from scratch each time. Skip this and you'll find yourself re-litigating the same argument about planned maintenance time on the tenth machine that you already settled on the second.
Common thirty-day mistakes
Connecting everything, then arguing about definitions. Scaling an undefined measurement just multiplies the disagreement instead of resolving it. Skipping the floor conversation because "it's just data" — the absence of an explanation gets filled in by assumption, and the assumption is rarely favorable. Treating week-one numbers as final, when they're a baseline and not a verdict; judge a machine off its first few days and you've conflated settling-in noise with real performance. Picking the hardest machine to connect first because it feels the most important, instead of the one where trust is easiest to build — trust compounds, difficulty doesn't. And no decision by day 30: if the dashboard hasn't changed one real call by the end of the first month, that's worth noticing before rolling out any further.
What should be different by day 30
By the end of the first month, a rollout that's going well has two or three machines with a believable baseline, an agreed definition of planned downtime and rated cycle time that doesn't need re-arguing on the next machine, a floor that's heard directly why the data exists, and at least one decision the data actually drove. Not a dashboard nobody acts on.
The short version
Thirty days is enough time to prove a rollout is trustworthy. It's not enough time to cover every machine, and trying to do both at once is usually why rollouts stall. Pick a few machines people already have opinions about. Explain to the floor what's being measured and why before any dashboard goes up. Treat the first two weeks as a baseline, not a verdict. And widen only once a real decision has come out of the data — not on a fixed calendar date regardless of whether the first few machines are settled yet.
Want to see what the measurement side looks like once machines are connected? The full OEE guide covers how Availability, Performance, and Quality come together once the baseline period is done.
