Connect981 – Content Dev

RSC Sphere: Quality, Compliance and Traceability

The Quality, Compliance and Traceability Sphere demonstrates how audit-grade credibility is built directly into execution workflows. It connects nonconformance, corrective action, inspection, traceability, and audit evidence into a continuous operational loop. The content emphasizes how quality systems must interact with live work rather than exist as parallel documentation processes. This sphere proves that compliance and execution can reinforce each other instead of competing for attention.

  • How does risk management differ between design and MRO under AS9100?

    Under AS9100, the core expectations for risk management are the same whether you are doing design or MRO: you must identify risks, evaluate them, plan actions, implement those actions, and monitor effectiveness within your quality management system. The practical implementation, however, looks very different between design and MRO because the data, levers, and time horizons are not the same.

    1. Scope of responsibility

    Design (AS9100 including design & development):

    In practice, this connects to part genealogy and traceability when teams need to turn the answer into repeatable execution habits.

    • Focuses on product safety, qualification to requirements, and lifecycle reliability.
    • Risk is tied to design decisions, configuration baselines, and changes (design changes, DER approvals, etc.).
    • Hazard analysis often spans the full life of the product, including how it will be manufactured, operated, and maintained.

    MRO (organizations with overhaul/repair scope):

    • Focuses on continuing airworthiness, maintenance error prevention, and repair/overhaul effectiveness.
    • Risk is tied to in-service conditions, prior maintenance history, deviations to OEM instructions, and findings from inspections.
    • Often constrained by Type Certificate holder data, OEM repair manuals, and regulatory approvals for repairs.

    2. Timing and nature of risk decisions

    Design:

    • Risk analysis is largely front-loaded during design and development, and then revisited at design change.
    • Common tools include FMEA, FTA, hazard analyses and safety assessments aligned with system engineering artifacts.
    • Risk controls are implemented via design choices, requirements, margins, derating, redundancy, and specified verification/validation activities.

    MRO:

    • Risk analysis is event-driven and continuous: each induction, teardown finding, AD/SB, or field event can trigger new assessments.
    • Common mechanisms include risk-based inspection scope, risk-based work scoping, and prioritization of findings (e.g., corrosion, fatigue indications).
    • Risk controls are implemented through revised work instructions, inspection points, tooling controls, human factors measures, and escalation rules for unusual damage or nonstandard repairs.

    3. Data sources and feedback loops

    Design:

    • Relies heavily on requirements, modeling, analysis, test results, and controlled design reviews.
    • In-service feedback enters more slowly: field reliability data, incident investigations, NCR trends, and change requests.
    • Feedback is typically routed through PLM, change control boards, and formal design change processes.

    MRO:

    • Relies on real-time condition data: teardown findings, inspection results, borescope images, NDT outcomes, and part history.
    • In-service issues can appear as AOG events, repetitive defects, or trend data across a fleet or component population.
    • Feedback is routed through the MRO shop control system, maintenance records, operator reports, and sometimes directly via airline/operator reliability programs.

    In brownfield environments, this often means design risks are mainly tracked in PLM/engineering tools, while MRO risks are tracked in separate MRO or ERP/MES systems. Under AS9100, you must show how those separate systems still support a coherent, traceable risk-based QMS.

    4. Risk controls and levers

    Design:

    • Change design geometry, materials, architecture, or interfaces.
    • Adjust safety factors, allowable limits, or environmental envelopes.
    • Specify manufacturing process controls and verification steps (e.g., special processes, inspection characteristics) in the technical data.
    • Define maintenance intervals and inspection requirements that will later apply in MRO.

    MRO:

    • Change how maintenance is executed: inspection methods, sequences, task cards, and routing.
    • Control who can perform specific repairs (certifications, authorizations, training) and how tools and test equipment are managed.
    • Apply or request alternative repairs or deviations (e.g., controlled concessions, engineering dispositions) and manage the risk of non-OEM repairs.
    • Adjust sampling, inspection frequency, or additional checks based on risk (e.g., repeat findings on a fleet or batch).

    5. Interaction with regulatory and design authority controls

    Design:

    • Risk management is tightly linked to certification basis, regulatory safety requirements, and design approval (e.g., design authority, DER/ODA processes).
    • Safety assessments, failure condition classifications, and development assurance levels influence how risk is controlled and documented.

    MRO:

    • MRO risk management must respect the approved design and maintenance data. Many risk decisions require coordination with the design approval holder (e.g., OEM, DOA) or regulator.
    • Risk-based deviations in MRO (e.g., blending beyond manual limits, non-standard repairs) usually demand formal engineering disposition and documentation traceable to the design authority.

    AS9100 expects that these interfaces are defined and controlled. It does not itself grant authority to alter design; it requires that any such changes and deviations be controlled and traceable.

    6. Risk-based thinking in processes and documentation

    Common AS9100 expectations across both design and MRO:

    • Risk-based planning of processes, audits, supplier controls, and changes.
    • Documented criteria for when a risk requires formal action (e.g., CAPA, engineering change, additional controls).
    • Evidence that risk controls are implemented and monitored (records in QMS, MES, PLM, or MRO systems).
    • Change control that evaluates risk before implementation and checks effectiveness after implementation.

    Design-specific emphasis:

    • Risk-based design reviews and gate criteria (entry/exit gates linked to hazard analysis maturity and verification plans).
    • Integration of risk assessments into requirements management and configuration baselines.

    MRO-specific emphasis:

    • Risk-based planning of inspection depth, test requirements, and sampling for certain part families or damage modes.
    • Risk-informed escalation paths for unusual damage, repetitive findings, or maintenance errors (e.g., immediate engineering review vs. routine MRB).

    7. System coexistence and practical constraints

    In many organizations, design, manufacturing, and MRO are supported by separate, legacy tools (PLM/ERP/MES for production, dedicated MRO or airline maintenance systems, stand-alone QMS tools). Under AS9100, this is acceptable if:

    • Risk information can be traced across systems (e.g., a field issue driving both an MRO procedure change and a design change is clearly linked).
    • Change control ensures that when design risk assessments change, downstream processes (including MRO) are updated and revalidated as needed.
    • You can show auditors a clear, end-to-end story of how risks are identified, assessed, controlled, and monitored, despite the distributed system landscape.

    Attempting a full system replacement to unify design and MRO risk management often stalls in aerospace because of validation burden, integration complexity, and the cost of requalifying long-lived equipment and workflows. Many organizations instead layer pragmatic integrations, standardized identifiers (e.g., configuration and part numbers), and cross-functional review boards to maintain traceability without wholesale rip-and-replace.

    8. Summary of key differences

    • Focus: Design is about creating a safe, compliant product; MRO is about keeping in-service products safe and compliant.
    • Timing: Design risk is planned and front-loaded; MRO risk is ongoing and event-driven.
    • Data: Design relies on models, requirements, and tests; MRO relies on condition data, history, and field events.
    • Controls: Design changes the product definition; MRO changes how maintenance and repair are performed within that definition.
    • Interfaces: Design leads with regulatory and certification interfaces; MRO operates within those constraints and must escalate when they are challenged.

    AS9100 sets the framework for risk-based thinking in both domains, but it is the underlying data, authority, and operational reality that drive the practical differences between design and MRO risk management.

  • What is AS9100 used for?

    AS9100 is used as the aerospace and defense sector’s quality management system (QMS) framework. It specifies how organizations plan, control, document, and continually improve the processes that affect product quality, safety, and reliability. It builds on ISO 9001 with added requirements specific to aviation, space, and defense.

    Primary uses of AS9100 in operations

    In industrial and manufacturing environments, AS9100 is typically used to:

    In practice, this connects to AS9100 compliance when teams need to turn the answer into repeatable execution habits.

    • Define and structure the quality management system by setting expectations for documented procedures, process ownership, metrics, and management review.
    • Control product realization from contract review through design, planning, production, inspection, and delivery, including first article inspection and configuration control.
    • Manage risk by requiring formal approaches to risk assessment, nonconformance handling, and corrective and preventive action.
    • Strengthen supplier management through requirements for supplier evaluation, flowdown of requirements, and control of externally provided processes, products, and services.
    • Ensure traceability of parts, materials, processes, and records at a level appropriate to aerospace and defense products.
    • Standardize documentation and records so that work instructions, forms, test results, and inspection data are controlled, current, and retrievable.
    • Support internal and external audits by giving a common structure and language for assessing process effectiveness across sites and suppliers.

    Where AS9100 shows up in day-to-day work

    AS9100 requirements are typically embedded into existing systems and processes rather than implemented in isolation. Examples include:

    • Quality management and QMS tools: Document control workflows, change approval, and record retention rules are aligned to AS9100 clauses.
    • Manufacturing operations: Routing approvals, in-process inspections, and production sign-offs are structured to provide the traceable evidence AS9100 expects.
    • IT and data systems: ERP, MES, PLM, and QMS integrations are configured to maintain configuration control, revision consistency, and audit trails.
    • Problem solving: Corrective action processes, root cause analysis, and effectiveness checks are designed to meet AS9100 expectations for nonconformity and CAPA management.

    Limitations and dependencies

    AS9100 is a standard, not a tool or a guarantee. Its effectiveness depends heavily on:

    • Process maturity: Weak or undocumented processes will not become robust simply by referencing AS9100. They need redesign, resourcing, and discipline.
    • System integration quality: In brownfield environments, disconnected ERP, MES, PLM, and QMS systems make it hard to achieve the traceability and configuration control AS9100 expects without additional integration or manual controls.
    • Change control: Frequent, poorly controlled system or process changes undermine the stability that AS9100 auditors look for, even if procedures exist on paper.
    • Validation and evidence: For regulated aerospace and defense work, you must be able to show objective evidence that your processes are implemented as described, not just that you have AS9100-aligned documents.

    Using AS9100 as a framework does not by itself provide certification, guarantee audit outcomes, or ensure regulatory compliance. Certification requires a separate accredited audit, and regulatory approvals depend on specific program and authority requirements.

    Coexistence with existing systems and long-lifecycle assets

    In most aerospace and defense plants, AS9100 is layered onto existing, mixed-vendor systems rather than driving wholesale replacement. Full replacement of core systems (ERP, MES, PLM, QMS) purely for AS9100 alignment often fails or stalls because of:

    • Qualification and validation burden for flight-critical or defense-related programs.
    • Downtime risk to production lines and test assets that operate on long cycles and cannot be easily stopped and requalified.
    • Integration complexity across legacy and new systems that both feed required AS9100 evidence.
    • Traceability and change control requirements that make large, rapid changes difficult to justify.

    As a result, organizations usually map AS9100 requirements onto the current landscape, closing gaps through targeted process changes, added controls, or incremental system enhancements instead of trying to rebuild everything at once.

  • Is ISO 13485 based on ISO 9001:2015 or an earlier version?

    ISO 13485:2016 is based on ISO 9001:2008, not ISO 9001:2015.

    When ISO 13485 was last revised (2016), the technical committee intentionally aligned it with the 2008 version of ISO 9001 to maintain stability for regulated medical device quality management systems and regulators. As a result:

    In practice, this connects to qms integration and evidence trails when teams need to turn the answer into repeatable execution habits.

    • ISO 13485:2016 keeps the ISO 9001:2008-style clause structure (not the Annex SL high-level structure used in ISO 9001:2015).
    • It does not fully adopt ISO 9001:2015 concepts such as organization-wide risk-based thinking in the same form, although it has extensive, more specific risk management requirements for medical devices.
    • Some terminology and clause references differ from ISO 9001:2015, which complicates direct one-to-one mappings in integrated QMS deployments.

    In brownfield environments where a site already uses ISO 9001:2015 for general operations and ISO 13485 for medical device lines or business units, this misalignment means:

    • You cannot assume a common clause structure across both standards; mappings must be explicit and documented.
    • Electronic QMS, MES, and document control systems need carefully configured workflows and metadata so records support both standards without implying full equivalence.
    • Change control and validation for shared processes (e.g., CAPA, document control, training) must show how each requirement from ISO 13485 and ISO 9001:2015 is individually addressed.

    Future revisions of ISO 13485 may move closer to ISO 9001:2015, but any such change would require careful impact assessment, revalidation of computerized systems, and updated mappings in regulated manufacturing environments.

  • Can small organizations exclude any ISO 9001 clauses from their scope?

    Small organizations cannot exclude ISO 9001:2015 clauses simply because of their size. The current standard does not permit broad clause-by-clause “exclusions” as ISO 9001:2008 did. Instead, it requires that:

    • All requirements that are applicable to the organization’s products and services are implemented, and
    • Any requirement that does not apply to the organization’s activities is treated as “not applicable” and justified in the scope of the QMS.

    What “not applicable” really means in ISO 9001:2015

    Under ISO 9001:2015, you do not remove entire clauses because you are small. You determine, based on your business model and processes, which specific requirements do not apply and why. Typical, defensible “not applicable” cases include:

    In practice, this connects to the ISO 9001 quality baseline when teams need to turn the answer into repeatable execution habits.

    • Design and development requirements if you truly perform no design and build only to fully defined customer or regulatory specifications.
    • Post-delivery activities that are not relevant if you have no warranty, servicing, or field support obligations, and no regulatory or contractual expectations in that area.
    • External provision of processes, products, and services details that do not apply if you do not outsource at all (rare in practice).

    In each case, the justification must be traceable to the nature of your products and services, not to your headcount or revenue.

    Constraints and expectations in regulated, industrial environments

    In aerospace and other regulated manufacturing contexts, the bar for claiming a requirement is “not applicable” is higher:

    • Customer contracts, regulatory requirements, and sector standards (for example, AS9100) may effectively reintroduce requirements you hoped to omit.
    • Prime contractors and OEMs often expect design, configuration control, and post-delivery controls even for small suppliers, because they need traceability and risk control across the supply chain.
    • Auditors will test your justification against what you actually do in your operations, not only what is written in procedures.

    For example, if you say design is not applicable but you regularly interpret incomplete customer drawings, choose materials, or modify configurations, an auditor may determine you are performing design or development activities and expect those requirements to be applied.

    How to approach scope and applicability as a small organization

    For a small manufacturer or MRO provider, a practical approach is:

    1. Map your real activities: Sales, contract review, purchasing, production, inspection, test, delivery, service, and change control across existing MES, ERP, and QMS tools.
    2. Compare to ISO 9001 clauses: Identify which requirements clearly apply and which might be candidates for “not applicable.” Be careful with borderline areas like design, post-delivery support, and control of externally provided processes.
    3. Check against customer and regulatory requirements: A requirement is not truly optional if contracts, flowdown clauses, or regulations demand it, even if ISO 9001 alone might allow you to treat it as not applicable.
    4. Document your justification: In your QMS scope statement and supporting documentation, clearly state any non-applicable requirements and the operational reason for each.
    5. Align with existing systems: In brownfield environments, your MES/ERP/PLM/QMS stack may already implement controls that touch a clause you hoped to omit. In practice, it can be simpler and lower risk to explicitly include such requirements than to argue they do not apply.

    Why “we are small” is not enough

    ISO 9001 is written to be scalable. A 20-person shop and a 2,000-person plant both apply the same clauses but with different levels of formality and tooling. The standard expects that:

    • You may implement simpler controls, fewer records, and leaner documentation if your processes and risks are simpler.
    • You do not discard whole requirement areas (such as risk-based thinking, competence, document control, or internal audits) because you have limited staff.

    Relying on organizational size alone as the rationale for excluding requirements is risky and unlikely to withstand an audit in defense or aerospace supply chains.

    Key takeaway

    Small organizations cannot exclude ISO 9001 clauses just because they are small. You must:

    • Apply all requirements relevant to what you actually do.
    • Justify any “not applicable” requirements in your scope based on your activities, contracts, and regulatory obligations.
    • Expect customers and auditors in regulated sectors to scrutinize these decisions closely, especially for design, outsourcing, and post-delivery controls.

  • What are the types of non-conformance?

    There is no single universal classification of non-conformance that applies to every regulated manufacturer. The exact types and definitions should be set in your QMS, procedures, and electronic systems (QMS/MES/ERP) and then validated and trained against. That said, most organizations use a consistent set of dimensions to categorize non-conformances.

    1. Product vs. system non-conformance

    Product non-conformance typically covers issues where a specific part, batch, lot, or unit does not meet a defined requirement, such as:

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    • Dimensional or functional out-of-tolerance
    • Wrong material, component, or revision used
    • Contamination, cosmetic defects, or damage
    • Labeling, traceability marks, or documentation missing for a given lot

    System or process non-conformance usually refers to failures of the management system or process rather than one specific unit:

    • Procedure not followed or unclear work instructions
    • Calibration system lapse, expired tooling, or unqualified equipment usage
    • Training gaps or personnel working without required qualification
    • Breakdown in document control, change control, or record retention

    In practice, product and system non-conformances often coexist: a product issue frequently exposes an underlying process weakness that should be addressed via CAPA.

    2. Critical, major, and minor non-conformance

    Many regulated plants use a severity scale. The exact criteria must be defined locally, but a common pattern is:

    • Critical non-conformance: Could reasonably lead to unsafe product, regulatory breach, or major customer impact if not detected (e.g., wrong material in a safety-critical component, missing required inspection on serialized aircraft parts).
    • Major non-conformance: A significant requirement is not met, but immediate safety impact is controlled (e.g., incomplete batch records, wrong revision of a non-safety drawing, repeated minor defects indicating process drift).
    • Minor non-conformance: Low risk, localized, often cosmetic or administrative (e.g., isolated labeling error with easy recovery, minor cosmetic defect within customer-accepted ranges).

    Severity levels affect required actions, approvals, documentation detail, and sometimes customer notification. In a brownfield environment, these categories often need to be mapped consistently across multiple legacy systems (QMS, MES, LIMS, ERP) to avoid conflicting severity logic.

    3. Internal vs. external non-conformance

    Another common dimension is where the issue is detected or originates:

    • Internal non-conformance: Found within your own operations (in-process checks, final inspection, in-house audits, lab testing, maintenance). These usually allow more controlled handling and rework options.
    • External non-conformance: Involves parties outside your direct control, such as:
      • Supplier non-conformance: Incoming material or components that fail specification.
      • Customer-returned non-conformance: Complaints, returns, or field failures.
      • Regulatory or third-party audit non-conformance: Observations against standards or licenses.

    External non-conformances typically trigger additional requirements such as supplier corrective action requests, customer communication, or formal CAPA, and they must be carefully linked to contracts, specifications, and regulatory submissions.

    4. Conforming vs. nonconforming material disposition types

    While not strictly “types of non-conformance,” many plants classify nonconforming material by its disposition category, because this drives risk, cost, and system configuration:

    • Use as is: Deviation/waiver is granted to accept the nonconformance without change. In regulated environments, this generally needs strong justification, risk assessment, and traceable approval.
    • Rework: Material can be brought into full conformance using an approved, validated process.
    • Repair: Material is made fit for use but may not fully meet original specifications; may require engineering justification and, in some industries, customer or regulatory approval.
    • Scrap: Material is not recoverable or not acceptable to rework/repair.
    • Return to supplier: Nonconforming items are sent back with appropriate records.

    In brownfield environments, you often have to align these disposition types across MES, ERP inventory statuses, and QMS workflows. Misalignment here is a frequent source of traceability gaps and audit findings.

    5. Process, equipment, and documentation non-conformance

    Many QMS frameworks further distinguish by the element of the system that failed:

    • Process non-conformance: Process parameter outside limits, uncontrolled change in sequence, or missing required verification. Example: heat treatment cycle not meeting specified time/temperature profile.
    • Equipment non-conformance: Equipment out of calibration, operating outside validated range, or maintained late. Example: CNC machine with overdue calibration producing unknown number of parts.
    • Documentation non-conformance: Incomplete, inaccurate, or obsolete records, drawings, procedures, or work instructions. Example: operator used a superseded work instruction revision.

    These categories are useful for trend analysis and for linking non-conformances to CAPA, maintenance, and change control records.

    6. Regulatory or standard-specific non-conformance types

    Some standards and regulators define additional or specific non-conformance categories that you may need to mirror or map in your systems. Examples include:

    • Audit findings categorized as critical/major/minor or similar wording.
    • Labeling and traceability non-conformances treated separately due to regulatory exposure.
    • Data integrity or record-keeping non-conformances called out explicitly.

    Where this is the case, your internal types usually need to be traceably mapped to the external categories for reporting and audit readiness. This mapping is a common integration challenge when you have multiple legacy QMS or point solutions still in use.

    7. How to define types in a brownfield, regulated environment

    In practice, your “types of non-conformance” should be defined and maintained through controlled documents and validated systems, not ad hoc lists. When updating or harmonizing types across plants or systems, consider:

    • Alignment with existing procedures and records: Changing types affects trending, historical metrics, and audit trails. You may need a transition plan and clear mapping.
    • System constraints: Legacy MES/QMS/ERP tools may limit field types, dropdown values, or workflows. Full replacement just to change categories is rarely justified given validation and downtime burdens.
    • Risk-based clarity: Types should support risk assessment and decision-making, not just reporting. If users cannot reliably distinguish between categories, the scheme is too complex or poorly defined.
    • Traceability: Ensure that non-conformance types can be linked to batches, serial numbers, equipment, documents, and changes. Incomplete linkage is a common failure mode in audits.

    For most sites, the practical solution is to standardize a small, well-defined set of non-conformance types across systems, then map historical and site-specific variants into that model through controlled change.

  • When is root cause analysis required under ISO 9001?

    ISO 9001 does not require a formal root cause analysis for every defect, deviation, or complaint. It requires you to determine causes when you take corrective action for nonconformities that are significant enough to warrant preventing recurrence.

    What ISO 9001 actually requires

    The core requirement is in ISO 9001:2015 clause 10.2 (Nonconformity and corrective action). When a nonconformity occurs and you decide that corrective action is necessary, you must:

    In practice, this connects to the ISO 9001 quality baseline when teams need to turn the answer into repeatable execution habits.

    • Review and analyze the nonconformity (including complaints when relevant).
    • Determine the causes of the nonconformity.
    • Determine if similar nonconformities exist, or could potentially occur.

    That determination of causes is where root cause analysis (RCA) comes in. ISO 9001 does not prescribe a specific method (5-Whys, fishbone, 8D, etc.), only that causes are understood well enough to support effective corrective action.

    When root cause analysis is required by ISO 9001

    Under ISO 9001, you are expected to perform cause analysis (and usually a formal RCA) when:

    • A corrective action is raised under your QMS procedures.
    • A nonconformity is recurring or systemic, even if individual events seem minor.
    • Customer complaints or escapes indicate a breakdown in your controls.
    • Internal or external audits identify significant nonconformities that you choose to address via corrective action.
    • Risk-based thinking flags the issue as high risk to product conformity, safety, regulatory expectations, or business continuity.

    In practice, you are required to show that, for each corrective action, you have:

    • Identified the root or contributing causes, not just the symptom.
    • Implemented actions that logically address those causes.
    • Verified the effectiveness of those actions over time.

    When root cause analysis is not strictly required

    ISO 9001 allows you to treat some issues with corrections only (fix the problem) without full corrective action. In those cases, a formal RCA is not mandated by the standard, as long as:

    • The issue is isolated and low risk.
    • There is no evidence of recurrence or systemic failure.
    • Your own procedures do not require a corrective action and RCA for that class of issue.

    Examples might include a one-off documentation error caught before release, or an operator mistake with no product impact and clear, immediate containment. However, in regulated or aerospace environments, many organizations voluntarily apply stricter triggers than ISO 9001 alone because of safety, contractual, or customer expectations.

    Internal triggers usually go beyond ISO 9001

    Most mature, regulated manufacturers define internal criteria that effectively require formal RCA in more situations than the standard minimally demands. Common triggers include:

    • Repeated nonconformances of the same defect mode or on the same asset, line, or cell.
    • Nonconformances affecting critical characteristics, safety, airworthiness, or regulatory compliance.
    • Customer returns, escapes, or formal complaints.
    • Significant COPQ (scrap, rework, warranty cost, delays).
    • Major or repeated audit findings (internal, customer, or certification).

    These criteria are usually documented in QMS procedures or CAPA / NCR work instructions. Under audit, you are measured against both the ISO 9001 requirements and your own defined process. If your procedure says a given trigger requires RCA and corrective action, failure to apply RCA in that scenario is a nonconformity even if ISO 9001 itself would have allowed a lighter response.

    Brownfield reality: systems, traceability, and evidence

    In mixed legacy environments (ERP, MES, QMS, PLM from multiple vendors), the main challenge is not the method of RCA but the evidence trail that links:

    • The nonconformance or complaint.
    • The investigation and root cause analysis.
    • The selected corrective actions and changes to processes, documentation, or equipment.
    • The verification of effectiveness over time.

    If your RCA and CAPA records sit in a separate point solution, you must ensure:

    • Clear linkage to NCRs, work orders, and relevant configuration or routing revisions.
    • Controlled, versioned changes to work instructions, travelers, and inspection plans remain traceable to the root cause and corrective action.
    • Evidence of ongoing monitoring (e.g., defect trend charts, sampling results) can be shown during audits to demonstrate effectiveness.

    Organizations that try to “rip and replace” QMS or MES to improve RCA visibility often run into major hurdles: validation burden, long equipment lifecycles, production downtime risk, and complex integrations with existing NCR, MRB, and CAPA workflows. A more realistic path is usually to:

    • Standardize RCA methods and triggers first (process), then
    • Incrementally improve system connections and evidence capture across existing tools.

    Key takeaways

    • ISO 9001 requires cause determination whenever you implement corrective action for a nonconformity.
    • It does not require formal RCA for every defect or minor issue handled by correction only.
    • Your internal procedures and risk criteria usually define stricter, practical triggers in regulated manufacturing.
    • In brownfield plants, the main risk is not lack of RCA tools, but weak linkage between RCA, NCR/CAPA records, process changes, and effectiveness evidence.

  • How can aerospace organizations move from MRB-driven firefighting to systemic prevention?

    Moving from MRB-driven firefighting to systemic prevention is less about a new tool and more about changing how you use data, govern change, and close feedback loops. In aerospace, the constraints of qualification, long lifecycles, and mixed legacy systems mean this shift has to be incremental and highly traceable.

    1. Reframe MRB as a system signal, not just a disposition step

    MRB will never disappear in aerospace. The goal is to treat every MRB event as structured input to prevention, not just a one-off decision.

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    • Standardize MRB data capture: Ensure nonconformances, dispositions, and justifications are captured in a consistent, queryable form (not only in PDFs or free text).
    • Enforce minimal required fields: e.g., defect code, operation/sequence, tool or program ID, material/lot, supplier, shift, station, inspector, and links to NCR/CAPA records.
    • Separate MRB risk decisions from analysis: Keep urgent airworthiness decisions fast, but schedule structured review of MRB patterns at daily/weekly cadence.

    2. Tighten traceability between MRB, process, and design

    Prevention requires clear digital threads from nonconformance back to the specific conditions that produced it.

    • Link MRB records to:
      • Specific work orders, operations, and revision of work instructions.
      • Tool IDs, CNC programs, fixtures, test stands, and measurement programs.
      • Material/lot, heat, and supplier batch where relevant.
    • Integrate systems minimally before replacing: Use connectors or lightweight data hubs to join QMS/MRB data with MES and ERP identifiers rather than attempting a full system swap that is unlikely to survive validation and downtime constraints.
    • Make traceability queryable: Engineers need to ask, for example, “Show all MRB events for Operation 40 on Part X for Rev C in the last 12 months.” If your current stack cannot support this, prioritize enabling these queries before chasing advanced analytics.

    3. Stabilize and govern standard work before automating prevention

    Systemic prevention depends on stable, controlled processes. If routing, settings, and instructions frequently change informally, you will only automate chaos.

    • Harden digital work instructions: Ensure work instructions, inspection plans, and torque/parameter limits live under explicit document control with revision history and formal approval.
    • Control local variation: Reduce “tribal” workarounds at cells (taped notes, unofficial parameter tweaks). If variation is needed, bring it under controlled deviation processes.
    • Apply change control rigor: Any process change implemented as a response to MRB should go through your standard change control, with explicit linkage back to the triggering nonconformances.

    4. Build a tiered problem-solving system around MRB data

    Instead of handling every MRB event the same way, introduce tiers of response that distinguish between quick fixes and systemic issues.

    • Tier 0: Containment at the cell
      • Operators and supervisors document nonconformance and immediate containment actions.
      • Use simple visual controls or checklists to ensure segregation of suspect product and documentation of impact.
    • Tier 1: Recurrent issue screening
      • Daily or shift-level quality review of MRB and NCR logs, grouped by part, operation, or defect type.
      • Basic pareto analysis and trend detection, using whatever tools your environment supports (QMS reports, BI tools, or custom queries).
    • Tier 2: Structured root cause analysis
      • For recurring or high-severity MRBs, trigger formal root cause analysis and CAPA using standard methods (5-Whys, fishbone, fault tree, etc.).
      • Require explicit linkage from MRB records to the CAPA and to any preventative actions in process, design, training, or supplier management.

    5. Prioritize high-leverage prevention targets

    Trying to “prevent everything” spreads resources too thin. Focus on a small number of recurrent, high-cost, or high-risk MRB drivers.

    • Use cost and risk weighting: Rank MRB categories by impact on scrap, rework hours, schedule slip, and customer impact (e.g., escapes, concessions).
    • Select a limited number of themes per quarter: For example, one structural nonconformance category, one cosmetic/dimension category, and one test/functional category.
    • Align engineering, manufacturing, and quality on these themes: Assign clear owners, charters, and target metrics for reduction.

    6. Close the loop with process and design changes

    Systemic prevention only happens when MRB insights reliably change how products are made and maintained.

    • From MRB to process control:
      • Update process FMEAs and control plans based on recurring MRB modes.
      • Introduce in-process checks at the operations where defects originate, not just at final inspection.
      • Standardize known-good setups, parameters, and fixtures where variation is driving MRB.
    • From MRB to design feedback:
      • Feed persistent manufacturability issues back into design reviews and drawing standards.
      • Flag tolerances and features that repeatedly drive MRB for DFM consideration on future programs or block changes.
    • From MRB to training:
      • Convert recurring human-factor MRBs into targeted training modules and certification criteria.
      • Use MRB cause codes to identify where training content or on-the-job guidance is ineffective.

    7. Layer analytics and monitoring on top of existing systems

    In brownfield aerospace environments, a full QMS/MES/ERP replacement seldom delivers quick prevention gains due to validation burden and downtime. Targeted analytics on existing data is usually faster and safer.

    • Start with basic aggregation: Use existing QMS exports or direct database access to build recurring MRB dashboards by part, cell, operation, supplier, shift, and revision.
    • Introduce early warning indicators: For example, trigger a review when MRB rate per 100 units for a given operation crosses a control limit, or when a new revision’s MRB volume spikes.
    • Use pilots, not big bangs: Apply analytics and prevention workflows to a focused product family or line first. Prove value and refine the model before expanding.

    8. Align governance, metrics, and incentives with prevention

    If leadership only rewards MRB cycle time and on-time shipment, people will optimize for fast firefighting.

    • Balance metrics: Track both response metrics (MRB throughput time, aging) and prevention metrics (reduction in MRB frequency and severity by category, number of MRB-driven process/design changes implemented).
    • Protect engineering and quality capacity: Reserve a fixed portion of engineer/ME/quality time for Tier 2 systemic work, not just MRB signoffs and urgent concessions.
    • Institutionalize learning: Hold periodic, evidence-based MRB reviews that focus on patterns, not blame. Document and share lessons across programs, especially in high-mix / low-volume contexts.

    9. Practical starting steps for a regulated, brownfield environment

    Given integration debt, validation overhead, and constrained downtime, a pragmatic approach might look like:

    1. Define a common MRB taxonomy for defect types, causes, and operations across programs, and ensure it is actually used in QMS entries.
    2. Establish regular cross-functional MRB review on a limited product family, focusing on patterns and systemic actions, not individual cases.
    3. Create basic MRB analytics from existing systems, even if initially via exports and a BI tool, to visualize paretos and trends.
    4. Pick 1–3 high-impact MRB modes and drive formal CAPA, with documented updates to work instructions, FMEAs, or design standards.
    5. Harden traceability between MRB, work orders, and revisions so that future analysis is faster and less manual.

    These steps can usually be done on top of existing QMS/MES/ERP with controlled configuration changes, avoiding risky wholesale replacements.

    Over time, the organization moves from reacting to each MRB to treating MRB as a structured feedback system that continuously hardens processes, designs, and training. The pace of firefighting slows as the number of repeated issues declines, while the remaining MRB workload becomes more about rare or novel conditions rather than chronic, preventable ones.

  • Can a small aerospace supplier realistically meet AS9100 requirements?

    Yes, a small aerospace supplier can realistically meet AS9100 requirements, but it requires deliberate scope, disciplined documentation, and leadership commitment. AS9100 does not mandate company size or specific software; it mandates a risk-based quality management system (QMS) that you can demonstrate, control, and maintain.

    What AS9100 actually expects from a small supplier

    AS9100 is an extension of ISO 9001 with added aerospace, defense, and aviation requirements. For a small shop, the core expectations are:

    In practice, this connects to AS9100 compliance when teams need to turn the answer into repeatable execution habits.

    • A defined, documented QMS that covers the work you perform (design, manufacturing, special processes, inspection, etc.).
    • Clear responsibilities and authorities, even if a few people hold multiple roles.
    • Documented, controlled processes for quoting, review of requirements, planning, production, inspection, release, and handling nonconformances.
    • Risk-based thinking around critical parts, special processes, and changes.
    • Configuration management and traceability appropriate to the products you make.
    • Evidence: records that show you follow your processes consistently.

    None of this requires being a large organization, but it does require structure and repeatability that many small suppliers do not have initially.

    Where small suppliers typically struggle

    Common pain points for smaller organizations include:

    • Documentation vs. capacity: One person is often the quality manager, document control, and internal auditor. If that person is overloaded or leaves, the system quickly erodes.
    • Informal processes: Tribal knowledge and verbal instructions conflict with the need for controlled procedures, work instructions, and records.
    • Configuration and revision control: Managing drawing revisions, router changes, and customer specifications across email, network folders, and ERP can be fragile.
    • Internal audits and management review: These are often late, rushed, or treated as a one-time pre-audit activity instead of an ongoing process.
    • Nonconformance and corrective action: NCRs might be logged, but root cause, corrective actions, and effectiveness checks are often weak or undocumented.
    • Training records: People are competent, but proof is scattered in spreadsheets, emails, or not documented at all.

    These gaps do not mean AS9100 is unrealistic. They mean you must right-size how you address them and be honest about resource limits.

    Right-sizing AS9100 for a small organization

    AS9100 allows scalability, but you have to justify how you scale. Practical approaches for small suppliers include:

    • Scope the QMS carefully: Limit the scope to the products and services you actually provide. Do not declare design responsibility if you only build to print.
    • Keep procedures lean: A 2–3 page clear procedure that people follow is better than a 30-page template no one reads. Focus on clarity and control, not volume.
    • Combine roles explicitly: It is acceptable for one person to be quality manager, document control, and internal auditor, as long as conflicts of interest are managed and competence is demonstrated.
    • Use existing tools: You can run an AS9100 system with paper, spreadsheets, and a basic ERP if you have good control and revision discipline. Dedicated software can help, but it is not a prerequisite.
    • Target high-risk areas first: Prioritize configuration management, special processes, FAI/AS9102, and nonconformance management, because these are high-impact in audits and operations.

    Coexisting with your current systems and tools

    In a brownfield environment, you will usually be layering AS9100 discipline over existing ERP, shared drives, and manual workflows, not replacing them:

    • ERP and job travelers: Use your current travelers or routers, but control the templates, revision, and linkage to the latest drawings and specs.
    • File shares and email: If drawings are on a shared drive, define naming, folder structure, and who can change what. Uncontrolled email attachments create traceability risk.
    • Paper records: Paper is acceptable if you can find it, it is legible, and there is a retention system. The audit risk is loss, misfiling, and version confusion.
    • Incremental digitization: Introducing digital travelers, electronic FAI, or NCR workflows can reduce risk, but each change must be planned, validated, and documented under change control.

    Full replacement of ERP/MES/QMS tools is rarely necessary or wise for a small supplier. The validation burden, migration risk, downtime impact, and cost often exceed the benefit unless the current systems are failing outright.

    Evidence and audit readiness

    For a small supplier, the main audit risk is not the absence of a fancy system, but the inability to show consistent evidence. You should be able to:

    • Pull a job at random and show the contract review, traveler, inspection records, special process certs, and final release decisions.
    • Trace a critical characteristic from drawing to inspection plan to recorded result.
    • Show how you handle a nonconformance from detection to disposition to corrective action.
    • Demonstrate control of external providers, including purchase order requirements, supplier performance data, and flowdown of customer and regulatory requirements.
    • Produce recent internal audit reports, management reviews, and actions taken.

    Auditors expect imperfection, especially in smaller organizations. What they do not accept is a mismatch between what your procedures say and what you actually do, or the inability to find records.

    Resourcing and sustainability considerations

    Even if initial certification is achievable, sustaining AS9100 is often the harder problem for small suppliers:

    • Single-point-of-failure risk: If one quality manager holds all knowledge, a departure or illness can destabilize the system.
    • Busy-period shortcuts: When production spikes, internal audits, training, and CAPA follow-up often slip first, creating findings at surveillance audits.
    • Change control drift: Uncontrolled process changes, tooling updates, or drawing interpretation shortcuts can erode compliance over time.

    Plan for at least minimal redundancy in QMS knowledge, distribute responsibilities, and schedule system activities (audits, reviews, calibration, training) as non-optional work, not “if we have time” tasks.

    Tradeoffs to be explicit about

    Before committing, leadership should recognize key tradeoffs:

    • Cost vs. opportunity: AS9100 brings access to more aerospace work and preferred supplier status for some customers, but there are ongoing costs in audits, maintenance, and lost flexibility.
    • Formality vs. speed: Increased formality slows ad-hoc changes and improvisation. This protects quality and traceability, but may feel restrictive to small, hands-on teams.
    • Incremental improvement vs. big-bang redesign: Trying to replace all systems at once to “get ready” for AS9100 usually fails in small, brownfield shops. Incremental tightening and digitization, with validation, is more realistic.

    Bottom line

    Yes, a small aerospace supplier can realistically meet AS9100 requirements. Success hinges less on size and more on:

    • Leadership willingness to accept the ongoing workload and discipline.
    • Honest scoping of the QMS to what you actually do.
    • Right-sized, documented processes that people follow.
    • Robust evidence trails that align with those processes.
    • Careful coexistence with existing ERP, paper, and manual systems instead of risky full replacement.

    Certification is attainable, but it is a strategic commitment to how you operate, not just a checklist to pass a one-time audit.