There is no single universal “right” system to own all effectivity and applicability data. In most regulated, brownfield environments the responsibility is intentionally split and coordinated across PLM, ERP, and MES, with clear separation between definition, planning, and execution.
Typical ownership pattern
1. PLM: Design & configuration effectivity (source of truth)
- Owns product configuration baselines, engineering changes (ECR/ECO), and configuration rules.
- Defines which configurations, serial number ranges, model/variant, or block points an engineering change applies to.
- Holds configuration-controlled BOMs, routings/operations (if managed there), and option/variant logic.
- Acts as the primary system of record for configuration effectivity used to support certification, as-designed vs as-built traceability, and long-term product history.
Constraint: This only works if PLM is actually used for structured configuration management and is integrated into change control. Many older plants still keep part of this logic in spreadsheets or drawing notes, which increases risk and rework downstream.
2. ERP: Commercial, planning & applicability context
- Owns effectivity that impacts planning, costing, and supply chain, such as:
- Effectivity by customer contract, program, or block/lot.
- Effectivity by required date, country of destination, or export-control constraints.
- Supersession and last-time-buy windows for old configurations.
- Interprets PLM changes into planning BOMs and work orders with clear applicability (which orders, which customers, which plants).
Constraint: ERP rarely handles full configuration logic well on its own. When ERP is allowed to drift away from PLM, you get mismatched BOMs, wrong parts at the line, and poor as-built traceability.
3. MES: Execution applicability & as-built effectivity
- Applies PLM/ERP effectivity rules at the point of execution:
- Determines which revision, work instructions, inspections, or special steps apply to a specific unit, lot, or serial number.
- Enforces that operators build to the correct configuration for that order or serial number.
- Captures actual as-built configuration (what was really installed where and when).
- Owns the operational view of applicability: which process, document, or tooling version was actually used on each work order or serial.
Constraint: MES should not invent configuration rules on its own. It should consume effectivity/applicability from PLM and ERP, possibly with local execution rules. In unintegrated plants, MES ends up with copied or manually keyed effectivity data, which is fragile and hard to keep in sync.
Why one system rarely owns everything
- Different responsibilities: Design configuration, commercial/contractual applicability, and execution reality are different problem spaces. Forcing them into a single tool often breaks one of them.
- Brownfield reality: Existing PLM, ERP, MES, and QMS stacks are already qualified and entangled. Replacing them or centralizing all effectivity into one platform can trigger major revalidation, downtime, and integration risk.
- Lifecycle length: Aerospace and other regulated products run for decades. Configuration history must survive multiple system upgrades and vendor changes. A layered ownership model with clear interfaces is usually more sustainable than betting everything on one system.
Practical design principles for ownership
- 1. Single source of truth per “type” of effectivity
Decide and document where each type of effectivity lives, for example:
- Engineering configuration effectivity: PLM.
- Program/contract or customer-based applicability: ERP.
- Serial/lot-level execution applicability and as-built linkage: MES.
- 2. No business rules trapped in documents only
Applicability rules buried in PDFs, drawings, or tribal knowledge (“this only applies to tail numbers for airline X”) are hard to enforce and audit. Implement them as structured data and logic in PLM/ERP, then consume them through integration in MES.
- 3. Explicit mapping from effectivity to work execution
Ensure there is a traceable link from configuration changes in PLM, through ERP planning, into the MES work instructions and routing steps actually used. Operators should never have to guess which revision applies to a specific order or serial.
- 4. Change control owns the cross-system update
Your change control process (often driven from PLM/QMS) should explicitly include:
- Which configurations, customers, plants, and date/serial ranges are affected.
- Which systems must be updated (PLM, ERP, MES, QMS, tooling databases).
- How effectivity will be verified at execution (test orders, dry runs, inspection points).
- 5. As-built data always lives close to execution
Even if PLM is the master for as-designed configuration, the reliable record of what was actually built usually comes from MES (and sometimes specialized test or inspection systems). PLM and ERP should reference that execution data rather than reconstructing it.
How this coexists with legacy and mixed-vendor stacks
In many plants, effectivity and applicability rules are currently split between:
- PLM/legacy PDM for drawings and engineering changes.
- ERP and MRP planning rules for phase-in/phase-out and block applicability.
- Paper travelers, local databases, or tribal knowledge for shop-floor applicability.
Trying to “fix” this by replacing everything with a single platform often fails in regulated environments because of:
- Qualification and validation cost: Any system that owns configuration effectivity becomes safety- and compliance-relevant. Replacing it demands extensive validation, regression testing, and documentation.
- Downtime risk: Migrating all effectivity and applicability logic at once is rarely feasible around live programs.
- Integration complexity: ERP, PLM, MES, and QMS all consume configuration and effectivity data differently. A big-bang replacement usually uncovers edge cases late.
A more realistic approach is to clarify ownership in the existing stack, reduce duplication, then strengthen integrations so that:
- PLM publishes authoritative configuration and engineering effectivity.
- ERP translates that into planning and order-level applicability.
- MES enforces applicability at the station, work-order, and serial level and captures as-built results.
What to document internally
To make ownership unambiguous, most organizations benefit from a short, controlled document or data model that states:
- Which system is the master for each kind of effectivity/applicability (configuration, serial range, program/contract, plant-specific, date-based).
- How changes are propagated across PLM, ERP, MES, and QMS.
- How conflicts are resolved when two systems disagree.
- Where auditors should look for the authoritative record for a given part, serial number, or time period.
Without this, you may unintentionally create multiple “masters” for effectivity, which increases risk of building the wrong configuration, misaligning FAI/AS9102 records, or failing traceability checks.
