The first step is to define what operational decisions and records need to be connected, then map the current systems, data flows, ownership, and control points that support them. It is usually a mistake to start with a platform selection, IIoT program, data lake, or dashboard strategy before understanding how work is actually released, executed, inspected, recorded, changed, and traced.
In regulated industrial environments, a connected operations architecture has to respect existing MES, ERP, PLM, QMS, maintenance, inspection, and document control systems. These systems often carry validated workflows, contractual obligations, audit evidence, and years of integration debt. Full replacement is often unrealistic because of qualification burden, validation cost, downtime risk, traceability obligations, change control, and long equipment lifecycles.
Start with the operational thread
The practical starting point is an operational thread map. This should show how a product, order, asset, material lot, work instruction, inspection result, nonconformance, and approval move through the plant and across enterprise systems.
That map should answer basic questions before architecture decisions are made:
- Which system is the system of record for each critical object?
- Where is the authoritative routing, bill of materials, work instruction, revision, inspection plan, and quality record maintained?
- Where are operators, inspectors, engineers, planners, quality teams, and maintenance teams actually making decisions?
- Which records must be retained, reviewed, version-controlled, or included in audit evidence?
- Which integrations are manual today, and which manual controls are intentional because of risk or validation constraints?
Do not confuse connectivity with architecture
Connecting machines, APIs, historians, scanners, or dashboards can be useful, but it does not by itself create a reliable operations architecture. If master data is inconsistent, part revisions are unclear, inspection results are not tied to the right operation, or nonconformance workflows sit outside execution, more connectivity can simply move bad data faster.
The first architecture decision is often not technical. It is governance: deciding which systems own which data, which workflows are allowed to change records, and how changes are reviewed, validated, and released.
What should be documented first
A useful first deliverable is a current-state and target-state map covering:
- Core operational processes: planning, release, execution, inspection, material control, maintenance, nonconformance, and closure.
- Systems involved: ERP, MES, PLM, QMS, EAM or CMMS, data historians, document control, and reporting tools.
- Critical data objects: work orders, serial numbers, lots, routings, revisions, specifications, tools, gages, personnel qualifications, and quality records.
- Integration points: APIs, file transfers, middleware, manual re-entry, spreadsheets, and shop-floor devices.
- Controls: approvals, audit trails, electronic signatures where applicable, validation status, access control, and retention requirements.
This does not need to be a large architecture exercise at the beginning. It does need to be accurate enough to expose where the real constraints are.
Common failure modes
Connected operations programs often fail when they treat the plant as a clean-sheet environment. Most plants are not clean-sheet environments. They are brownfield operations with old equipment, mixed vendors, validated systems, custom integrations, and workarounds that may exist for good reasons.
Common failure modes include:
- Building dashboards without resolving data ownership or definition conflicts.
- Connecting equipment data that cannot be tied to a work order, serial number, lot, or operation.
- Replacing local workflows without accounting for validation, training, audit evidence, or customer approvals.
- Assuming ERP, MES, PLM, and QMS data models already align.
- Underestimating the cost of change control across qualified equipment and validated processes.
What comes after the first step
After the operational thread and data ownership are clear, the organization can prioritize a limited set of connected use cases. Good candidates are usually narrow, traceable, and operationally measurable, such as electronic travelers, inspection result capture, material genealogy, nonconformance routing, equipment status visibility, or controlled work instruction delivery.
The architecture should then evolve through controlled increments. In regulated operations, this normally means documented requirements, integration testing, validation where required, migration planning, user training, security review, and change control. The goal is not to connect everything at once. The goal is to connect the right records, decisions, and controls without breaking the systems the plant still depends on.