Organizational interoperability is less about a specific technology and more about how different groups use shared information to run a process end to end. An example in a regulated manufacturing environment is an engineering change that touches PLM, MES, and QMS, but is executed coherently across organizations.
Example: Engineering change flowing across PLM, Manufacturing, and Quality
Consider a design change to a safety-critical component:
- Design authority (Engineering / PLM)
- Engineering raises an Engineering Change Order (ECO) in PLM and updates the CAD, BOM, and approved materials list.
- The ECO includes structured impact analysis fields for manufacturing operations, quality, and supply chain.
- Traceability requirements (what must be recorded in MES and QMS) are explicitly defined as part of the ECO package.
- Manufacturing operations (MES / production planning)
- Manufacturing engineering receives an automated notification and a task in a shared workflow, not just an email.
- They update routings, work instructions, and tooling in MES using the ECO as the single reference, with version links back to PLM.
- They define an effective date or serial/batch cut-in, aligned with material availability and downtime constraints.
- Production planning adjusts schedules to phase in the new configuration while minimizing disruption to existing orders.
- Quality management (QMS / inspection / validation)
- Quality reviews the ECO and updates control plans, inspection plans, and test methods in QMS, again referencing the same change record.
- Any required re-validation, first article inspection, or process capability study is created as linked QMS actions.
- Quality defines what evidence must be captured in MES and LIMS and how it will be retrieved for audits.
- Integrated execution on the shop floor
- Operators see only the correct, effective work instructions in MES, with a clear revision and ECO reference.
- Nonconformances related to the change automatically reference the relevant ECO in QMS.
- Build history (genealogy) reflects which configuration and instructions were used for each unit or batch.
- Cross-functional governance
- A formal change control board (engineering, operations, quality, supply chain, IT) approves the change using shared criteria.
- Metrics like time to implement, number of deviations, and audit findings are reviewed at a cross-functional forum, not in silos.
This is organizational interoperability because multiple departments, and often external suppliers, are working from a common change object, with defined roles, handoffs, and decision rights. The systems (PLM, MES, QMS, ERP) do not need to be from the same vendor, but the organizations agree on how to use them together.
What makes this interoperable at the organizational level
- Shared process: A documented, cross-functional engineering change process that spans PLM, MES, QMS, and ERP.
- Clear ownership: Defined roles for who initiates, who assesses impact, who approves, and who verifies implementation.
- Common identifiers: Consistent ECO numbers, part numbers, and revision IDs used across systems and departments.
- Traceability: Ability to follow the change from design decision through manufacturing records and quality evidence.
- Change control: Controlled introduction of the change, respecting validation, qualification, and downtime constraints.
Brownfield and regulated environment realities
In most plants, PLM, MES, QMS, and ERP are from different vendors and generations, and some steps are still handled with spreadsheets or email. Organizational interoperability in this context usually means:
- Agreeing on a unified cross-functional change process that can be executed with existing tools.
- Implementing minimal but reliable integrations or structured handoffs (for example, exports and controlled imports) instead of attempting a full system replacement.
- Maintaining a single source of truth for key identifiers and status, with governance over who can change what.
- Validating any integration or process change that affects regulated records, and documenting that validation.
Attempts to achieve organizational interoperability purely by replacing all systems with a single suite often fail in regulated, long-lifecycle environments because:
- The qualification and validation burden for a wholesale change is high.
- The required downtime to cut over is often unacceptable for critical production lines.
- Legacy equipment, custom integrations, and historical data are difficult and risky to migrate.
- Traceability and auditability can be compromised if historical records are not handled carefully.
As a result, practical organizational interoperability focuses on aligning processes, governance, and identifiers across existing systems, rather than expecting technology consolidation alone to solve the problem.
