Congratulations! Your Plant Has Been Selected for Digital Transformation.


“Surprise! We’ve selected you for a digital transformation.” 🎉 Possibly the least exciting surprise party ever... especially when you’re the plant manager finding out about it through a calendar invitation. 🤣

Another site ran a successful pilot, corporate loved the results, and now it’s your turn. The kickoff is Thursday. Your team wasn’t involved in choosing the problem, nobody has asked how your operators work, and the implementation schedule overlaps with your busiest production month. But don’t worry... there WILL be training! (Apparently, everything else gets resolved in that webinar.)

The enthusiasm behind these rollouts is understandable. Rockwell Automation’s 2026 State of Smart Manufacturing report found that 59% of manufacturers surveyed are actively using smart manufacturing technologies to support operations. These investments are becoming part of how plants run, with expectations for better quality, productivity, and performance. When one site demonstrates results, leaders naturally want to extend those benefits across the business. “How quickly can we get this everywhere?” is a reasonable question. Answering it well requires understanding what made the first implementation successful, which conditions exist at the next plant, and what work remains before the results can travel with the technology.

The Pilot’s Most Valuable Features May Never Appear in the Software

The original pilot may have benefited from months of collaboration with the people using it. Operators explained which alerts mattered and which would become background noise. Maintenance helped distinguish an equipment problem from normal operating behavior. Supervisors worked through who should respond, what action to take, and when to escalate.

Along the way, the team developed something that rarely appears in the deployment checklist: shared understanding. People knew why the solution existed because they had helped define the problem. They understood its limitations because they had encountered them. They had reasons to trust it because they had watched their feedback improve it. There may also have been a dedicated engineer, an enthusiastic plant manager, carefully prepared data, and a vendor answering the phone immediately whenever something broke. Those conditions contributed to the outcome, too. Before projecting the same benefits across a network of plants, someone needs to understand which of those conditions must be recreated and what that will cost.

Instead, the next site can end up receiving the software, the dashboard, and the performance target... with considerably less of the collaboration and support. The people at the pilot site helped shape the solution. The people at the next site are being asked to accept it. That difference affects how quickly they learn, whether they raise concerns, and how much effort they put into making it work when production gets difficult. Local differences add another layer. Plants can share a company logo while having different equipment, product mixes, maintenance practices, staffing levels, and operating constraints. An alert that gives one team enough time to intervene may reach another team when nobody is available to respond. A recommendation that works well during a long production run may be much less useful in a plant constantly changing products.

AI adds its own questions. Does the model perform well on this site’s data? Do its recommendations reflect local operating conditions? Who decides what to do when experienced operators disagree with its output? Those questions deserve attention before the team is expected to depend on it.

When people raise these issues, calling them “resistant to change” is a remarkably efficient way to lose useful information. They may be explaining exactly what will prevent the rollout from delivering its promised results. “Corporate has already committed to the savings” probably won’t resolve their concerns. 😬

Give the Next Plant a Role in Its Own Transformation

Scaling successfully requires a repeatable approach that leaves room for local reality. The goal is to carry forward what has been learned while giving each site the involvement, capability, and support needed to turn that learning into results.

A few practical changes can make a substantial difference:

  • Bring the next site in while the pilot is still learning. Let its operators, maintenance teams, and supervisors challenge assumptions before the design is considered finished. Early involvement helps uncover differences while there is still time to address them.

  • Validate the local business case. Establish the plant’s baseline, identify the loss or constraint being addressed, and agree on what improvement would be valuable. Solving the biggest problem at one site does not guarantee the same opportunity exists elsewhere.

  • Define what stays consistent and what can adapt. Common architecture, data definitions, and cybersecurity requirements support scale. Workflows, escalation paths, and implementation timing may need local adjustment. Make those boundaries clear so every difference doesn’t become a debate.

  • Give ownership time and authority. A local owner needs decision-making authority, access to technical support, and protected time to work with the team. Adding “transformation champion” to someone’s existing responsibilities does not create additional hours in their week. (I have checked.)

  • Measure what happens after training. Watch how the solution performs across shifts. Can people use it confidently? Are recommendations actionable? Are recurring problems getting resolved? Track adoption and operating results, and use what you learn to improve the next deployment.

A recent example shows why workforce capability belongs in the results. In its June 2026 Global Lighthouse announcement, the World Economic Forum recognized Rockwell Automation’s Singapore plant, which reported a 67% reduction in time-to-competency alongside its deployment of digital and AI solutions. That puts a measurable outcome around how quickly people become effective in their work, extending the conversation beyond whether the technology has been installed. That is a useful question for every rollout: how will we help this team become confident and effective with the new way of working? Answering it requires more than scheduling training. It requires involving people in decisions, making the benefits relevant to their work, and staying engaged as they encounter real production conditions.

You can reuse technology, architecture, and lessons learned. You still have to earn participation and create the conditions for success at the next site. Otherwise, the pilot will continue working perfectly at every plant you haven’t tried it in... and the plant manager will continue wondering who planned this party and why they’re the one cleaning up.


References:

Next
Next

IT/OT Convergence Is Not One Thing