Why IT/OT convergence fails — and how to fix it

Before deploying private 5G for industry 4.0, consider how IT and OT can work together within your business

When smart manufacturing initiatives stall, usually it’s not because the technology is ineffective. It’s because many organizations aren’t structured to support the operating model required to support emerging technologies. Welcome to the gap between information technology and operational technology, or IT and OT.  

It’s important to think deeply about IT vs. OT. These teams often have different timescales, risk tolerances, budget structures, and definitions of success. 5G is the first wireless technology that closely aligns with factory-floor requirements: deterministic latency, network slicing, SIM-based identity, and mobile edge computing. However, deploying 5G without addressing underlying IT/OT misalignment typically results in an expensive connectivity program that does not deliver expected outcomes.  

It’s important to consider how IT/OT convergence initiatives often fall short across four dimensions: organizational structure, network architecture, cybersecurity, and operational expectations. Then we can look at field-tested approaches for plant engineers and operations leaders. 

The IT/OT convergence imperative centers on a reimagined factory floor 

 Since the onset of industrial automation, the factory floor and the corporate network have existed in carefully maintained separation. OT systems — the PLCs, SCADA platforms, DCS controllers, and proprietary machine protocols that run production — were designed to be deterministic, isolated, and stable. They did not need to talk to anything outside their own closed loop. The corporate IT network carried email, ERP data, and business intelligence. The two worlds occasionally exchanged data through manual exports and middleware that nobody fully understood. That arrangement worked because the demands placed on manufacturing data were modest. 

If you are being asked to deliver real-time overall equipment effectiveness (OEE), predictive maintenance, faster changeovers, or tighter traceability, you should plan for live, bidirectional connectivity between production systems, people ,and the platforms that analyze and act on their data. Periodic exports and manual floor walks will not scale to these requirements. Treat connectivity as production infrastructure, and design it with the same rigor as any other critical utility built on the shop floor. 

This is the IT/OT convergence imperative. It is not a technology trend. It is an operational necessity driven by competitive pressure, customer expectations for traceability and customization, regulatory requirements for data integrity, and the simple arithmetic of downtime costs. A mid-size assembly plant losing $20,000+ per hour of unplanned downtime — a conservative industry estimate — cannot afford to discover equipment failures reactively when the tools to predict them exist and are within reach. 

Data expectations have expanded 

Quality, yield, energy consumption, throughput, asset health — executives have stopped accepting lagging monthly reports and started demanding real-time visibility. That means pulling live data off machines that were never designed to share it, routing it through networks that were never designed to carry it, and displaying it in dashboards that live in the cloud or on edge servers.  

The moment you connect a production line to anything outside its own closed loop, the network becomes part of the production system. Not adjacent to it — part of it. A network failure is no longer an inconvenience. It is a production event. 

The control loop has moved

In traditional automation, the intelligence lived at the machine. The PLC made decisions locally. The network carried status updates after the fact. In modern industrial AI — predictive maintenance models, vision-based quality inspection, autonomous mobile robots, digital twin synchronization — the intelligence increasingly lives off-device, in an edge server or a cloud platform. The network is now inside the control loop. A packet that arrives late or doesn't arrive at all doesn't just affect a dashboard. It affects whether a robot arm moves correctly. Whether a safety interlock fires. Whether a batch gets scrapped. 

Latency and reliability have become engineering tolerances, not IT service levels. 

Key insight: The convergence imperative is not about connecting more devices. It is about moving intelligence closer to the physical process — and that requires a network that can carry time-critical information without compromise.

How convergence fails: The four failure modes, in order of frequency 

IT/OT convergence projects fail in predictable ways. Understanding the failure modes before you start is more valuable than any technology selection decision. In the authors' experience, and consistent with published research on industrial digital transformation, the following four patterns account for the overwhelming majority of convergence projects that stall, underdeliver, or quietly collapse after launch. 

Failure mode 1: Nobody owns it

The most common convergence failure has nothing to do with technology. It is an accountability vacuum. OT lives in engineering and operations such as capital expenditure decisions, asset lifecycle planning, uptime above everything. IT lives in the corporate cost center — operational expenditure, patch cycles, vendor contracts, and security compliance. When a 5G convergence project lands in neither budget and neither team has unambiguous accountability for outcomes, it drifts. 

The pattern is consistent: a cross-functional working group is formed, a pilot is scoped, enthusiasm is high. Then the first conflict arises: 

• Who pays for the annual spectrum fees?
• Which team manages the SIM provisioning process?
• Who is on call when the 5G core goes down at 2 a.m. on a Sunday?

In the absence of a single accountable owner with both technical authority and budget authority, these questions become committee discussions that last months. 

A more effective approach is to establish a joint OT/IT steering function with an executive sponsor. Often the plant general manager or a manufacturing leader, this sponsor can make architecture decisions and resolve budget conflicts efficiently. Without clear ownership and decision rights, convergence efforts can slow due to unresolved cross-functional dependencies. 

Strategic tip: Before any technology procurement, establish a single named owner for the convergence program with explicit authority over both OT and IT decisions and a consolidated budget line. This is not a governance recommendation — it is a precondition for success. 

Failure mode 2: The patch cycle standoff

OT systems are designed around uptime. A PLC running a production line often cannot be taken offline for a security patch on short notice when IT receives a critical notification about a vulnerability or exposure. The available maintenance window may be the next scheduled shutdown, which can be months away. 

Operating under cybersecurity policies that require patching within defined timelines, IT may view this as an unacceptable security posture. Operating under production targets where unplanned downtime carries significant operational impact, OT may view the IT position as impractical. 

Both positions are correct within their own operational logic. The problem is that IT/OT convergence puts them in the same room for the first time, and organizations that have not resolved this conflict before go-live discover it as a crisis — usually when a significant vulnerability is disclosed and the CISO is demanding immediate action on systems that cannot be touched without a plant shutdown. 

Often the failure mode is invisible. The project launches successfully. Six months later, the OT team has quietly stopped applying updates to converged systems because the process is too disruptive. The network configuration drifts out of vendor support. The security team raises a finding. The plant manager learns that the “secure” converged network they invested in is running on unsupported software with unpatched critical vulnerabilities. Nobody planned for this, and no one is surprised in retrospect. 

Strategic tip: Architect the network so OT systems and the 5G infrastructure layer can be patched independently. Schedule radio and core network updates on an IT cadence, and align OT endpoint patching with the plant maintenance calendar. Where available, use 5G core high availability and RAN redundancy to apply updates without service interruption. 

Failure mode 3: The network as an afterthought 

Many smart manufacturing projects treat connectivity as something to be worked out after the use cases are selected, the software platform is chosen, and the vendor contracts are signed. The network is viewed as plumbing — a commodity that can be specified at the end and installed quickly. This is a category error that produces expensive consequences. 

In a converged IT/OT environment, the network is the foundation that determines whether every other component works as specified. A quality inspection AI that requires less than 20ms consistent round-trip latency to the edge compute node will not function correctly on a Wi-Fi network delivering 35ms average latency with periodic spikes to 150ms. A predictive maintenance model that ingests 500 sensor readings per second will not deliver its designed value on a network that drops 3% of packets during peak production. These are not corner cases; these are the normal operating conditions of a busy factory floor on a network that was not designed for its load. 

By the time latency problems surface in production — manifesting as false positives in the inspection system, as gaps in the sensor data stream, as intermittent robot navigation failures — the cost of rearchitecting the network layer is enormous.  

Here’s the ideal sequence: 

• First, define the network performance requirements based on use cases
• Second, select the network technology
• Third, build the application layer on top of a foundation that can actually support it

Strategic tip: Conduct an RF site survey and an OT asset inventory before any technology selection. Define latency, reliability, and throughput requirements per use case as engineering specifications, not IT service levels. Treat the network as infrastructure — part of the capital planning process. 

Failure mode 4: Security as a checkbox  

The fourth failure mode is treating OT security as a compliance exercise rather than an operational risk discipline. This manifests in two ways. The first is the organization that has never seriously assessed its OT security posture because its systems were air-gapped and therefore presumed safe. When convergence removes the air gap, these organizations discover that their OT systems are running decades-old firmware with known vulnerabilities, have no logging or monitoring capability, and authenticate devices by MAC address — a mechanism that any competent attacker can spoof in minutes. The security debt that was invisible when the systems were isolated becomes acutely visible and expensive when they are connected. 

The second manifestation is the organization that conducts a thorough security assessment, documents the findings, and then proceeds with the convergence project without resolving them. Resolution would require taking production systems offline, replacing equipment that is still functionally effective, and spending capital that was not in the original budget. The security findings sit in a risk register. The converged network goes live with known vulnerabilities. The risk is accepted without a full understanding of what accepting it actually means in a 5G-connected environment. 

Both patterns share a common root: Security is being managed as a documentation exercise rather than as an engineering discipline. In a converged IT/OT environment, a security failure is not a data breach. It is a production outage, an equipment failure, a safety incident, or all three simultaneously. 

Strategic tip: Treat OT security as a design constraint, not a compliance layer. Network slicing, zero trust device authentication, and immutable audit logging are architectural requirements that must be designed from the start. Engage a security architect with specific OT experience before the network design is finalized. 

The IT/OT fault line: Organizational and structural root causes 

The four failure modes described in Section 2 share a common structural origin. IT and OT are not simply two teams with different technical specializations. They are two organizational cultures with different value systems, risk frameworks, time horizons, and relationships to the physical world. Recognizing this fault line as a structural incompatibility is the first step toward building an organization capable of delivering on the promise of IT/OT convergence. 

Bridging the fault line 

The goal of IT/OT convergence is not to eliminate the difference between these two cultures — the differences exist for good reasons and reflect the genuine requirements of their respective domains. The goal is to build organizational structures and technical architectures that allow them to coexist on shared infrastructure without compromising either set of requirements. 

 In practice, this means three things. First, governance structures that give both OT and IT decision authority within their respective domains, with a shared escalation path for conflicts. Second, technical architectures — specifically network architectures — that enforce the separation of OT and IT traffic at the infrastructure level rather than relying on policy alone. And third, a shared language for discussing tradeoffs. OT and IT need to be able to talk about latency, reliability, patch cycles, and security posture in terms that both communities understand and accept as legitimate. 

Strategic tip: The most valuable person in a convergence program is not the 5G architect or the OT systems engineer. It is the rare individual who speaks both languages fluently, has credibility in both communities, and can translate the legitimate concerns of each team into terms the other can act on. Finding or developing that person is worth more than any technology selection. 

Why private 5G changes the architecture: The specific capabilities that matter for industrial OT 

Legacy wireless technologies were not wrong; they were correctly designed for the requirements that existed when they were built. Wi-Fi was designed for best-effort data delivery in office environments. LTE was designed for wide-area mobile voice and data. Neither was designed for a factory floor where tightly controlled latency is a production requirement; where thousands of devices move continuously through complex RF environments; and where the same physical infrastructure must simultaneously support safety-critical machine control, high-throughput video inspection, and general IT connectivity with completely different performance guarantees. 

On the other hand, 5G was designed for requirements of industry 4.0. The 5G capabilities that matter for industrial environments are the ones that address specific OT requirements that no previous wireless standard could meet. 

Ultra-Reliable Low Latency Communication (URLLC) 

URLLC delivers sub-10ms end-to-end latency with reliability targets of 99.999% — five nines. For context: Wi-Fi in a typical factory environment delivers 5-50ms average latency with significant variance. LTE delivers 30-70ms. The difference between 10ms and 50ms is not a performance improvement for factory applications. It is the difference between a wireless network that can participate in a closed-loop control system and one that cannot. 

A servo motor receiving positioning commands over a wireless link needs that link to behave as predictably as the wired connection it replaces. Variance in worst-case latency is what breaks precision control loops. URLLC's reliability guarantee means worst-case performance is bounded. That boundedness is what opens the door to wireless machine control, wireless safety systems, and wireless robot coordination at the performance levels that OT applications demand. 

Network segmentation 

Network segmentation allows a single physical 5G infrastructure to be partitioned into multiple logically isolated segments, each with intent-based quality of service parameters — enforced at the network core level, not just at the access layer. Each segment can be mapped to corresponding VLANs that carry the traffic to the application platforms.  

This capability directly addresses the IT/OT convergence problem. A separate OT segment carries machine control traffic with hard latency guarantees and zero connectivity to external systems. A separate analytics segment carries IoT sensor data to the edge compute platform. A separate IT segment carries corporate connectivity for general business use. A safety segment, physically isolated, carries emergency stop signals and interlock systems. These segments are logically invisible to each other; an attacker who compromises the IT segment cannot reach the OT segment, because the separation is enforced at the network core, not by a firewall that might be misconfigured. 

In practice, this means the decision to deploy 5G is not a choice between OT performance and IT flexibility. It is the first technology that can deliver both simultaneously, on the same infrastructure, without compromise. 

Massive MIMO and dense coverage 

Factory floors are the worst possible RF environment. Steel structures create multipath reflections that confuse standard antenna systems. Welding arcs generate broadband electromagnetic interference. Large metal assemblies moving through the plant create dynamic RF shadows. Electric motors produce noise across the spectrum. These are the baseline conditions in virtually every heavy manufacturing environment. 

With 5G, massive MIMO antenna arrays use beamforming to direct radio energy precisely toward individual devices rather than broadcasting omnidirectionally. This translates to consistent, predictable signal quality in environments where Wi-Fi produces dead zones whenever the geometry changes — behind a large machine, in a stamping cell, in a welding bay. 

Mobile edge computing integration

5G's architecture natively supports compute resources placed at the base of the network itself, inside the facility, rather than routing all traffic to a remote cloud platform. Compute at the 5G network edge allows data to be terminated locally, process it, and return results without the round-trip to a cloud data center. 

For manufacturing applications, this means a quality inspection AI running at the edge can process 60 frames per second from a production camera, return a result in under 20ms, and never transmit proprietary production imagery outside the facility perimeter. A predictive maintenance model can ingest 1,000 sensor readings per second from a machine cell, run inference locally, and issue a maintenance alert in near-real time — without depending on a cloud platform whose availability is outside the plant's control. 

SIM-based device identity 

Every device on a 5G network authenticates via a SIM — a hardware-rooted cryptographic identity provisioned, managed, and revocable by the network operator. This is categorically different from Wi-Fi authentication, which is typically password-based, and from legacy OT device identification, which often relies on MAC addresses that can be spoofed trivially. 

In a private 5G network, the plant operator knows with cryptographic certainty which devices are authorized on the network. A device that is lost, stolen, compromised, or decommissioned can have its SIM revoked instantly, removing it from the network without requiring physical access. This level of device identity management is not achievable on legacy wireless infrastructure, and it is the foundation of a credible zero-trust architecture in a device-dense manufacturing environment.

Security without illusions: The honest picture of private 5G and OT cybersecurity 

The security conversation around private 5G in industrial environments suffers from two opposing misrepresentations. The first presents 5G as an unambiguous security improvement over legacy OT infrastructure. The second — common in risk-averse IT and security teams — frames connectivity itself as the threat, and air-gapping as the only credible defense. Both positions miss the honest picture, and both lead to poor decisions. 

The myth of the secure air gap 

Legacy OT environments were not secure. They were obscure. The assumption that physical isolation guarantees security has been disproven repeatedly and consequentially. The Stuxnet worm, which destroyed uranium enrichment centrifuges at the Natanz facility in 2010, propagated via USB drives into systems that were completely air-gapped from any network. The Triton malware attack on a Saudi Arabian petrochemical facility in 2017 targeted the safety instrumented systems — the last line of defense in a process plant — on equipment that was not supposed to be network-accessible. In both cases, the systems were breached not through network connectivity but through the human behaviors that surround supposedly isolated systems: vendors with laptops, maintenance personnel with USB drives, remote access tunnels that IT didn't know about. 

Most OT environments have more network exposure than their operators believe. An informal survey of industrial facilities typically reveals undocumented remote access connections established by equipment vendors, shadow IT — personal Wi-Fi hotspots or mobile devices used by operators because the official network is too slow — and legacy Ethernet segments that were connected to corporate networks years ago and never documented. The air gap, in practice, often is a policy rather than a physical reality. 

What private 5G actually does for security

A properly implemented private 5G network offers a materially better security posture than the legacy OT environments it replaces, in three specific ways. 

First, device identity. SIM-based authentication replaces the password-based and MAC-address-based identification that most OT environments rely on. Every device is known, its identity is cryptographically verified, and access can be revoked in seconds. This eliminates an entire class of attack — unauthorized device connection — that is trivially easy against legacy OT networks. 

Second, traffic isolation. Enterprises can enforce the separation of OT and IT traffic at the network core, not at a firewall that might be misconfigured or bypassed. This is a fundamentally stronger guarantee than VLAN-based segmentation, which can be exploited through a range of well-documented techniques. 

Third, visibility. A private 5G network gives the plant operator complete visibility into what devices are on the network, what they are communicating, and whether that communication is consistent with expected behavior. This visibility didn't exist in legacy air-gapped OT environments, where there was no logging, no anomaly detection, and no mechanism to detect an attacker who had already gained access. 

The real security risks 5G introduces

Let’s be realistic, though. 5G connectivity does introduce genuine new exposure in three areas. 

The management plane is the first. The radio units, the 5G core network, and vendor remote support interfaces are all new administrative systems that require their own security, patching, and access control. If a vendor's support tunnel into the 5G core is compromised, the attacker has reach into the OT network. These interfaces must be treated with the same rigor as any other critical infrastructure access: strong authentication, minimal privilege, complete audit logging, and regular security review. 

The protocol bridge is the second. Connecting legacy OT systems — running PROFINET, Modbus, Ethernet/IP — to a 5G network requires protocol translation, typically through OPC-UA gateways. These translation layers are new software components with their own attack surface. A vulnerability in an OPC-UA gateway can expose the OT systems behind it to threats from the IT network in ways that neither the OT team nor the IT team may anticipate. 

Supply chain is the third. Private 5G infrastructure is sourced from a small number of vendors. The U.S. government's restrictions on equipment from certain countries in critical infrastructure reflect a genuine concern about supply chain integrity — backdoors, vulnerabilities, and foreign government access to network management interfaces. Organizations deploying private 5G in manufacturing facilities that handle sensitive production data, defense contracts, or critical infrastructure functions should understand this risk explicitly and make vendor selections accordingly. 

Strategic tip: If the management plane cannot be secured, deploy private 5G with local management completely eliminating that attack vector. Physically isolate protocol bridges and establish a process for periodic security updates. If done properly, a private 5G deployment can deliver a stronger security posture than the legacy wired and wireless OT infrastructure it replaces. The operative phrase is “done properly.” 5G forces you to do security seriously for the first time. That is harder and more expensive than the status quo. It is also significantly better than the false security of an air gap that was never as solid as it appeared. 

Operational markers of a successful IT/OT convergence deployment

A successful convergence deployment shows up first in daily routines — what the shift supervisor checks, how maintenance plans work is scheduled, and what happens when a line starts to drift. If you do not see these operational behaviors changing, you do not yet have a working converged system. 

The shift supervisor's morning 

In a facility where convergence has genuinely worked, the shift supervisor starts the day with situational awareness that was previously impossible or prohibitively expensive to obtain. Instead of walking the floor to find out what happened on the previous shift, they look at a real-time dashboard showing where each line stands, what equipment has been flagged for attention, what the quality rate was on the last several hundred units, and whether any of the predictive maintenance models have issued early warnings overnight. 

This does not sound revolutionary. In most manufacturing facilities today, however, this information either does not exist in real time, is 24 hours old, lives in three different systems with three different interfaces that require separate logins, or can only be obtained by asking someone who was on the previous shift and may or may not have noticed. The shift supervisor who has genuine real-time situational awareness makes better decisions faster, and with more confidence. 

The maintenance call that didn't happen

In a successfully converged facility, the most telling indicator is a production stoppage that didn't occur. A bearing on a critical conveyor shows an anomalous vibration signature in the sensor data. The predictive maintenance model, running at the edge, flags it three days before the bearing would have failed catastrophically. A maintenance work order is generated automatically. The part is ordered. The repair is scheduled for the next planned downtime window. The bearing is replaced. Production continues without interruption. 

This is not a hypothetical. The difference between these outcomes and “we have IoT sensors” is whether the network can get the data to the model fast enough, reliably enough, and with sufficient fidelity to actually act on it before the failure occurs. 

The quality escape that was caught

In a converged facility with vision-based quality inspection running at the edge, a dimensional defect introduced by a worn tool is detected at the point of production rather than at final inspection or, worse, at the customer. The inspection AI flags a trend — not just a single defect, but a statistical drift in a critical dimension over the last 200 units — and generates an alert. The process engineer investigates, identifies the worn tool, replaces it, and clears the affected units for re-inspection. The customer never sees the defect. The cost of the quality escape — warranty claims, field service, reputational damage — is avoided entirely. 

In a facility without this capability, the alternative is that the drift continues undetected until it crosses a hard tolerance limit, triggering a batch scrap event or, in the worst case, until defective product has reached the customer. The cost difference between detection at point of production and detection in the field is typically measured in orders of magnitude.

Roadmap: A phased approach for plant engineers and operations leaders

The path from the current state to a functioning, converged IT/OT environment is not a single project. It is a multi-year program that proceeds in phases, with each phase building on the last and validating the investment before the next commitment is made. The following framework is not a procurement checklist. It is a sequence of decisions and actions that address the organizational, architectural, and technical dimensions of convergence in the order that produces the highest probability of success. 

Phase 1: Foundation (months 1-3) 

Phase 1 has one job: Eliminate guesswork. Produce two artifacts before you let the project move forward. 1) An RF site survey that maps interference sources, coverage constraints, and antenna placement requirements across the facility. 2) An OT asset inventory that lists every OT device, its protocol, firmware version, current connectivity, and operational criticality. If you cannot point to these documents, you are not ready to design (or deploy) a private 5G network. 

These are not glamorous deliverables. They are foundational. You cannot design a 5G network without knowing the RF environment. You cannot converge an OT network without knowing what is on it. Organizations that skip this phase and proceed directly to technology procurement invariably discover expensive surprises during deployment. 

• Commission RF site survey across full facility footprint
• Complete OT asset inventory with protocol, firmware, and criticality data
• Establish joint OT/IT governance structure with named program owner
• Define latency, reliability, and throughput requirements per use case as engineering specifications
• Confirm spectrum availability

Phase 2: Pilot zone (months 4-6) 

The pilot phase deploys private 5G in a single, bounded production zone — a single manufacturing cell, a specific assembly line, or a defined area of the warehouse. The purpose is not to demonstrate the technology. It is to validate the specific performance requirements defined in Phase 1, stress-test the organizational governance model, and identify the integration challenges that only surface in production conditions. 

Select the pilot zone based on two criteria: high enough operational complexity to surface real integration challenges, and low enough criticality that a deployment problem does not cascade into a production crisis. Two or three use cases is the right scope for a pilot — enough to generate meaningful data, yet not so many that failure analysis becomes impossible. 

• Deploy 1-2 5G radio units covering the pilot zone
• Implement 2-3 priority use cases; predictive maintenance, AMR connectivity, and vision inspection are the highest-ROI starting points
• Validate end-to-end latency and reliability against Phase 1 specifications under production load
• Test OT integration: Confirm that existing PLC and SCADA systems communicate correctly through the 5G layer
• Conduct first IT/OT patch cycle negotiation Establish the governance model before it becomes a crisis
• Security review: Penetration test the pilot network before expanding

Phase 3: Plant rollout (Months 7-18) 

The plant rollout phase expands the proven pilot architecture to full facility coverage. The technology decisions are largely settled by this point; the unknown variables are operational. How does coverage behave in parts of the facility not included in the pilot? Which OT systems require unexpected integration work? How does the network perform under full production load rather than pilot-zone conditions? 

 The critical discipline of this phase is resisting the temptation to expand scope. New use cases will be proposed. New stakeholders will have requirements. The answer, during the rollout phase, is to add them to a backlog and keep focus on delivering the pilot use cases at scale. Scope expansion during rollout is the most common cause of schedule delay and budget overrun in convergence programs. 

• Extend radio coverage to full facility using RF survey data
• Migrate production systems to 5G network in planned maintenance windows, not cutover events
• Configure network slicing for full use case portfolio: OT, safety, IT, analytics as separate slices
• Deploy edge compute nodes to support AI inference at scale
• Complete staff training: operators, maintenance technicians, and supervisors
• Establish 24/7 monitoring and alerting for network performance and security events

Phase 4: Continuous optimization (Month 19+) 

A successfully deployed private 5G network is not a finished product. It is a platform. New use cases become viable as the organization builds operational competence with the technology. AI models improve as they accumulate production data. Edge compute capacity can be expanded as demand grows. The network architecture evolves as standards mature and new capabilities become available in software updates. 

The organizations that extract the most long-term value from convergence investments are those that treat the network as a living infrastructure — continuously measuring its performance, proactively identifying new use cases, and systematically building the internal expertise to manage and evolve it without depending entirely on external vendors. 

• Conduct quarterly performance reviews against original KPI commitments
• Develop internal 5G expertise: Train at least two plant engineers to level of network architecture competence
• Add new use cases from backlog on a structured six-month cadence
• Review network configuration as use case portfolio evolves

The single most important decision in a convergence program is not which 5G vendor to select, which edge compute platform to deploy, or which use cases to prioritize first. It is the appointment of a program owner who has genuine authority over both OT and IT decisions, genuine accountability for the outcome, and genuine understanding of both operational domains. Everything else in this roadmap can be corrected if it goes wrong. That appointment cannot be undone, and if it is made incorrectly, the probability of convergence success drops precipitously regardless of how well everything else is executed.