The pilot worked. Why does the plant-wide rollout fail?

The pilot ran well, the review looked good, and then the second and third stations slowed down, and the project came to rest on some station and never moved again. In cases like this the technology is usually fine; what failed to keep up was the organisation. A pilot and a rollout are different things. The pilot runs on the concentrated attention and extra effort of a small group; the rollout requires turning that practice into a routine that does not depend on any one person.

The pilot may have been an exception

Before pushing the pilot outwards, answer one question honestly: why did the pilot succeed? Usually it depended on several conditions that a rollout does not have.

• One person’s effort. The pilot was usually nursed along by someone who knew the line and the technology, and tuned many of the rules by hand on site. Once that person is busy elsewhere, the rollout stops.
• One station’s special conditions. The station chosen for the pilot was often the one with good imaging and a comfortable cycle. Move to a reflective, dimly lit or fast station and the same rules will not hold.
• Management attention. During the pilot a manager was watching, and decisions were made the same day. In rollout the attention moves on, and the same decision waits days.

Five organisational reasons rollout fails

• No shared standard. Each station and team reads “pass” differently, so every new station defines its rules from scratch and the cost rises instead of falling.
• No owner for rollout. The pilot had a clear owner; the rollout became everyone’s job, which is to say no one’s.
• No scenario library. The rules tuned during the pilot, the samples collected and the traps hit were never organised into a searchable asset, so new stations start from nothing.
• Departments owning a slice each. Production, quality and IT each hold a piece, and nobody leads the cross-department alignment and integration, so the work stalls at the handover.
• Treating rollout as copy-and-paste. Assuming station two is like station one and reusing the configuration wholesale, only to be caught out by the imaging differences.

An unshared standard is where costs run away

Of the five, the unshared standard is the most underestimated. With one pilot station, the standard problem is hidden; once it spreads across stations and teams, renegotiating “what counts as pass” every time burns the project’s time on alignment instead of deployment. Worse, inconsistent standards make the data incomparable — a trend reported at one station is not the same measure as the trend at another, and a manager cannot act on a dashboard that means two different things. Resistance from the workforce is often tangled up with this: when the standard is vague, people feel judged against a rule nobody can state, and pushback grows, as why operators resist visual SOP sets out.

Three things to put in place before rollout

It is worth admitting that none of these three is a technical problem, and none is solved automatically by a piece of software. They are management actions: someone must approve the standard, someone must delegate the ownership, someone must keep the scenario library alive. The role of technology here is to make those actions cheaper — for example by making detection rules reusable, migratable configuration rather than something rewritten per station. If the resistance to rollout is organisational, the organisational problem is what to solve first. One more point is worth saying out loud: rolling out to the whole plant is not always the right answer. Some stations never had a business case, and forcing them in only adds maintenance burden. The pragmatic path is to rank scenarios by value, start with the ones that pay back, and put resources where they count — a rhythm the visual SOP pilot plan describes from the single station outwards.