The smart factory cannot be cloned

A successful pilot creates a dangerous illusion. Once a new system improves quality or shortens deployment time at one plant, the obvious next step appears to be replication: package the technology, copy the process and repeat the result across the network. The difficulty is that manufacturers do not own 20 versions of the same factory. They own sites shaped by different acquisitions, equipment generations and local workarounds.

The first plant often conceals those differences because the project team has chosen an environment where the data is accessible and leadership is supportive. Scaling exposes everything the pilot did not have to confront. Cécile Vercellino, Senior Vice President for Industrial Automation Services and Advisory at Schneider Electric, has seen this repeatedly across global transformation programs. “You cannot duplicate like for like from one factory to another and say, ‘Take what has been done and redo it.’ You generally must do the same job factory by factory because the back end is not the same. You are more efficient the second time, but it is not a copy-and-paste system.”

What the pilot leaves out

Pilot projects are designed to prove value, which makes them useful, but they are rarely representative. One site may have a modern MES and an operations team willing to experiment. The next may depend on legacy software and manual workarounds that have never been documented because they evolved gradually around the needs of the plant.

Toby Mankertz, Manufacturing Industry Director at Columbus UK, describes the same gap when companies move from a first implementation to a wider rollout. “You might be an organization with operations in 20 countries and 30 factories, and you have made the rash assumption that all those instances work in the same way,” he says. “It is when you push out the technology that you find this is not necessarily the case. Even after you involve people widely, there will still be localizations because of regulations, operating differences or cultural barriers.”

Those differences are not always signs of poor management. A factory producing a different product mix may need a different workflow, while another has built years of practical knowledge around equipment that no longer exists elsewhere in the group. Trying to erase every variation can remove the practices that keep production stable.

The mistake is to treat local complexity as an obstacle to be eliminated rather than information that should shape the design. A scalable program must identify which differences are accidental and which reflect legitimate operating needs. Only then can the organization decide what must be common and what should remain flexible.

Standardize the foundations, not every decision

Manufacturers still need standardization. Without it, each plant creates its own data structures and deployment methods, turning every use case into another bespoke project. The answer is to standardize the foundations that plants should not have to reinvent while leaving room for local execution.

For Pierluca Chiodelli, Vice President of Product Management at Dell Technologies, edge computing only becomes scalable when it is treated as an operating model rather than a hardware exercise. “It is tempting to spin up a custom, siloed solution every time a plant needs a new efficiency gain, but those snowflake one-offs add up fast,” he explains. “You are left with a jumbled model with no real integration or cohesion. Lasting value comes from secure onboarding, centralized lifecycle management and support for both legacy industrial systems and newer AI workloads.”

This distinction changes the purpose of a corporate standard. It should not prescribe every screen an operator sees or every rule a production team follows. It should define how applications are deployed and how access and updates are controlled across the estate.

Common foundations make local adaptation safer. A plant can configure a quality application for its products or adjust an AI model to its process without creating a separate security regime and support model. The enterprise gains consistency where inconsistency creates risk, while the site retains flexibility where local knowledge matters. Standardization becomes an enabler of local improvement rather than a demand for uniformity.

Blueprints should travel, not freeze the factory

The most useful scaling model resembles a blueprint rather than a clone. It captures the repeatable components of a successful implementation but expects each site to complete the design around its own operating conditions. The blueprint is therefore a starting point, not a command to reproduce the first plant.

One customer deployment shared by Chiodelli shows how this can work at scale. Eaton, the global power management manufacturer, needed to modernize a network of more than 230 manufacturing facilities without creating another collection of isolated edge systems. Working with Dell Technologies, it introduced reusable digital blueprints and centralized orchestration, reducing software deployment time from three to six months to just days, an improvement of more than 90%. Chiodelli says the significance lies in the operating model: “The benefit was not simply putting infrastructure in plants,” he explains. “It was creating a secure and repeatable way to push intelligence closer to production across a global manufacturing footprint.”

A blueprint also creates a better relationship between central teams and plants. Corporate leaders can define the non-negotiable principles and provide tested components. Local teams can then show where equipment or process design requires an adjustment rather than quietly building around a template that does not fit.

This reduces the risk of false standardization, where every site appears to use the same platform but has created hidden exceptions underneath it. Those exceptions eventually make upgrades harder and weaken the enterprise view the standard was supposed to create. A blueprint should make variation visible rather than force it underground.

Scaling is an organizational discipline

Technology is rarely the main reason a rollout stalls. The greater challenge is the organizational effort required once a project moves beyond the team that created it. Governance must become clearer, operational ownership must shift to the people running the process and the benefits have to survive after the original project team moves on.

Dave Philp, Chief Value Officer at Bentley Systems, sees the same issue in the scaling of digital twins. “The biggest challenge is not technological,” he notes. “Pilot projects often start with enthusiastic innovation teams and dedicated resources, but scaling requires governance, standardization and operational ownership. If every new digital twin becomes a bespoke project, it is expensive and impossible to scale. We must treat digital twins as enterprise infrastructure rather than one-off innovation projects.”

Philp’s point applies well beyond digital twins. A corporate platform will not create consistency if every site interprets the program differently or if accountability disappears after deployment. Scaling needs a permanent structure that owns the architecture, measures value and manages the tension between global standards and plant-level reality.

Change management also must travel with the technology. Schneider Electric did not scale its lighthouse factory program by copying equipment from Le Vaudreuil into every other site. It repeated the management disciplines behind the transformation and developed a structured program for involving the workforce.

Vercellino describes this as a continuous journey rather than a one-time rollout. “We reused the same approach, but not only the same technology,” she adds. “We standardized the different phases of change management and now implement them across the factories. It requires a systematic program because the transformation is never finished; the technology evolves, the objectives change and the people need to remain part of it.”

Local variation is a source of intelligence

Manufacturing groups often discover their own operating reality only when they try to impose a common system. A rollout reveals that plants use different naming conventions or have developed unofficial processes to compensate for gaps in existing systems. This can slow deployment, but it also creates an opportunity to understand why those differences exist.

Some should be removed because they add cost without creating value. Others reveal practices worth sharing across the network. A local maintenance routine may reduce downtime, while a scheduling method developed at one plant may respond better to volatile demand.

A platform that cannot accommodate useful local variation will encourage workarounds. A platform with no standards will make every improvement difficult to share. The operating model must therefore be firm at the core and adaptable at the edge, with a clear process for deciding which local changes remain local and which should become part of the enterprise blueprint.

This is where multi-site transformation becomes more than a technology rollout. Each deployment produces new evidence about how the organization actually operates. The blueprint should evolve as that evidence accumulates rather than remaining frozen around the assumptions of the first pilot.

The network matters more than the showcase plant

The smart factory is often presented as a destination: one highly automated site that demonstrates what the future could look like. For a global manufacturer, however, the competitive advantage does not come from operating one exceptional plant. It comes from raising performance across a network without pretending the network is uniform.

The question is not how faithfully a second factory resembles the pilot, but whether it can use the same foundations to improve on its own terms. A smart factory cannot be cloned because its intelligence is bound to local operating reality. Scaling works when the blueprint travels and the factory remains itself.