Configuration control and engineering change management are tightly coupled disciplines, but they address different parts of the same problem: how to define, change, and prove what you built over time.
Core relationship
Configuration control focuses on what the current approved configuration is for a product, assembly, or system at any point in time. It governs:
- Defined baselines (design, production, as-built, as-maintained)
- Approved part numbers, revisions, and BOMs
- Approved process plans, routings, and work instructions
- Traceability between requirements, design, and realized product
Engineering change management (ECM or ECN/ECR processes) governs how configurations are allowed to change. It covers:
- Initiating and documenting a change request or change notice
- Impact analysis (technical, quality, cost, schedule, regulatory)
- Formal approval, rejection, or deferral of the change
- Planning and executing implementation (effectivity, cut-in, rework or use-as-is)
- Updating affected artifacts (drawings, specs, routings, programs, inspection plans)
Put simply: configuration control defines and preserves the baseline; engineering change management is the governed path for modifying that baseline.
How they work together in practice
In a regulated industrial environment, configuration control and ECM should operate as a closed loop:
- Configuration is baselined: A product or process configuration (design and associated manufacturing data) is released and baselined in PLM/ERP/MES.
- A change is proposed: A nonconformance, field issue, cost-down idea, obsolescence, supplier change, or regulatory update triggers an engineering change request.
- Change is evaluated: Engineering, quality, operations, supply chain, and sometimes customers or authorities review the impact against the existing controlled configuration.
- Decision and effectivity: If approved, the change is assigned effectivity (serial numbers, date, lot, or configuration-specific criteria) and implementation responsibilities.
- Configuration records are updated: BOMs, routings, NC programs, work instructions, inspection plans, and reference data are revised and re-baselined. Old and new configurations must both remain traceable.
- Execution and verification: Shop floor systems, suppliers, and MRO partners execute to the new configuration; as-built and as-maintained records demonstrate that the correct configuration was actually produced or serviced.
If configuration control is the “source of truth” for what is approved, ECM is the “only legal door” through which that truth is allowed to change.
Where responsibilities typically sit
Roles often split as follows, although exact ownership varies by company and program:
- Configuration management teams define the configuration item structure, control baselines, and ensure traceable records across life cycle phases.
- Engineering creates and assesses proposed changes and owns technical validation.
- Quality assesses compliance and risk impact, and ensures EC workflows align with QMS and regulatory commitments.
- Operations and supply chain validate implementability, capacity, tooling, supplier readiness, and logistics effectivity.
- IT / systems owners maintain the PLM/ERP/MES/QMS integrations that keep configuration records and EC workflows synchronized.
The relationship is most effective when configuration management and ECM governance are aligned under a common policy, even if execution is distributed.
Dependencies and failure modes in real plants
The relationship between configuration control and ECM is only as strong as the systems and data flows connecting them. In brownfield, mixed-vendor environments, typical issues include:
- PLM "approved" but MES still old: Engineering approves an EC, but routings, digital work instructions, or NC programs in MES or machine controllers are not updated or validated in sync. The configuration record and the shop floor reality diverge.
- ERP effectivity vs. physical reality: ERP may show effectivity at a date or lot, but actual WIP, rework, and repair activities create mixed configurations that are not cleanly represented by system cut-in rules.
- Manual workarounds: Paper redlines, tribal knowledge, and email approvals bypass the formal EC workflow. Configuration records in PLM/QMS look clean, but the as-built condition is uncertain.
- Incomplete impact analysis: Changes are assessed only at drawing/BOM level, and not against test procedures, inspection plans, special processes, tooling, MRO documentation, or regulatory approvals.
- Lack of as-maintained linkage: For long-life assets, line and depot maintenance may implement changes through service bulletins or field orders that are not tightly linked back to the design configuration and original EC records.
In regulated environments, these failure modes do not just create scrap or delays; they undermine evidence of conformity, traceability, and airworthiness or safety justifications.
Why you cannot treat them as separate concerns
Some organizations treat configuration control as mainly documentation control and treat engineering change as a project management function. That separation rarely holds up for complex, regulated products. Common consequences are:
- Un-clearable audit findings: You can show an EC log or a configuration baseline, but not a seamless story linking requirement, design, EC, implementation, and as-built/as-maintained configurations.
- Version mismatches across systems: Drawing revs, ERP BOM revs, MES routing versions, and QMS-controlled work instructions drift out of alignment with each other.
- High rework and MRB load: Lack of clear effectivity and configuration visibility increases mis-builds, concessions, and use-as-is decisions.
Practically, configuration control should define what objects and relationships are under control and how they are baselined, while engineering change management should be the governed mechanism by which those controlled objects are created, revised, superseded, or retired.
System coexistence and long-lifecycle constraints
In aerospace and other long-lifecycle, regulated sectors, fully replacing PLM, ERP, MES, or QMS to “fix” configuration control and EC is rarely feasible. Reasons include:
- Qualification and validation burden for any system that touches configuration or EC records.
- Downtime risk for production and MRO if core systems are taken offline or replaced abruptly.
- Integration complexity across OEMs, Tier suppliers, MROs, and authorities with different tools and data models.
- Long asset lifecycles where historical configurations and legacy systems must remain accessible for decades.
Most plants instead incrementally strengthen the relationship between configuration control and ECM by:
- Clarifying which system is authoritative for which type of configuration data (PLM vs. ERP vs. MES vs. QMS).
- Implementing controlled, traceable integrations and handoffs between these systems.
- Reducing manual redlines and uncontrolled changes in favor of digital, workflow-driven EC processes.
- Linking as-built and as-maintained records to specific configuration baselines and EC identifiers.
Key takeaways
- Configuration control defines and protects the product and process baselines.
- Engineering change management is the formal, traceable process for changing those baselines.
- They are interdependent: effective configuration control is impossible without disciplined change management, and EC has no value if it does not reliably update controlled configurations across systems.
- In regulated, long-lifecycle environments, the relationship must be implemented across PLM, ERP, MES, and QMS with strong traceability, validation, and change control, rather than relying on a single “magic” replacement system.
