AS9100 Rev D does not replace configuration management as you know it, but it does raise the bar for how integrated, risk-aware, and lifecycle-focused your configuration management (CM) needs to be.
What actually changes with Rev D
Key shifts compared with earlier revisions are:
- Stronger linkage to risk-based thinking: CM is no longer just about part numbers and revisions. You are expected to consider the risks of incorrect configuration (wrong revision, mismatched hardware/software, incomplete records) when planning and controlling processes.
- Closer integration with design & development: Rev D ties CM more explicitly to design outputs, design changes, and verification/validation. Your CM needs to ensure that what is built, tested, and delivered matches the approved configuration baseline at each stage.
- Emphasis on documented information: There is more focus on controlling documented information (drawings, models, BOMs, software, work instructions) and maintaining traceability between requirements, configuration items, and changes.
- Lifecycle perspective: CM should cover the configuration across the product lifecycle (including in-service support and MRO when applicable), not just initial manufacture. This is especially relevant where repairs, retrofits, and upgrades are performed over many years.
What usually does not change
Rev D generally does not require you to abandon your existing CM tools or fundamental methods if they are already robust:
- You can usually keep your current PLM, ERP, MES, or QMS as the system of record for configuration, provided they are under adequate control and validated where required.
- Basic elements like part numbering, drawing control, change control, and revision history remain essential and recognizable.
- If you already manage baselines, effectivity, and change impact analysis, Rev D mostly asks you to make those linkages clearer and more consistently applied.
In practice, the standard changes how auditors evaluate CM discipline and integration, more than it mandates a specific CM technology or architecture.
Implications for brownfield and mixed-system environments
Most aerospace manufacturers and MRO providers operate in brownfield environments with a mix of legacy PLM/ERP/MES/QMS systems. Rev D expectations play out as follows:
- System coexistence, not rip-and-replace: Full replacement of legacy CM-related systems is rarely justified, given qualification burden, validation cost, downtime risk, and integration complexity. The more realistic path is clarifying which system is the master for each configuration artifact and tightening interfaces and procedures.
- Traceability across systems: You need a reliable way to show that what was planned (PLM/engineering) matches what was ordered (ERP), executed (MES/shop floor), and accepted (QMS/FAI/NCR records). Gaps and manual handoffs are not disqualifying by themselves, but you must demonstrate how they are controlled and checked.
- Change control consistency: Engineering changes, deviations, concessions, and software updates must be consistently reflected across all systems. Ad hoc “local” changes on the shop floor that bypass configuration baselines are a common Rev D weakness.
- Long asset lifecycles: For platforms with decades-long lifespans, you need a method to access historical configurations, superseded parts, and retrofit records without relying on fragile tribal knowledge or unstructured network drives.
Process and validation considerations
How much you need to change depends heavily on your current maturity:
- If your CM is basic or document-only: You may need clearer baselines, formal configuration item identification, effectivity control, and better traceability from requirements to configuration items to records of conformance.
- If you already use PLM/MES with CM features: The work is typically around hardening processes (role clarity, approvals, audit trails), ensuring integrations reflect changes correctly, and demonstrating that the system is validated and under change control.
- Validation and change control: Any digital tools supporting CM in regulated environments should be under formal change control, with evidence that they function as intended and that configuration data is accurate, complete, and retrievable for the required retention period.
Common failure modes under Rev D
Organizations that struggle with CM under Rev D often have:
- Unclear ownership: No single accountable owner for configuration across engineering, operations, and quality.
- Disconnected systems: Engineering releases a revision in PLM, but ERP/MES and work instructions lag or are updated inconsistently.
- Local workarounds: Shop-floor changes, tribal knowledge, or undocumented “tweaks” that are not brought back into the formal configuration and change process.
- Poor evidence: Inability to efficiently show auditors which configuration applied to a specific serial/lot at the time of manufacture, repair, or modification.
Practical next steps
To align with AS9100 Rev D without overreacting:
- Clarify your configuration baselines and what constitutes a configuration item.
- Document which system is authoritative for each type of configuration data (drawings, BOMs, software, routings, work instructions).
- Strengthen change control so that all affected systems and records are updated, with effectivity clearly documented.
- Review how you demonstrate configuration traceability for a specific unit or lot, from requirements through build records and concessions.
- Ensure supporting systems and workflows are under appropriate validation and change control, especially where digital records are your only evidence.
In summary, AS9100 Rev D tightens and modernizes expectations for configuration management, especially around integration, risk, and lifecycle traceability, but it does not mandate wholesale system replacement. Most organizations need targeted improvements in process discipline, system interfaces, and evidence, rather than a new CM paradigm.
