The instinct when picking a pilot line is to point at the worst one. The machine that breaks the most, runs the slowest, causes the most arguments in the Monday meeting. It feels like the obvious choice: prove the system on the hardest case and everything else looks easy after. It’s usually the wrong choice, and understanding why changes what a pilot actually sets out to prove.
Why the worst line is the wrong first pick
A pilot has one job in its first thirty days: produce a number the floor trusts and a clear picture of what the system does when data gets messy. A chronically troubled machine makes both of those harder to see clearly. If it’s breaking down constantly, the data is dominated by one dramatic failure mode instead of the everyday pattern of stops that most machines actually run on, and a Pareto built from one bad month on one bad machine doesn’t generalize to what a rollout across ten normal machines will look like. Worse, when the machine’s problems are mechanical, not measurement problems, a pilot can end up proving the machine is broken, which everyone already knew, instead of proving the monitoring system works.
There’s a political risk too. A troubled machine carries history, blame, and defensiveness that have nothing to do with the pilot. Whoever’s closest to that machine may treat a new monitoring system as a threat, not a tool, and a pilot spent managing that reaction instead of building trust in the numbers is a pilot that starts from behind.
What to look for instead
Three traits matter more than drama: repetitive production, an existing signal source, and a leader who wants the data.
Repetitive production. A line running the same part, or a small family of similar parts, on a predictable cycle produces a clean baseline fast. A month of repetitive cycles gives a real average changeover time, a real per-part rate, a real sense of what normal looks like, all inside the pilot window. A line doing one-off, highly variable work never quite settles into a pattern in thirty days, which makes the first number harder to trust: there isn’t yet a stable normal to compare it against.
An existing signal source. A machine with a PLC already exposing run state, a controller with a counter, or even a simple part-present sensor already in place is a fast, low-risk connection. A machine with no usable signal at all forces a decision about added sensing before the pilot can even start collecting data, turning a thirty day software evaluation into a hardware installation project first. Pick a line where getting connected is close to trivial, so the pilot’s thirty days measure the system, not the time it took to wire up a signal that should have existed already.
A leader who wants the data. This matters more than either of the first two. A supervisor or line lead who’s curious about what the numbers will show, who already suspects something specific and wants to check it, turns a pilot into a partnership instead of an installation. That person checks the first Pareto against what they already know, flags when something looks wrong, and becomes the internal voice vouching for the system in front of the plant manager. A pilot run on a line whose leader is indifferent, or actively resistant, has to do all of that verification work from outside, slower and less trusted every step of the way.
Why the combination matters more than any single trait
Each trait alone isn’t enough. Repetitive production with no engaged leader produces clean data nobody looks at closely enough to trust. A leader who wants the data on a line with no usable signal source stalls immediately on wiring. A machine with a great PLC connection but wildly inconsistent production never produces a number stable enough to build confidence in during a short window. The three together are what make a pilot’s first month actually land: fast to connect, fast to stabilize, and fast to get checked by someone who cares whether it’s right.
What this looks like in practice
Walk the floor with these three questions instead of asking which machine is worst. Which lines run the same handful of parts most weeks. Which of those already have a controller or counter exposing something usable. And among that shortlist, whose supervisor has actually asked about getting better numbers, or complained about a specific thing they can’t currently measure. That last signal is often the clearest: a supervisor who’s already frustrated by not knowing something specific is telling you exactly where the pilot will land its first real finding.
It’s fine, and often smart, to run the pilot on a mid-tier line instead of the best or worst one on the floor. A line that’s fine but not exceptional, with a leader who’s paying attention, produces a first month that looks like most of the rest of the plant will look once the system rolls out further. The real test isn’t whether the system can handle the hardest problem on the floor. It’s whether the system works the way it’ll actually work across most of the floor, day to day.
This also tends to be the fastest path to a second pilot line, if the plan is to expand past one. A representative first line gives the plant manager a result that generalizes, not a special case that needs its own separate justification before anyone trusts it applies elsewhere. A second line chosen afterward can be more ambitious precisely because the first one already answered the basic question of whether the system works on a normal day.
Save the hard case for later
None of this means the worst machine never gets monitored. It means it isn’t where trust gets built first. Once a pilot has produced a number the floor believes and a leader willing to vouch for it, that same credibility carries into the harder case: the troubled machine, the odd protocol, the line with no clean signal yet. A system that’s already proven itself on a fair test earns the benefit of the doubt when it hits a demanding one. A system asked to prove itself on the hardest case first has no credibility banked yet to fall back on if week one looks rough, even when the rough result is really about the machine, not the measurement.
Quick recap
- The worst machine on the floor is usually the wrong first pilot line, its data is dominated by one failure mode and it carries baggage the pilot doesn’t need
- Look for repetitive production, so a real baseline forms inside the pilot window
- Look for an existing PLC, counter, or sensor, so connection time doesn’t eat into the pilot’s data-collection time
- Look for a leader who actually wants the data: they’ll check the numbers, catch what’s wrong, and vouch for what’s right
- All three traits together matter more than any one alone: a mid-tier line with an engaged supervisor beats a dramatic one without
- Save the hardest machine for after the pilot has built credibility on a fair test