A nine-stage IT/OT build order starts with an owned device inventory, uses a buffer between plant and office zones, and permits only site-specific flows [S2].
The model covers controllers, operator PCs, scanners, vehicles, PLCs, SCADA, DCS, MES/MOM, CMMS, ERP, data platforms, and cloud services across plants, warehouses, and offices [S2][S4].
Define Convergence by Operational Boundary
IT/OT convergence links operational assets such as PLCs, SCADA, DCS, sensors, and machines with ERP, MES/MOM, CMMS, CRM, data platforms, and cloud systems [S4]. A workable plant program is not a single network project. It is a written operating model covering the shared goal, decision rights, first site, and approved change windows [S2].
IT systems generally manage enterprise applications and information services, whereas operations retain responsibility for assets capable of stopping a line [S2]. This distinction makes convergence manageable without assigning one team unilateral control.
One workable division is for IT to operate the office network and buffer zone, operations to own the production zone, and both functions to approve changes that cross the boundary [S2]. A plant running three shifts cannot follow the same maintenance window as a warehouse with a quiet afternoon [S2].
Compare Four Organization Models
Four common OT structures, embedded within IT, each expose different weaknesses in spending control, scalability, and operational ownership [S1]. The practical comparison is therefore about decision rights and technical scope, not whether OT should sit inside IT or report to manufacturing.
The selection question is simple: which model lets the plant keep control, while the enterprise can reuse equipment, configuration, and data improvements across sites [S1]? A site-specific OT function may work for one plant, but it tends to fragment projects, reduce visibility, and prevent successful practices from scaling [S1].
Build in Nine Ordered Stages
The prescribed build order contains nine stages: devices, zones, flows, suppliers, old machines, warehouse wireless, monitoring, roles, and site review [S2]. Each stage depends on the asset and flow record created before it, which prevents network expansion from becoming an undocumented exception.
Step one requires every production and warehouse device to be listed, including controllers, operator PCs, engineering laptops, handheld scanners, vehicle terminals, and dock devices [S2]. Step two assigns each device to a zone, while a buffer separates plant infrastructure from the office network [S2]. Step three allows only the flows required by each zone, rather than granting broad connectivity by default [S2].
Steps four through nine address external access, legacy equipment, wireless coverage, observability, accountability, and rollout control. Suppliers receive one controlled route, unpatched machines are shielded, warehouse wireless must suit aisles and docks, plant traffic is monitored with both teams alerted, and each site is reviewed before the next joins [S2]. The sequence is slow by design because each stage creates the evidence needed by the next one.
Assign Roles Through Workflows and Skills
Before changing the organization chart, identify the current personas and responsibilities, assess how the team spends its time, define critical workflows, complete a skills matrix and gap analysis, tailor the structure, and map processes to roles [S1]. That six-step sequence matters because technical convergence increases responsibility faster than it increases headcount.
Achieving OT/IT convergence requires bridging the cultural divide between engineering and IT teams [S3].
Shared performance measures should include OEE, downtime, throughput, quality, energy intensity, safety, and OTIF [S4]. These measures put reliability and commercial performance in the same operating review, while the operating plan remains clear enough to avoid turning every convergence project into a low-latency cloud deployment.
Fit the Model to Plant Scale and Risk
A three-shift plant needs a different rollout model from a low-volume facility with a single planned outage window [S2]. Start with a bounded use case, such as transmitting one line's output counts to the planning system without manual entry, then expand only after IT and operations demonstrate that the workflow works [S2].
The approach is not suitable for plants that expect direct office-network access to every controller or require real-time enterprise commands inside safety-critical control loops. It is also unsuitable where device ownership, local regulatory constraints, or change authority remain undefined [S2][S5]. Those gaps should be closed before network changes, not transferred into IT/OT disputes after an incident.
IT organization maturity is also uneven. OT capabilities include simulation, emulation, machine vision, industrial data operations, human-machine interfaces, connected machines, automated mobile robots, and automated storage and retrieval systems, and many were not viable categories five years earlier [S1]. A mature IT structure does not automatically supply OT domain knowledge for all of those systems.
Standardize Data Without Flattening Control
A converged architecture needs common asset hierarchies, event taxonomies, data-quality rules, and production-event definitions so that data remains usable across ERP, MES/MOM, CMMS, analytics, and cloud destinations [S4]. The process starts by cataloging OT and IT systems, formats, interfaces, gaps, and redundancies, followed by a shared data model and common communication protocols such as OPC UA or MQTT [S3].
Data normalization belongs inside the operating model, not only in the data platform. Common models connect PLC, SCADA, and historian information with MES/MOM, CMMS/EAM, and ERP workflows; edge gateways can handle onboarding and normalization where direct access is inappropriate [S4]. Compute placement also differs by function: low-latency control, vision, and condition monitoring may remain at the edge, while enterprise analytics can use centralized platforms [S4].
Governance needs four integrated components: identity and access management, data governance, change management, and security controls [S5]. Administrative access should use multi-factor authentication, session monitoring, role-based least privilege, network segmentation, encryption, and attributable audit trails [S5]. Plant availability rules and legacy-system limitations must shape those controls rather than forcing an enterprise IT policy unchanged onto continuous operations [S5].
Make Governance Operate at Plant Speed
A common governance model defines policies, processes, and technical controls for automation aligned with safety, security, data integrity, and business objectives [S5]. The framework cited for connected plants uses ISO 27001, NIST 800-82, and applicable local regulatory requirements for auditability [S5].
Three documents turn the structure into an operating control: an asset-and-zone register, a change matrix, and an incident RACI. The register records each device, owner, zone, permitted flows, and criticality [S2]. The matrix identifies who can approve control logic, network configuration, software, and boundary changes [S5]. The RACI assigns approval, response, and incident leadership without leaving the plant head, OT lead, or IT lead to infer their role during an event [S2].
The first implementation gate should therefore be organizational, not technical. Verify that one site, one use case, one owner per device, one buffer zone, one controlled supplier route, and one review before expansion are all defined [S2]. A structured approach to plant security framework selection can then align the governance baseline with the operating model.
The next trackable signal is not another network connection. It is the first site that can produce production data for the planning system without manual entry, while retaining a named incident owner, an approved change record, and a successful manual fallback [S2].