Which plants or programs should I select for the first pilot?

Select a plant or program that is representative enough to prove value, but contained enough to control risk.

In practice, the best first pilot is usually not your flagship site, not your worst-performing site, and not the most regulated or qualification-sensitive program unless you already have strong validation discipline, integration readiness, and local leadership support.

What a good first pilot looks like

• Clear operational pain: The site has a visible problem worth solving, such as rework, routing confusion, paper delays, traceability gaps, training inconsistency, or poor handoffs between ERP, MES, QMS, or PLM.
• Stable local leadership: Plant and program leaders will make decisions, remove blockers, and hold the line on process changes.
• Manageable process scope: The workflow is important but narrow enough to implement without touching every product family, every shift, and every downstream system at once.
• Reasonable data quality: Core routings, part masters, revision control, and work instruction ownership are good enough to support a pilot. Perfect data is not required, but unmanaged master data problems will derail early results.
• Measurable baseline: You can compare before and after using lead time, rework, scrap, queue time, training time, execution errors, or traceability completeness.
• Some local credibility: The site is respected internally, so a successful pilot can influence other plants without looking like a special case.

What to avoid first

• Your highest-risk production program: If any downtime or workflow instability would create major delivery, customer, or qualification risk, it is a poor first pilot.
• The most customized plant in the network: If the site depends on years of local workarounds, undocumented tribal knowledge, and heavy legacy integration debt, it may teach the wrong lessons.
• A crisis site: Plants already dealing with leadership turnover, poor schedule stability, major quality events, or ERP/MES transitions often cannot absorb another change.
• A politically symbolic site: If the pilot is chosen mainly for visibility, the organization may optimize for appearances instead of learning.

How to choose between plants and programs

If your processes are mostly standardized across sites, choose a single plant where adoption is likely and results can be repeated elsewhere.

If variation between plants is high, choose a single program or value stream with a contained workflow that crosses fewer organizational boundaries. In many brownfield environments, program-level pilots are safer because they reduce the number of interfaces, exceptions, and approval paths that must be managed at once.

Either way, keep the first pilot small enough that you can validate process changes, train users, handle deviations, and maintain traceability without creating uncontrolled parallel processes.

Selection criteria that matter more than enthusiasm

1. Business impact: Is the problem real and costly?
2. Execution feasibility: Can the team implement with limited downtime and limited custom integration?
3. Validation burden: How much formal testing, document revision, and change control will the pilot trigger?
4. System coexistence: Can the new workflow coexist with current ERP, MES, PLM, QMS, and paper records during transition?
5. Replication potential: Will what you learn transfer to at least several other plants or programs?

A simple scoring model across those criteria is usually better than selecting the loudest site or the most senior sponsor’s preferred plant.

Brownfield reality

Do not pick the first pilot as if you are starting with a clean slate. Most plants have legacy transactions, local spreadsheets, partial interfaces, and long-established approval paths. Your pilot should be designed to coexist with those conditions, not pretend they are gone.

Full replacement strategies often fail in regulated, long-lifecycle environments because the qualification burden is high, downtime is hard to justify, integrations are deeply embedded, and traceability and change control obligations do not disappear during cutover. A pilot that works alongside existing systems is usually more credible than one that assumes a wholesale reset.

Practical rule of thumb

If you are choosing among several candidates, prefer the one that has:

• a painful but bounded use case,
• strong site leadership,
• acceptable data readiness,
• limited integration complexity,
• and metrics you can defend under scrutiny.

If you cannot identify those conditions, the issue may not be pilot-site selection. It may be weak process ownership, poor master data, unclear scope, or unrealistic rollout expectations.