Connect981 – Content Dev

FAQ Tag: master data

  • When is a formal 8D analysis warranted in aerospace manufacturing?

    A formal 8D analysis is warranted when the problem is significant, repeatable, systemic, externally visible, or risky enough that a basic correction or routine NCR disposition will not provide adequate containment, root cause evidence, and follow-through.

    In practice, aerospace manufacturers commonly use 8D for issues such as:

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

    • repeated nonconformances on the same part family, process, tool, program, or supplier
    • customer escapes or suspect escapes, especially where product has already shipped or been installed
    • major supplier quality issues that require coordinated containment and permanent corrective action
    • failures affecting flight-critical, safety-significant, mission-critical, or highly regulated characteristics
    • process breakdowns that cross functions, such as design release, planning, inspection, production, MRB, and supplier management
    • issues with unclear root cause where interim containment is necessary while evidence is gathered
    • problems with meaningful cost, schedule, scrap, rework, concession, or delivery impact
    • findings that management, customers, or the QMS explicitly require to be handled with formal RCCA discipline

    An 8D is usually not warranted for every isolated defect. If the issue is minor, well understood, contained, and truly one-off, a standard NCR, local correction, or simpler corrective action workflow may be enough. Overusing 8D creates paperwork without improving learning, and teams start treating it as an administrative exercise rather than a problem-solving method.

    What usually makes the threshold cross into formal 8D

    The strongest signal is that the problem is not just a defective part, but evidence of a process control failure. If you need a cross-functional team, immediate containment across open inventory and work in process, validation of root cause, and checks for systemic recurrence, that is usually 8D territory.

    Common decision criteria include:

    • risk to airworthiness, mission performance, reliability, or contract deliverables
    • evidence of recurrence or trend, even if each individual event looks small
    • potential impact across lots, serial numbers, builds, or sister programs
    • need for supplier coordination or customer communication
    • need to prove effectiveness of corrective action over time
    • management review visibility and auditable evidence expectations

    The exact threshold depends on your QMS, customer requirements, part criticality, escape history, and how disciplined your NCR and CAPA processes already are. Some sites invoke 8D early for supplier escapes or repeat defects. Others reserve it for major events and use lighter RCCA methods for lower-risk issues.

    8D is not a substitute for containment, MRB, or CAPA governance

    8D is a structured problem-solving format, not a standalone quality system. In aerospace manufacturing it typically coexists with NCR, MRB, CAPA, supplier corrective action, and configuration-controlled documentation. That coexistence matters in brownfield environments, because the evidence is often spread across ERP, MES, QMS, PLM, inspection systems, and supplier portals.

    If those systems are poorly integrated, teams may struggle to assemble the full record needed for an effective 8D: affected serials, as-built history, process revisions, operator certifications, inspection results, tool status, and supplier lot genealogy. A formal 8D can still be warranted, but the quality of the analysis will depend on traceability, data readiness, and change control discipline.

    Trying to replace all legacy quality and execution systems just to support 8D usually fails in regulated aerospace settings. The qualification burden, validation effort, downtime risk, and integration complexity are often higher than expected. In most plants, the practical path is to improve decision criteria, evidence capture, and workflow handoffs across existing systems rather than force a full platform replacement.

    Practical rule of thumb

    Use a formal 8D when leadership would reasonably ask all of the following:

    • How are we containing every potentially affected unit right now?
    • What is the verified root cause, not just the symptom?
    • How do we know similar product, processes, or suppliers are not also affected?
    • What permanent action will prevent recurrence?
    • What objective evidence will show the action actually worked?

    If those questions need formal, cross-functional, documented answers, 8D is usually warranted.

    If they do not, a simpler corrective action path may be more efficient and just as appropriate.

  • How does ERP fit into AS9100-compliant quality and traceability processes?

    ERP fits into AS9100 primarily as the transactional and financial backbone that underpins quality and traceability, not as the sole system that fulfills all AS9100 requirements. In most aerospace environments, AS9100-compliant quality and traceability are delivered by a combination of ERP, MES, PLM, QMS, and controlled documents, with integration and governance being the deciding factors.

    What ERP usually owns in an AS9100 environment

    Typical AS9100-relevant responsibilities for ERP include:

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

    • Customer, contract, and order data
      Links between customers, contracts, sales orders, and the production orders that must be traceable to specific requirements and revisions.
    • Item masters and BOMs (when not fully in PLM)
      Part numbers, basic specifications, planning BOMs, and configuration rules that drive work orders and purchase orders.
    • Work orders and routing headers
      Creation and release of production orders, operation sequences, planned resources, and due dates that other systems use for execution control.
    • Purchasing and supplier records
      Approved supplier lists (sometimes shared with QMS), purchase orders, supplier performance data, and receiving transactions, all of which are inputs to supplier traceability.
    • Inventory and lot/batch tracking
      On-hand balances, location, lot/heat/batch IDs, certificates of conformance (often referenced, sometimes attached), and movement history between locations.
    • Costing and financial impact of quality events
      Standard and actual costs, scrap postings, and rework transactions that link financial consequences to quality and nonconformance data held elsewhere.

    These functions are critical to AS9100, but they do not, by themselves, deliver complete, audit-ready traceability or process evidence. They need to be combined with controlled work instructions, inspection records, nonconformance workflows, and calibration/maintenance data, which often live outside ERP.

    Where ERP usually is not sufficient for AS9100

    Most aerospace ERPs were not designed as full manufacturing execution or quality systems. Common AS9100 needs that are only partially covered by ERP include:

    • Detailed process and operation traceability
      Operator sign-offs, actual machine, tool, or fixture used, special process parameters, and inspection results at each operation are typically handled by MES, LIMS, SPC, or point solutions, not by ERP.
    • Nonconformance, MRB, and CAPA workflows
      ERP may capture scrap or rework codes, but structured NCR, MRB decisions, root cause, containment, and CAPA workflows usually sit in a QMS or specialized NCR system for AS9100 compliance.
    • Document and revision control
      AS9100 requires robust control of drawings, specifications, and work instructions. These are usually managed via PLM, DMS, or QMS. ERP typically references revision levels but does not control content, distribution, or training records.
    • FAI / AS9102 evidence
      ERP may store a flag or reference indicating that FAI is required or completed, but the ballooned drawing, characteristic-level results, and FAIR package are almost always managed outside ERP.
    • Gage management and calibration
      Tooling and gage calibration schedules and histories are generally handled in metrology or asset systems, linked only loosely to ERP item and operation data.
    • Detailed as-built genealogy
      Many ERPs can model serial and lot tracking, but part-to-part genealogy (which specific serials and lots came together in each assembly and rework event) often needs MES or a specialized genealogy solution to be audit-ready.

    Trying to force all of these into ERP alone typically results in heavy customization, validation risk, brittle integrations, and long-term upgrade constraints, especially in regulated and ITAR-constrained environments.

    How ERP supports AS9100 quality and traceability in practice

    In real AS9100-certified plants, ERP usually plays three key supporting roles:

    1. Authoritative source of core transactional data
      ERP is the system of record for items, customers, suppliers, contracts, and inventory balances. Other systems reference ERP IDs and data to maintain consistency and traceability.
    2. Linking commercial and operational traceability
      AS9100 expects you to trace from customer requirement to delivered product. ERP provides the chain from customer order and contract, through internal work orders and purchase orders, to shipment. MES, PLM, and QMS record what actually happened during production and inspection; ERP ties that to who ordered and received it.
    3. Financial and planning context for quality data
      ERP captures the cost impact of scrap, rework, and yield loss. When integrated with QMS and MES, this enables evidence-based decisions in MRB and continuous improvement, but only if mappings between systems are clean and consistently governed.

    From an AS9100 perspective, auditors typically want to see that ERP data is:

    • Accurate and consistent with what MES, PLM, and QMS show.
    • Under change control, with appropriate access, approvals, and audit trails.
    • Clearly linked to procedures, work instructions, and quality records.

    Integration patterns between ERP and execution/quality systems

    In brownfield aerospace environments, ERP almost always coexists with other systems. Common patterns are:

    • ERP + MES
      ERP creates work orders and high-level routings. MES manages operation-level execution, labor reporting, in-process inspections, special processes, and detailed as-built genealogy. Completion and scrap feed back to ERP for inventory and costing.
    • ERP + PLM / PDM
      PLM controls the engineering BOM, CAD, drawings, and change process. ERP receives a released manufacturing BOM and revision references. Traceability relies on consistent part numbers, revisions, and change notices across systems.
    • ERP + QMS
      QMS manages nonconformances, CAPA, audits, document control, and training records. ERP may provide transaction context (e.g., which lot and work order were involved), and may hold summary status flags or cost impact.
    • ERP + supplier portals / collaboration tools
      ERP is the system of record for POs, receipts, and invoices. Supplier collaboration tools handle flowdown of requirements, digital certificates, and NCR workflows, feeding status back to ERP.

    The key AS9100 issue is not which system “owns” a function, but whether:

    • Interfaces and data mappings are documented and validated.
    • There is a clear definition of the system of record for each data type.
    • Users know where to find the evidence an auditor will request.
    • Changes to integration are controlled, tested, and traceable.

    Why full replacement by ERP often fails for AS9100 needs

    Many organizations attempt to consolidate MES, QMS, and PLM capabilities into ERP to simplify the landscape. In AS9100 and long-lifecycle aerospace environments, this often fails or stalls because:

    • Qualification and validation burden
      Deep customizations or new ERP modules that affect quality records or traceability require rigorous validation, documentation, and sometimes customer or regulatory review.
    • Downtime and cutover risk
      Replacing established MES/QMS capabilities with ERP during a short outage window is high-risk, especially when customer programs cannot tolerate extended downtime.
    • Integration and change-control complexity
      ERP is typically integrated with finance, MRP, and external partners. Rewiring quality and execution inside ERP tends to create ripple effects across many interfaces and procedures.
    • Long equipment and program lifecycles
      Plants may need to maintain traceability for decades. Frequent ERP upgrades or vendor changes become problematic if critical execution and quality records are deeply embedded and heavily customized inside ERP.

    Because of these realities, many AS9100-compliant organizations pursue an approach where ERP stays focused on planning, inventory, and financials, while MES/PLM/QMS handle detailed execution, documentation, and quality. The integration is then incrementally strengthened and validated rather than rebuilt in one step.

    What to document for AS9100 using ERP data

    To use ERP effectively in your AS9100 evidence set, it helps to explicitly document:

    • Which AS9100 clauses are supported by ERP data, and which are supported by other systems.
    • The defined system of record for part numbers, BOMs, routings, suppliers, and quality records.
    • How work orders and purchase orders created in ERP link to FAI, inspection, and NCR data elsewhere.
    • How changes to ERP master data are controlled, approved, and audited.
    • How you demonstrate consistency between ERP and downstream systems during audits.

    This mapping is usually more important than the specific technology choices, as long as roles and interfaces are clear, validated, and maintained under change control.

  • What MES data do I need before starting AI projects in aerospace?

    You do not need a perfect MES to start AI projects in aerospace. You do need data that is trustworthy enough for a narrow, well-defined problem and traceable enough that engineering, quality, and operations can review how the output was produced.

    In practice, the best starting point is not “all MES data.” It is the smallest data set that supports one operational question, such as predicting rework risk on a process step, identifying likely bottlenecks, or prioritizing quality review queues.

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    Minimum MES data foundation

    For most aerospace manufacturing use cases, the minimum useful MES data set includes:

    • Work order and routing history
      Operation sequence, work center, planned versus actual step completion, hold events, rework loops, and dispatch status.

    • Part, serial, and lot traceability
      Part number, revision, serial number or lot, parent-child relationships where applicable, and material or component consumption records.

    • Timestamps with consistent event meaning
      Start, stop, queue, move, hold, release, inspection complete, and close timestamps. If timestamp semantics vary by area or by shift, AI outputs will be difficult to trust.

    • Quality outcomes
      Inspection results, pass-fail dispositions, defect codes, NCR links, rework records, scrap events, and disposition timing.

    • Operator and resource context
      Work center, machine or asset identifier, shift, certification or role if allowed by policy, and major tooling context. This matters when trying to separate product effects from resource effects.

    • Configuration and revision context
      Routing revision, work instruction revision, process plan revision, and where possible the effective configuration at the time of execution.

    • Basic master data stability
      Consistent part numbers, operation codes, defect codes, reason codes, and asset identifiers. If names and codes change without control, the model may learn noise instead of process behavior.

    What usually matters more than volume

    For aerospace, data quality and context usually matter more than raw volume. A smaller, cleaner execution history with stable identifiers and strong genealogy is more useful than a large MES extract full of missing timestamps, free-text workarounds, and uncontrolled code changes.

    You should expect problems if any of the following are true:

    • The MES event model changed over time and no one mapped old and new meanings.

    • ERP, PLM, QMS, and MES disagree on part revision, operation naming, or status definitions.

    • Rework is recorded inconsistently or outside the MES in spreadsheets, email, or disconnected QMS workflows.

    • Inspection outcomes are captured, but not linked reliably to the exact operation, configuration, or serial number.

    • Important process changes were made without clean change control metadata, making before-and-after comparisons misleading.

    Data readiness by AI use case

    The data needed depends on the use case.

    • Bottleneck and flow analysis
      You mainly need event timestamps, routing states, queue and hold reasons, and work center context.

    • Yield, scrap, or rework prediction
      You need genealogy, operation history, inspection outcomes, defect codes, rework loops, revision context, and enough historical examples of failures to train against.

    • Operator guidance or anomaly detection
      You may also need machine, sensor, or test data outside MES, plus digital work instruction usage and exception history.

    • Scheduling or dispatch recommendations
      You usually need MES plus ERP and planning context, because MES alone rarely contains all constraints, material status, outside processing dependencies, or program priorities.

    So the honest answer is that MES data alone is often necessary but not sufficient.

    What is enough to start

    A practical starting threshold is usually:

    • One clearly defined business question

    • Six to eighteen months of reasonably consistent execution history, if product and process conditions were stable enough during that period

    • Reliable identifiers linking work orders, operations, parts, serials or lots, and quality events

    • A known system of record for each critical field

    • Documented data gaps and business rules, rather than pretending the data is cleaner than it is

    That said, the required history length depends on event frequency and process stability. High-mix, low-volume programs may not produce enough repeatable examples for some supervised models. In those environments, analytics, rules, and constrained anomaly detection may be more realistic than ambitious predictive AI.

    Brownfield reality in aerospace

    In aerospace plants, MES data readiness is usually limited by coexistence issues, not just MES functionality. Many sites run mixed MES, ERP, PLM, QMS, and homegrown systems with different data models and years of integration debt. Important execution evidence may be split across digital travelers, test systems, inspection tools, and manual records.

    That is why full replacement is rarely the right prerequisite for AI. Replacing MES or surrounding systems first often fails because of qualification burden, validation cost, downtime risk, integration complexity, and the long lifecycle of equipment and regulated processes. A narrower approach is usually safer: map the data needed for one use case, establish traceable extracts, validate logic with process owners, and expand only after the outputs are reviewable and useful.

    Governance you should have before production use

    Before using AI outputs operationally, you should have:

    • Clear data lineage from source systems to features and outputs

    • Change control for mappings, code sets, and model versions

    • Review procedures for questionable recommendations or anomalies

    • Defined handling for missing, late, or corrected records

    • Validation appropriate to the intended use and system impact

    This does not guarantee acceptance or compliance outcomes, but without these controls, AI results are hard to defend in a regulated environment.

    Bottom line

    Start with MES data that can reliably answer one operational question: event history, routing context, genealogy, quality outcomes, revision context, and stable timestamps. If those links are weak, fix the data path before scaling AI. If those links are strong, you can begin with a bounded use case even in a brownfield aerospace environment.

  • What are the main business benefits of ISO 9001 certification?

    ISO 9001 certification can provide real business benefits, but only when the quality management system (QMS) is genuinely used to run the operation, not treated as paperwork for auditors. In regulated and aerospace-grade environments, the main benefits come from better control of processes, clearer accountability, and more predictable outputs across a complex system of plants, suppliers, and IT.

    1. More consistent quality and fewer surprises

    ISO 9001 pushes you to define, control, and monitor key processes. When this is done well, you typically see:

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

    • More consistent part conformance and documentation quality across shifts, sites, and suppliers.
    • Earlier detection of issues through defined checks, reviews, and internal audits.
    • Less variation driven by tribal knowledge or individual workarounds.

    The impact depends on how seriously you treat process definition, training, and change control. A certificate alone does not reduce nonconformances or escapes.

    2. Structured approach to risk and problem solving

    ISO 9001 requires risk-based thinking, corrective actions, and structured management review. Done properly, this can lead to:

    • Clearer prioritization of risks that can impact product quality or delivery.
    • More disciplined root cause analysis and closure of corrective actions, instead of recurring fixes.
    • Documented decision-making that is easier to defend to customers and regulators.

    The business benefit appears only if leadership actually uses these mechanisms to make decisions, not just to populate audit binders.

    3. Better customer confidence and access to business

    Many OEMs and tier-1s expect ISO 9001 (or sector-specific variants like AS9100) as a baseline. Certification can:

    • Reduce friction in supplier qualification and RFQ processes.
    • Improve customer confidence in your ability to control quality and maintain traceability.
    • Support answers to customer audits and questionnaires with a recognized framework.

    Certification does not guarantee good audit outcomes or protect you from customer scrutiny, but it can shorten discussions and open doors where ISO 9001 is an explicit requirement.

    4. Clearer roles, documentation, and traceability

    ISO 9001 emphasizes documented processes, responsibilities, and records. In practice, this can enable:

    • Less ambiguity over who owns which process, metrics, and approvals.
    • Stronger document control and version governance for procedures, work instructions, and specifications.
    • More reliable evidence trails for product history, changes, and decisions.

    These benefits are critical in environments with long equipment lifecycles, multiple revisions, and frequent audits. The value depends on how well your QMS is integrated into daily workflows and IT systems, not just that documents exist.

    5. Foundation for continuous improvement and cost reduction

    ISO 9001 does not prescribe lean or Six Sigma, but it establishes a framework for continuous improvement. Over time, this can support:

    • Reducing cost of poor quality (scrap, rework, returns, concessions) through data-driven corrective actions.
    • Improving throughput and on-time delivery by stabilizing and standardizing processes.
    • Making improvement projects auditable and repeatable across sites.

    The magnitude of savings depends heavily on data quality, measurement systems, and whether continuous improvement is truly embedded in operations, not just a quality department activity.

    6. Stronger governance over change and long lifecycle assets

    ISO 9001 requires formal control of design and process changes. In regulated, long-lifecycle environments, this often delivers:

    • Reduced risk of uncontrolled changes affecting certified products, tooling, or software.
    • Better alignment between engineering changes, production, and quality records.
    • More predictable impacts on validation, requalification, and documentation when processes or systems change.

    This is especially important when you upgrade MES/ERP/QMS components or modify legacy equipment that has been in service for decades. A disciplined ISO 9001 change process can prevent misaligned updates that cause line stoppages or audit findings.

    7. Coexistence with existing systems and brownfield reality

    In most plants, ISO 9001 is layered on top of a mix of legacy MES, ERP, PLM, and paper-based systems. The benefits depend on how you implement the standard in this brownfield context:

    • Integration over replacement: Trying to replace all systems to “be ISO-compliant” is rarely viable due to qualification burden, validation cost, and downtime risk. It is usually more effective to integrate existing systems into a coherent QMS framework and close the gaps with targeted changes.
    • Realistic traceability: ISO 9001 expects you to maintain appropriate records and traceability. How far you go (lot-level, serial-level, full genealogy) must align with your sector requirements and with what your current systems can reliably support.
    • Validation and change control: Any IT or process changes you make to support ISO 9001 (e.g., new QMS modules, digital work instructions) should go through formal validation and change control, or you risk trading one set of problems for another.

    Plants that treat ISO 9001 as a way to rationalize their existing system landscape and clarify interfaces usually see more benefit than those that launch large, disruptive replacement programs justified primarily by certification goals.

    8. Limitations and common failure modes

    ISO 9001 certification is not a guarantee of quality, compliance, or safety performance. Common failure modes include:

    • A well-documented QMS that operators do not actually follow on the shop floor.
    • Processes tailored to pass audits rather than to control real operational risk.
    • Certificates used as marketing proof without corresponding investment in training, data, or system integration.

    To realize business benefits, leadership has to use ISO 9001 as a management system: align KPIs with the QMS, use audit findings to drive meaningful improvements, and ensure IT/OT changes support the processes described in the QMS.

    In summary, ISO 9001 certification can support improved consistency, customer trust, and structured improvement, but the business payoff is determined by implementation quality, integration with existing systems, and ongoing governance, not by the certificate itself.

  • How long should CAPAs remain open before escalation?

    There is no universal maximum time that a CAPA can stay open before escalation. The escalation trigger has to be defined in your quality system and justified by risk, process complexity, and resource reality. Regulators will expect you to follow your own procedure consistently and explain why it makes sense.

    Typical timeframes used in regulated environments

    While numbers vary by company and product risk, many sites use time-based triggers like:

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

    • Low/medium risk CAPAs: 60 to 90 days to implementation, with earlier checkpoints.
    • High risk / patient safety / regulatory impact CAPAs: 30 to 60 days for containment and critical actions, sometimes with formal weekly review.
    • Effectiveness checks: Often scheduled 30 to 180 days after implementation; these have their own aging rules.

    The exact numbers should be documented in your CAPA SOP, not improvised case by case.

    Use tiered escalation instead of a single deadline

    Rather than one “max age,” most mature systems define staged escalation based on target due dates:

    • Planned due date: Set per CAPA step (investigation, root cause, implementation, effectiveness check), aligned to risk.
    • Early warning (e.g., 14 days before due date): Reminder to owner and functional manager.
    • First escalation (e.g., at due date missed): Escalate to department head; documented justification and revised plan required in the CAPA record.
    • Second escalation (e.g., 30 days late or crossing a defined “max age” threshold): Escalate to site quality leadership and possibly management review.
    • Critical escalation (for high risk CAPAs or repeated slippage): Escalate to executive leadership, with explicit risk assessment of operating with CAPA open.

    This approach recognizes that a complex, multi-site CAPA may legitimately take longer than a simple local corrective action, while keeping visibility on aging items.

    Risk-based timelines are expected

    Escalation criteria should be explicitly tied to risk, not just calendar age. Consider:

    • Severity of the underlying issue (e.g., safety, regulatory, business continuity).
    • Detectability and occurrence (e.g., how likely is recurrence while the CAPA is open).
    • Scope and complexity of changes (multiple lines, suppliers, or software/automation changes usually need longer and more formal change control).

    High risk CAPAs generally warrant shorter timelines, stricter monitoring, and faster escalation than low risk, localized issues.

    What auditors and regulators actually look for

    Auditors rarely look for a specific “number of days” as a rule that applies everywhere. Instead, they assess whether:

    • Your CAPA procedure defines clear expectations and escalation rules.
    • You follow your own rules and document deviations and justifications.
    • Risks are controlled while CAPAs are open (containment, interim controls, additional inspection or testing).
    • Chronic aging CAPAs are visible in management review and trigger systemic fixes (e.g., resourcing, prioritization, training).

    Inconsistent behavior is usually a bigger problem than a long but justified and documented CAPA timeline.

    Handling long-duration or complex CAPAs

    In industrial and aerospace-grade environments, some CAPAs legitimately take many months because they involve:

    • Changes to qualified equipment or validated software.
    • Updates across multiple plants, suppliers, or ERP/MES/QMS integrations.
    • Customer approvals, contract changes, or formal requalification.

    Closing these too quickly to “hit a date” can create new nonconformances. For long, complex CAPAs, you can mitigate aging by:

    • Breaking work into phased CAPAs or sub-actions with their own due dates.
    • Maintaining strong interim controls (e.g., 100% inspection, additional signoffs, temporary process limits).
    • Documenting why a longer timeline is necessary (e.g., shutdown windows, validation testing, supplier lead times).
    • Reviewing progress in formal governance forums like CAPA review boards or management review.

    This is particularly important in brownfield sites where changing legacy MES/ERP, test equipment, or automation carries downtime, validation, and integration risk.

    Practical minimums for defining your own rules

    When you write or refine your CAPA SOP, you should at least:

    • Define target timelines per CAPA phase (e.g., investigation, root cause, action plan, implementation, effectiveness check).
    • Define risk-based categories (e.g., critical, major, minor) with different expectations.
    • Specify time-based aging thresholds for reminders and escalations (e.g., 30/60/90 days, adapted to your environment).
    • Require a documented justification and revised plan any time a due date is extended.
    • Ensure your eQMS, MES, or tracking tools can report CAPA aging and escalation status accurately.

    Whatever thresholds you choose, they should be achievable with your current staffing, system integration, and shutdown windows. Overly aggressive “paper” timelines that are routinely violated often look worse during audits than a realistic, risk-justified plan.

    Bottom line

    CAPAs should not remain open indefinitely, but there is no single mandated maximum age. Use risk-based, phase-specific targets with clear, staged escalation and documented justifications for any delays. In complex, regulated, and brownfield environments, longer timelines can be acceptable if interim risk controls are strong and governance is disciplined.

  • What types of controls does AS9100 expect for counterfeit parts prevention?

    AS9100 expects you to implement a documented, risk-based counterfeit parts prevention process that is integrated into your quality management system. The standard does not prescribe a single method, but it does expect a coherent set of controls across supplier management, purchasing, receiving, production, and nonconformance handling.

    1. Documented counterfeit parts prevention process

    AS9100 requires you to define, maintain, and control a counterfeit parts prevention process or procedure. At a minimum, it should:

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

    • Define what your organization considers a counterfeit or suspected counterfeit part (aligned with AS9100 and any customer/contract definitions).
    • Describe responsibilities across quality, supply chain, engineering, and production.
    • Specify where and how controls apply: supplier selection, purchasing, receiving, in-process, inventory, service/repair, and disposal.
    • Describe how to escalate, investigate, and disposition suspected counterfeit parts using your existing nonconformance and CAPA processes.
    • Include how you maintain records to provide objective evidence during audits.

    2. Supplier evaluation and approval controls

    AS9100 expects you to reduce counterfeit risk by controlling who you buy from and under what conditions. Typical controls include:

    • Approved supplier list (ASL): Criteria for adding and maintaining suppliers, with stronger criteria for high-risk categories (electronic components, hardware, high-value or safety-critical items).
    • Preference for original sources: Using original component manufacturers (OCMs), original equipment manufacturers (OEMs), or their authorized distributors whenever feasible.
    • Heightened controls for brokers/independent distributors: Additional verification, audits, or test requirements when you must use non-authorized sources.
    • Supplier performance monitoring: Tracking quality history, documentation issues, and any counterfeit-related incidents as part of supplier scorecards or periodic reviews.
    • Flowdown requirements: Requiring suppliers to maintain their own counterfeit parts prevention controls and to flow those requirements down their supply chains when applicable.

    In brownfield environments this usually means tightening criteria and documentation around an existing ASL, not replacing supplier systems outright. Changes typically have to move through established change control and supplier qualification processes.

    3. Purchasing and contract controls

    AS9100 expects purchasing documents to include requirements that reduce counterfeit risk. Common elements are:

    • Clear sourcing requirements: Specifying OCM/OEM or authorized distribution channels where required.
    • Traceability requirements: Mandating certificates of conformity, manufacturer certificates, test reports, and lot/date codes as appropriate.
    • Change notification: Requiring suppliers to notify you of substitutions, alternate sources, or changes in distribution channels.
    • Right of access and audit: Enabling you (and sometimes customers or regulators) to review the supplier’s counterfeit controls.
    • Suspected counterfeit reporting obligations: Expecting the supplier to cooperate in investigations and reporting if suspect parts are identified.

    Practically, this often involves updating PO templates and ERP purchasing data, plus retraining buyers on when to invoke stricter clauses based on part criticality and risk.

    4. Receiving inspection and verification controls

    AS9100 expects you to verify that incoming product is authentic and conforms to requirements, with the level of scrutiny based on risk. Typical controls include:

    • Document verification: Checking certificates of conformity, manufacturer certificates, lot/date codes, and serial numbers for consistency with POs and specifications.
    • Visual inspection: Looking for signs of tampering, re-marking, inconsistent packaging, or physical anomalies (especially for electronic components and hardware).
    • Sampling plans: Applying more stringent sampling and verification for high-risk sources or part families.
    • Enhanced testing where warranted: Electrical tests, X-ray, material analysis, or other methods for high-risk items when risk assessment justifies the cost and time.
    • Receiving holds: Preventing use of high-risk parts until required documentation and verification steps are completed.

    In brownfield plants this usually requires procedural updates and receiving training, plus some alignment with existing inspection and sampling plans. It may also require adjustments in ERP/MES receiving workflows to support holds and additional checks.

    5. Traceability and inventory controls

    AS9100 expects you to maintain sufficient traceability to detect, contain, and remove counterfeit or suspect parts. Controls typically include:

    • Lot and serial tracking: Maintaining traceability from received lot or serial numbers to work orders, assemblies, and shipped product for critical parts.
    • Segregated storage: Clearly separating conforming stock, suspect stock, and nonconforming/scrap so suspect material cannot be used by mistake.
    • Inventory transactions with genealogy: Recording movements between locations and work orders to support fast containment.
    • Controlled returns and reuse: Procedures for returns (RMA), teardown, and reuse to avoid reintroducing suspect material into inventory.

    In many regulated environments, full system replacement is not realistic due to validation and downtime constraints. Instead, organizations typically enhance traceability within existing ERP/MES/WMS platforms, use add-on tools for genealogy where needed, and strengthen procedures and labeling for suspect and nonconforming stock.

    6. Production and maintenance controls

    AS9100 expects counterfeit prevention to extend into production, repair, and overhaul activities:

    • Bill of material (BOM) and routing control: Ensuring only approved part numbers and sources are used for critical items.
    • Shop-floor verification: Work instructions or traveler checks for critical parts (e.g., verifying part/lot/serial against the traveler or build record).
    • Control of customer-furnished or repaired parts: Verifying authenticity and condition of customer-supplied items and parts returned for overhaul or repair.
    • Scrap and rework handling: Clear rules preventing scrapped or high-risk suspect parts from being reintroduced into production.

    These controls typically coexist with existing digital travelers, work instructions, and tool control in MES or paper-based systems. Organizations rarely replace core systems just to add counterfeit checks; they embed steps into existing workflows and validate those changes.

    7. Nonconformance, investigation, and disposition controls

    AS9100 expects suspected counterfeit parts to be managed through your nonconformance and CAPA processes, not treated as an informal side process. Typical controls include:

    • Immediate segregation and quarantine: Any suspected counterfeit part is clearly identified, removed from use, and placed in a controlled area.
    • Formal NCR / MRB process: Documenting the nonconformance, performing risk assessment, and deciding disposition via MRB in accordance with your QMS.
    • Root cause and corrective action: Using structured methods (e.g., RCA, 8D) to address why the counterfeit part entered your system (supplier, purchasing, inspection, design, or system gap).
    • Communication and reporting: Notifying affected customers and, where applicable, industry reporting bodies in line with contractual and regulatory requirements.
    • Documented disposal: Ensuring confirmed counterfeit parts are destroyed or rendered unusable and cannot re-enter the supply chain.

    Because nonconformance and CAPA systems are usually deeply embedded and validated, organizations tend to extend those systems for counterfeit scenarios rather than deploy a separate tool. Careful change control and validation are important if you modify digital NCR/MRB workflows.

    8. Training and awareness

    AS9100 expects personnel who can influence counterfeit risk to be trained and aware of their role. Typical practices include:

    • Role-specific training: For buyers, receiving inspectors, warehouse staff, engineers, and production supervisors.
    • Recognition of red flags: Visual cues, documentation anomalies, unusual pricing or lead times, and channel risks.
    • Reporting expectations: How to escalate if a part looks suspicious or documentation does not align with expectations.
    • Periodic refreshers: Integrating counterfeit awareness into ongoing competency and recurrent training schedules.

    9. Risk-based application and continual improvement

    AS9100 is explicit about risk-based thinking. Counterfeit controls should scale with risk, considering part criticality, market conditions, and supplier history. Auditors will typically look for:

    • Evidence that you have assessed which parts and suppliers present higher counterfeit risk.
    • Stronger controls where the risk and consequence of failure are higher.
    • Use of data from NCRs, supplier performance, and industry alerts to update controls over time.
    • Change control and, where relevant, validation of system or process updates related to counterfeit prevention.

    In long-lifecycle aerospace programs, any changes to traceability, supplier qualification, or digital workflows often require careful planning to avoid disrupting qualified configurations and to preserve evidence trails.

    10. Limits and dependencies

    AS9100 does not guarantee that counterfeit parts will never enter your supply chain. What it expects is:

    • A documented and implemented process appropriate to your risk profile and product types.
    • Integration of counterfeit prevention into your existing QMS, supplier management, and traceability processes.
    • Objective evidence that controls are followed, monitored, and improved when issues occur.

    The exact mix of controls you adopt will depend on your supply base, product mix, digital maturity, and the practical constraints of your brownfield environment. Full replacement of core systems solely to add counterfeit controls is rarely necessary and often impractical given qualification and downtime risks; most organizations layer additional controls onto existing, validated processes and systems.

  • What information should be visible in real time to aerospace production supervisors?

    Aerospace production supervisors need real-time information that directly supports safe, compliant throughput. The specific design of views depends on your MES/ERP stack, data quality, and validation status, but the focus should be on current execution risk, not just historical KPIs.

    1. Work status and flow control

    Supervisors need a live picture of what work is running, blocked, or at risk:

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

    • Current WIP by cell/line: work orders, tail/serial numbers, configuration, and routing step currently in process.
    • Queue depth and aging: how many jobs are waiting at each constraint and how long they have been waiting.
    • Planned vs actual start/finish: operations or jobs that are late to start, late to complete, or projected to miss need-by dates.
    • Upcoming critical operations: operations that are time or resource critical (e.g., autoclave runs, special processes, takt-managed final assembly) in the next 4–8 hours.

    In brownfield environments this is usually stitched together from MES, dispatch lists, and spreadsheets. Any new real-time board should be validated against these existing sources before being trusted.

    2. Resource availability and constraints

    Real-time visibility must highlight what is limiting output right now:

    • Machine and cell status: running, idle, changeover, setup, down, under maintenance, or held for investigation.
    • Planned vs unplanned downtime: current outages, reason codes, and expected time to return to service.
    • Labor coverage: who is logged onto which operation or cell, current skill coverage, and any uncovered critical operations.
    • Tooling and fixture status: availability of required tools/fixtures, calibration status, and any tools in quarantine.

    Integrating OT data (machine signals) and MES labor tracking can be challenging and often requires progressive rollout and clear ownership of data corrections.

    3. Materials, shortages, and kitting

    Supervisors need to see material risk before it stops the line:

    • Shortages against today’s plan: parts and consumables that are missing, low, or late for operations scheduled in the current and next shift.
    • Kit completeness: kitting status for each work order or aircraft position, with explicit flags for partial kits.
    • Critical parts and effectivity: items with export-control constraints, shelf life, lot-controlled material, or specific serial-match requirements.
    • Incoming receipts at risk: inbound supplier deliveries or internal transfers that, if late, will impact specific jobs.

    These views typically depend on tight and well-maintained ERP/MRP integration. If backflushing or manual issues are delayed, “real-time” material views will be misleading and should be labeled accordingly.

    4. Quality, NCRs, and rework exposure

    Quality risk must be visible in time to act, not just after the fact:

    • Open NCRs on today’s work: nonconformances tied to current WIP, with clear indication if work is on hold, allowed to progress, or proceeding under deviation/concession.
    • Rework and scrap in the shift: parts moved into rework routes, scrap events, and high-frequency defect codes on specific cells.
    • Inspection queues: in-process and final inspection backlogs, including which jobs are waiting on QC sign-off.
    • High-risk characteristics: operations with recent issues on key/critical characteristics, FAI-related steps, or special processes with new parameters or new operators.

    In many plants, NCR and QMS data are in separate systems from MES. Near real-time synchronization and clear rules about when status changes are authoritative are essential to avoid working to conflicting information.

    5. Compliance, traceability, and process adherence

    Supervisors need visibility into where execution is drifting from the defined, qualified process:

    • Hold points and sign-offs: operations that cannot proceed without specific quality, engineering, or customer approvals.
    • Process deviations in effect: open deviations, concessions, or engineering authorizations that apply to current jobs, with clear linkage to affected serials or lots.
    • Work instruction and revision alignment: current job step vs required revision, with alerts if operators are at risk of using superseded instructions or travelers.
    • Special process compliance status: confirmation that required approvals, parameters, and certifications are valid for ongoing work (e.g., NADCAP processes, calibrated equipment use).

    Real-time compliance views should never be treated as certification or audit guarantees. They are operational aids and must be backed by robust document control, configuration management, and validated digital signatures where used.

    6. Safety, escapes, and stop-the-line triggers

    Production supervisors need immediate visibility into anything that can justify or require stopping work:

    • Active safety events: current EHS incidents, unsafe conditions, or lockout/tagout areas impacting production.
    • Suspected quality escapes: potential escapes that may affect in-process work or recently shipped product, with guidance from quality/engineering.
    • Process lockouts: operations or equipment that must not be used pending investigation or containment.

    These signals usually come from EHS and quality systems. Tight coordination is needed so that any stop-the-line indication in a real-time view is quickly validated and cleared or escalated.

    7. Near-term performance and shift control

    Supervisors need tactical performance metrics that are close enough to real time to adjust staffing and priorities:

    • Throughput vs plan: units or key assemblies completed vs the shift plan, with leading indicators (e.g., operations completed, not just final assembly).
    • OEE or equivalent KPIs at the constraint resource: availability, performance, and quality components where data is trustworthy.
    • NPT and delay codes: non-productive time by category (waiting on material, engineering, quality, tools, or approvals).
    • Short interval control: status of actions from previous production meetings (e.g., 30/60/90 minute or 2-hour huddles).

    In regulated aerospace environments, these metrics should be traceable back to raw events and logs. Black-box dashboards without evidence trails make it difficult to use the data in investigations or continuous improvement work.

    8. Operator guidance and escalation paths

    Supervisors also need to see whether the workforce has the information and support needed to execute correctly:

    • Active help requests: calls for support from operators (quality help, engineering question, material request, maintenance ticket).
    • Training and authorization gaps: operations staffed with operators whose training or authorization status is mismatched to the requirement.
    • Instruction usage and dwell: steps where operators are frequently pausing, re-reading, or requesting clarification, indicating potential confusion or poor standard work.

    These views typically rely on digital work instructions or MES front-ends. They need careful change control, since changes to escalation logic or training rules can affect who is allowed to perform which steps.

    9. Implementation and brownfield realities

    Making this information visible in real time is constrained by your existing systems and validation approach:

    • Multiple systems of record: ERP, MES, QMS, PLM, and maintenance systems rarely agree perfectly. Supervisors must know which source is authoritative for each data type.
    • Data latency vs “real time” claims: if integrations update every 5–15 minutes, label that explicitly. Some decisions tolerate this; others do not.
    • Validation and change control: in regulated aerospace, any view used for official records or compliance evidence must be validated. Quick custom dashboards may be useful for supervision but not suitable as primary records.
    • Coexistence, not replacement: full rip-and-replace of MES/ERP just to improve supervisor visibility is rarely practical due to downtime, requalification, and integration risks. A layered approach that surfaces existing data with better usability is more common.

    Before relying on any new real-time board for operational decisions, cross-check it against existing reports and shop-floor reality, and document known gaps or approximations. Supervisors will trust what is consistently accurate and traceable.

  • How can I show AI risk scores to operators without overwhelming them?

    Use AI risk scores as guided decision support, not as another dashboard. In most plants, the safest approach is to translate the score into a small number of operator-facing states such as normal, review, and escalate, then pair each state with a specific approved action.

    Do not ask operators to interpret probabilities, model confidence, feature weights, or trend charts unless their role actually requires it. Raw scores often create hesitation, workarounds, or alarm fatigue, especially when the model is noisy or the action path is unclear.

    In practice, this connects to digital operator experience when teams need to turn the answer into repeatable execution habits.

    What to show on the operator screen

    • A simple risk state with consistent visual treatment.

    • A short plain-language reason, for example which process condition or deviation triggered the alert.

    • The required next step, such as verify setup, perform a defined inspection, call quality, or continue and monitor.

    • A link to the governing work instruction, escalation path, or exception workflow.

    • Time relevance, so the operator knows whether the signal is current, stale, or based on missing data.

    If the model output affects quality decisions, containment, or routing, the screen should also make clear whether the AI is advisory only or whether a governed business rule is driving the action. That distinction matters for training, traceability, and investigation later.

    What not to show by default

    • Continuous 0 to 100 scores without action context.

    • Too many alert levels.

    • Model internals that are difficult to interpret on the shop floor.

    • Competing KPIs, trends, and diagnostics on the same screen.

    • Warnings that operators cannot act on.

    If engineers or quality teams need more detail, provide drill-down views outside the primary operator workflow. The operator view and the engineering review view should usually be different.

    Design for action, not curiosity

    A practical pattern is:

    1. Detect elevated risk.

    2. Map it to a validated threshold or rule band.

    3. Present one recommended action.

    4. Capture operator response and outcome.

    5. Route exceptions into existing MES, QMS, maintenance, or supervisor workflows.

    This reduces cognitive load and gives you an evidence trail for whether the signal was useful, ignored, wrong, or late.

    Important limits and tradeoffs

    Less detail is usually better for usability, but too much simplification can hide uncertainty. If the model is unstable, trained on incomplete history, or sensitive to data latency, a clean-looking risk badge can create false confidence. Be explicit about those limits in system design, training, and escalation logic.

    Threshold design is also site-specific. A threshold that works on one line, product family, or machine state may fail on another because of different process windows, operator practices, sensor quality, or mix complexity. Expect tuning, version control, and periodic review.

    Human factors matter. If too many events land in the middle band, operators may stop trusting the signal. If the system fires rarely but blocks work, they may bypass it. If it misses obvious bad conditions, credibility drops quickly. You need feedback loops, not just a model deployment.

    Brownfield integration reality

    In regulated manufacturing, this usually should coexist with existing MES, SCADA, historian, QMS, and digital work instruction systems rather than replacing them. Full replacement often fails because qualification effort, downtime risk, integration debt, and change control burden are high, especially with long-lived equipment and validated processes.

    A more workable pattern is to keep the system of record where it is and add AI-driven guidance at the edge of the workflow. For example, show the operator prompt in the existing HMI, MES screen, or work instruction layer, while storing model version, input context, alert state, acknowledgement, and resulting action in traceable records. Whether that is feasible depends on available APIs, event timing, master data alignment, identity management, and how cleanly the existing stack supports extensions.

    Validation and governance

    If the score influences execution, inspection intensity, hold decisions, or review priority, treat the presentation logic and action mapping as controlled changes. You will typically need:

    • Documented threshold rationale and ownership.

    • Versioning for the model, rules, and displayed text.

    • Test evidence that the right alert appears under the right conditions.

    • Change control for updates to prompts, thresholds, integrations, and training.

    • Traceability from alert to operator action to downstream outcome.

    That does not guarantee any audit or compliance result, but it does reduce the risk of deploying an opaque signal into a controlled process with no evidence trail.

    In short, show operators a bounded risk state, the reason, and the approved next action. Keep deeper analytics for engineering and quality review. If you cannot connect the score to a clear workflow, reliable data, and controlled change process, the display will likely add noise rather than improve execution.