Connect981 – Content Dev

RSC Content Type: FAQ

Direct answers to common technical or compliance questions.

  • What is the meaning of non conformities?

    In regulated manufacturing, a nonconformity is any instance where a product, process, service, or system does not meet a defined requirement. The requirement can come from a drawing, specification, work instruction, control plan, contract, standard, or an internal procedure.

    Typical types of nonconformities

    Common categories include:

    • Product nonconformity: The part or material does not meet dimensional, functional, performance, cleanliness, or documentation requirements (for example, missing inspection record, wrong revision, out-of-tolerance feature).
    • Process nonconformity: The process was not executed as required (for example, skipped operation, incorrect parameter, unqualified operator, expired calibration, or using an unapproved program or recipe).
    • System or procedural nonconformity: The management system does not follow an approved procedure or a standard requirement (for example, QMS procedure not followed, required review not performed, records incomplete or not retained as specified).
    • Supplier nonconformity: Any of the above, but originating from an external provider or subcontractor and detected at incoming inspection, in-process, or in the field.

    How nonconformities relate to defects and compliance

    In practice:

    • Every defect in a regulated product should correspond to at least one defined nonconformity.
    • Not every nonconformity is a safety or regulatory issue. Some are low risk (for example, minor documentation errors) but still require controlled handling and traceability.
    • Nonconformity is a neutral term. It does not guarantee a regulatory finding or audit outcome. How you detect, classify, document, and act on nonconformities is what auditors and customers evaluate.

    Why nonconformities matter in regulated, brownfield environments

    Because most plants run mixed legacy and modern systems with long-qualified equipment, nonconformities are a key mechanism to:

    • Maintain traceability when issues span multiple systems (for example, ERP, MES, QMS, PLM) and suppliers.
    • Feed CAPA and improvement activities with structured, evidence-based problem data.
    • Control risk without needing to replace existing systems, which is often not feasible due to validation burden, downtime risk, and integration complexity.

    How nonconformities are typically handled

    Although the exact workflow depends on your QMS, system configuration, and process maturity, a typical pattern is:

    1. Detection and recording: A deviation is identified on the line, at incoming inspection, in test, or in the field. It is logged as a nonconformity with date, source, product, batch/lot, and evidence (measurements, photos, records).
    2. Containment: Affected product or process is contained (for example, quarantine, hold tag, blocking in MES/ERP) to prevent unintended use.
    3. Evaluation and disposition: The impact is assessed and a controlled disposition is made, such as rework, repair, use-as-is under concession, scrap, or return to supplier. In regulated environments, this must be documented and traceable.
    4. Linking to root cause and CAPA: Significant, recurrent, or high-risk nonconformities often trigger root cause analysis and corrective or preventive actions. The nonconformity record becomes part of the objective evidence trail.
    5. Verification and closure: Actions taken are verified for effectiveness where applicable, and the nonconformity is formally closed in the QMS or MES with proper approval and change control.

    Key constraints and dependencies

    The way nonconformities are defined and managed in your environment depends on:

    • Applicable standards and regulations (for example, aerospace, medical devices, pharmaceuticals, nuclear), which may have specific definitions and handling rules.
    • System landscape: Whether you record nonconformities in a QMS, MES, ERP, PLM, or multiple systems. Integration quality and master data governance strongly affect traceability.
    • Validation and change control: Any change in how you capture or process nonconformities typically requires impact assessment, documented rationale, and, in some cases, system revalidation.

    In summary, a nonconformity is any documented deviation from an approved requirement, managed through a controlled process to protect product quality, safety, and compliance across complex, long-lived manufacturing systems.

  • Do we need a formal CAPA system for ISO 9001 compliance?

    ISO 9001 requires you to have a defined corrective action process and to keep records, but it does not require a specific software product or branded “CAPA system.” You can meet the requirement with paper, spreadsheets, or a module inside an existing QMS, provided the process is controlled, repeatable, and auditable.

    What ISO 9001 actually requires

    The core requirements related to CAPA are:

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

    • A documented process for handling nonconformities and corrective actions (including how you react, contain, investigate, and prevent recurrence).
    • Evidence-based root cause analysis and selection of appropriate actions.
    • Records of actions taken, responsibility, and due dates.
    • Verification that actions were effective.
    • Controlled records that can be retrieved during audits.

    ISO 9001 does not prescribe:

    • Which software platform you must use.
    • Whether it is on paper, in a generic ticketing tool, or in a dedicated eQMS.
    • Any specific workflow engine, dashboards, or integrations.

    When a “formal” CAPA system becomes necessary in practice

    While not strictly required by ISO 9001, a more formal CAPA system usually becomes necessary when:

    • You have multiple sites, high NCR volume, or complex products and need consistent workflows.
    • Regulators or customers (for example aerospace primes or medical OEMs) expect CAPA traceability beyond ISO 9001.
    • You need tight linkage between NCRs, change control, training, and configuration-managed work instructions.
    • Paper or ad hoc tools can no longer reliably support timeliness, effectiveness checks, or audit retrieval.

    In these cases, a digital CAPA application or QMS module helps standardize data, enforce required steps, and provide evidence trails. But it still must be implemented, validated, and governed correctly to satisfy auditors.

    Brownfield and coexistence considerations

    In most established plants, CAPA cannot live in isolation. You will typically need to integrate or at least align CAPA with:

    • Existing NCR/MRB workflows in MES, ERP, or legacy QMS.
    • Document control and change control for procedures and work instructions.
    • Training and qualification records to show that corrective actions were deployed to operators.
    • Supplier quality processes when root causes extend into the supply chain.

    Full replacement of legacy quality or MES systems with a new CAPA platform often fails in regulated, long-lifecycle environments because of validation burden, downtime risk, integration complexity, and the need to preserve historical evidence. A more realistic approach is to:

    • Standardize the CAPA process and data model.
    • Layer digital CAPA capabilities on top of existing systems.
    • Use interfaces or disciplined manual linkages (NCR IDs, change order numbers) to maintain traceability.

    Key criteria for ISO 9001 alignment

    Regardless of tooling, auditors will look for whether your CAPA approach:

    • Is documented, controlled, and understood by users.
    • Is consistently followed in practice, not just on paper.
    • Links nonconformities to root cause, corrective actions, and effectiveness checks.
    • Maintains records that are traceable, complete, and protected from uncontrolled editing.
    • Is subject to change control and periodic review for effectiveness.

    If your paper or spreadsheet-based process can demonstrate those points reliably, it can be ISO 9001 compliant. A more formal, digital CAPA system can make this easier to sustain at scale, but it is a design choice, not a direct clause-level requirement.

  • What is an NCR in quality?

    An NCR in quality management is a Nonconformance Report (often called a Nonconformity Report). It is a formal record used to document any instance where a product, process, document, or system does not meet an approved requirement.

    What an NCR typically covers

    In regulated manufacturing environments, an NCR is used when there is a deviation from:

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

    • Product requirements (e.g. drawings, specifications, material requirements)
    • Process requirements (e.g. validated process parameters, CNC programs, torque values)
    • Procedural requirements (e.g. SOPs, work instructions, inspection plans)
    • Regulatory or customer requirements (e.g. special processes, documentation needs)

    The NCR provides a traceable record of:

    • What went wrong (description of the nonconformance)
    • Where it was found (operation, work center, supplier, lot/serial)
    • When it occurred and when it was detected
    • Who identified and reviewed it
    • Applicable requirements (drawings, specs, SOPs, contracts) that were not met

    NCR vs CAPA and other quality records

    An NCR is not the same as a CAPA, although they are often related:

    • NCR: documents the specific nonconformance event and supports immediate control and disposition.
    • CAPA: addresses underlying systemic causes when nonconformances are significant, recurrent, or high risk.

    Depending on your QMS design and regulatory context, an NCR may:

    • Stand alone with a simple correction and documented disposition, or
    • Feed into a formal CAPA, risk review, or change control workflow if the impact is higher or recurring.

    Why NCRs matter in regulated, long-lifecycle environments

    In aerospace, defense, medical, and similar sectors, NCRs are important because they:

    • Provide traceability of nonconforming material and process deviations across long asset lifecycles.
    • Support impact assessment on delivered vs in-process product, including fielded hardware.
    • Act as evidence during customer and regulatory audits that issues are identified, evaluated, and controlled.
    • Feed into trend analysis, risk management, and continuous improvement (e.g. Pareto of nonconformance types).

    Because of this, NCR processes usually fall under formal change control, with constraints on who can approve dispositions and how records can be modified after approval.

    Typical NCR lifecycle

    While details vary by site and system, a typical NCR lifecycle includes:

    1. Identification: A nonconformance is detected during manufacturing, inspection, testing, or in the field.
    2. Containment: Nonconforming product is segregated or controlled to prevent unintended use.
    3. Documentation: An NCR is opened in the QMS, MES, or other system, capturing required fields (requirements, lot/serial, photos, measurements, etc.).
    4. Evaluation: Quality, engineering, and sometimes customers review technical and regulatory impact (fit, form, function, safety, compliance).
    5. Disposition: An authorized function decides the path for the nonconforming item, such as:
    • Use as is (under controlled justification and approvals)
    • Rework to meet requirements
    • Repair under an approved deviation or concession
    • Scrap and replace
    1. Closure: Actions are completed, records are updated, and the NCR is formally closed.
    2. Follow-up: For significant or recurring issues, the NCR may trigger root cause analysis and CAPA.

    System coexistence and integration realities

    In brownfield environments, NCRs are commonly distributed across multiple systems:

    • QMS or EQMS for the formal NCR record and approvals.
    • MES or LIMS for shop-floor detection, holds, and status.
    • ERP for inventory holds, material status, and cost tracking.
    • PLM or PDM for links to drawings, specifications, and change history.

    Because of integration constraints and legacy systems, the same NCR may be represented differently in each system. Ensuring consistent identifiers, clear master record ownership (usually QMS), and controlled interfaces is critical for traceability during audits and for accurate trend analysis. Full replacement of legacy NCR modules is often difficult due to validation burden, downtime risk, and the need to preserve decades of historical records for long-life products.

    Key constraints and tradeoffs

    When designing or changing NCR processes, typical tradeoffs include:

    • Granularity vs workload: Very detailed NCR classifications improve analytics but increase user effort and may reduce reporting compliance.
    • Speed vs rigor: Fast disposition supports flow, but incomplete evaluation can create downstream risk or rework.
    • Centralization vs flexibility: A single global NCR process aids consistency, but sites with different regulators/customers may need local variants.
    • Automation vs validation: Deep integration (e.g. automatic holds, electronic signatures) improves control but increases validation and change-control overhead.

    None of these design choices guarantee compliance or audit outcomes. Effectiveness depends on how the NCR process is implemented, validated, maintained, and used in daily operations.

  • Can digital systems handle customer-specific NCR requirements?

    Yes, digital systems can handle customer-specific NCR (nonconformance report) requirements, but it is rarely “out of the box” and the effectiveness depends heavily on how requirements are modeled, configured, and validated within your existing landscape.

    What “customer-specific NCR requirements” usually involve

    Customer-driven NCR expectations typically include:

    • Unique data fields (e.g. customer defect codes, contract numbers, key characteristic IDs)
    • Customer-specific dispositions, approval roles, or signoff sequences
    • Different containment and communication timelines by customer or program
    • Specific forms, templates, or PDF exports aligned to customer formats
    • Reporting expectations (e.g. periodic defect dashboards, 8D packages, RCCA evidence)
    • Linkage to customer PO, contract clauses, and flowdown requirements

    Digital systems can support these, but only if they are implemented as explicit rules and data structures rather than tribal knowledge.

    What digital systems typically support this well

    In a regulated, multi-customer environment, customer-specific NCR handling is usually distributed across several systems:

    • QMS / EQMS / NCR modules: Core NCR data model, workflows, approvals, CAPA linkage, audit trail.
    • MES or shop floor system: Defect capture at operation level, holds, rework routing, and traceability to parts, lots, and serial numbers.
    • ERP: Commercial linkages (returns, credits, replacement orders, cost capture).
    • PLM / Document control: Customer-specific specs, quality clauses, and controlled report templates.

    Customer-specific logic often spans these systems, so the question is less “can one system do it” and more “can your stack collectively enforce the rules without gaps.”

    Key capabilities you need for customer-specific NCR handling

    To manage divergent customer expectations reliably, your digital approach typically needs:

    • Configurable data model: Ability to add customer-specific fields and lists (defect codes, disposition options) without breaking validation or reports.
    • Conditional workflows: Routing that can change based on customer, program, part family, or contract (e.g. additional customer approval step, required engineering signoff).
    • Rules engine or logic layer: Business rules like “if customer = X and defect type = Y, require containment within Z hours and notify these roles.”
    • Form and output configurability: Custom NCR report templates per customer, under document control, with version traceability.
    • Traceability and linkage: Tie NCRs to serial numbers, lots, work orders, inspection results, and customer POs so you can satisfy customer audit and recall expectations.
    • Role-based access: Control who can see or edit which NCRs and fields, especially when multiple customers or export-controlled work share the same environment.

    Constraints and common failure modes

    Even where tools are advertised as configurable, several realities limit what is practical:

    • Over-customization: Hard-coded customer logic in one system can become a maintenance burden and complicate upgrades and re-validation.
    • Fragmented implementations: Different plants or programs implementing NCR workflows differently can break corporate reporting and confuse auditors and customers.
    • Inadequate integration: If MES and QMS are loosely coupled, customer-specific rules might apply on paper but not on the shop floor, resulting in late or missing NCRs.
    • Unvalidated changes: In regulated environments, changes to workflows, fields, or logic require impact assessment, regression testing, and documentation. This slows how quickly you can respond to new customer requirements.
    • Legacy constraints: Older MES/QMS platforms may not support conditional workflows or flexible data models, forcing awkward workarounds (free-text fields, attachments, manual checklists).

    These constraints do not make customer-specific NCR handling impossible, but they shape what is realistic without destabilizing your validated environment.

    Brownfield and coexistence considerations

    In most plants, you are layering customer-specific NCR logic onto an existing stack, not starting fresh. Important points:

    • Do not assume a full replacement: Replacing QMS, MES, or ERP solely to handle NCR variants is rarely viable due to validation cost, integration risk, and downtime. Leveraging and extending existing tools is usually safer.
    • Use a hub-and-spoke pattern where needed: Some organizations centralize NCR master data and rules in the QMS, with MES/ERP passing minimal data and IDs rather than duplicating complex logic.
    • Clarify system of record: Define where the legally relevant NCR and customer communication record resides, versus where operators log defects or rework steps.
    • Align with existing change control: Any customer-specific fields, workflows, and templates must go through your standard change control and validation paths to avoid audit exposure.

    Practical implementation approach

    To make customer-specific NCR handling work in digital systems without introducing unnecessary risk:

    1. Capture requirements explicitly: Translate customer quality clauses, contracts, and QMS procedures into structured rules (fields, approvals, SLAs, outputs).
    2. Map rules to systems: Decide which parts of each rule are enforced in QMS, MES, ERP, and document control. Avoid duplicating complex logic in multiple places.
    3. Standardize where possible: Use a common core NCR process with limited, controlled customer-specific variants to keep configuration and validation manageable.
    4. Prototype with one or two key customers: Pilot in a limited scope, then harden the design before rolling out to additional customers or plants.
    5. Validate and document: Treat customer-specific NCR workflows as validated functionality, with test evidence, traceability to requirements, and clear version history.
    6. Monitor and adjust: Track how often customer-specific rules drive rework, delays, or confusion. Simplify or harmonize where you can, with customer alignment.

    Done this way, digital systems can reliably handle customer-specific NCR requirements, but the outcome depends less on the software brochure and more on disciplined configuration, integration, and ongoing governance.

  • What is the difference between rework, repair, and use-as-is dispositions under AS9100?

    Under AS9100, rework, repair, and use-as-is are three different ways to disposition nonconforming product. They are not interchangeable, and each has different implications for design authority, risk, documentation, and customer approval.

    Rework

    Conceptually, rework brings the product back into full conformity with the released design definition (drawings, specifications, bills of material, and approved processes).

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

    Typical characteristics:

    • The nonconformance is eliminated and the part fully meets all drawing requirements and specifications afterward.
    • No change to design intent or functional performance is accepted.
    • Usually follows existing, approved manufacturing or inspection processes, or processes that can be validated and documented as equivalent.
    • Normally does not require customer approval if handled strictly within your approved nonconformance procedures and contractual requirements. Some customers still require notification in specific cases.
    • Traceability is required through NCR / MRB records, but the as-built configuration matches the released design after rework.

    Examples:

    • Re-machining a surface that was out of tolerance until the feature meets the print.
    • Stripping and reapplying a coating to meet thickness or adhesion requirements.
    • Re-running an assembly step using the same work instruction to correct a mis-installed hardware item.

    Key risk if misused: Calling something “rework” when the final condition still deviates from the design (even slightly) can create hidden configuration and conformity issues, especially in serialized or safety-critical hardware.

    Repair

    Conceptually, repair accepts a controlled deviation from the released design and restores functional suitability, but not full design conformity. The product is made usable, but its condition is different from the baseline design definition.

    Typical characteristics:

    • The final condition remains out of strict design specification but is judged acceptable via engineering analysis and defined repair instructions.
    • Usually requires engineering authority (e.g., design engineering) to define and approve the repair.
    • Often requires customer or design-organization approval and issuance of a concession or deviation, depending on contracts and regulatory context.
    • Repair instructions are usually unique or limited-use processes that must be documented, version-controlled, and tied to specific parts/serials.
    • Configuration and traceability records must clearly link the product to the approved repair, including any operational or maintenance limitations.

    Examples:

    • Blending a nick on a rotating part beyond drawing limits but within an engineering-defined damage tolerance envelope.
    • Installing a bushing or oversize fastener to salvage an oversize hole outside drawing requirements.
    • Applying localized weld repair and machining in a way not defined in the original drawing or specification.

    Key risk if misused: Treating repairs as routine production steps without appropriate engineering analysis, concession/deviation control, and traceability can cause long-term reliability issues and undermine airworthiness evidence.

    Use-as-is

    Conceptually, use-as-is accepts the nonconforming condition with no physical change, based on engineering assessment that the nonconformance does not adversely impact fit, form, function, safety, or regulatory requirements.

    Typical characteristics:

    • The product remains as built and does not fully meet design requirements.
    • An engineering or authorized body performs a documented assessment to justify that the deviation is acceptable.
    • Frequently requires formal deviation or concession and, in many aerospace contracts, customer approval.
    • Must be traceable to the specific serial/lot, with clear documentation of the accepted discrepancy.
    • May trigger additional inspection, monitoring, or maintenance instructions, depending on consequence of failure.

    Examples:

    • A minor cosmetic defect on a non-appearance-critical surface where design requirements were conservative, and engineering confirms no impact.
    • A slightly undersize chamfer whose deviation is shown by stress or tolerance analysis to be acceptable.
    • A non-critical dimension out of tolerance on a non-load-bearing feature that does not affect interfaces or assemblies.

    Key risk if misused: Overuse of use-as-is to avoid rework/repair costs can degrade fleet reliability and exposes gaps in design margin understanding, especially if trend data on repeated use-as-is decisions is not analyzed.

    How AS9100 treats these dispositions

    AS9100 does not redefine basic quality terms, but it requires you to control nonconforming outputs, including how you:

    • Identify and segregate nonconforming product.
    • Define and enforce authorized dispositions (rework, repair, use-as-is, scrap, etc.).
    • Obtain necessary approvals, including customer and design-authority approvals when required.
    • Maintain records to demonstrate traceability, risk assessment, and conformity to approved dispositions.

    The standard also expects that where the product does not meet requirements specified by the customer or applicable regulations, you will not repair or use-as-is without prior authorization from the applicable authority (e.g., customer, regulatory holder, design organization), in line with contracts and regulatory constraints.

    Practical decision boundaries

    A simple way to distinguish the three in daily operations is:

    • Rework: After action, the product is indistinguishable (by requirements) from fully conforming hardware. No change to specification or drawing is needed.
    • Repair: You modify the product so it does not meet the original specification but is made fit for use by an approved engineering change or concession.
    • Use-as-is: You do nothing to the product; you accept the deviation based on documented engineering and, where applicable, customer approval.

    In a robust QMS, these boundaries are codified in procedures, MRB charters, and training, with clear rules for when customer or design-authority involvement is mandatory.

    Dependencies on your environment and systems

    How these dispositions actually work in your plant depends heavily on:

    • Design authority and contracts: Whether you hold design approval or are a build-to-print supplier strongly affects when you can approve repair or use-as-is versus when customer authorization is required.
    • QMS maturity: Weak NCR / MRB processes often blur the line between rework and repair, or treat use-as-is as an informal shortcut instead of a controlled concession.
    • System landscape: In brownfield environments with mixed ERP, MES, PLM, and QMS tools, nonconformance dispositions often live in multiple systems. Misalignment can cause:
    • ERP showing a part as conforming while PLM or QMS records a repair or use-as-is concession.
    • Maintenance and MRO systems not seeing repair-specific limitations because NCR data is not integrated.
    • Inconsistent serial-level genealogy, making it hard to answer audit questions about which units were repaired or accepted use-as-is.

    Because replacing core QMS, MES, or PLM systems in aerospace can be highly disruptive and expensive, many plants overlay digital workflows on existing tools to standardize how rework, repair, and use-as-is are captured and approved, instead of attempting a full rip-and-replace.

    Common pitfalls and controls

    Some recurrent issues and mitigating practices include:

    • Mislabeling repairs as rework: Control with MRB checklists that explicitly ask whether the final state meets all drawing and specification requirements.
    • Informal use-as-is decisions: Require written engineering justification and, where applicable, evidence of customer approval before closing the NCR.
    • Poor traceability: Ensure serial/lot tracking links to NCRs and concessions so audit trails can show which units were reworked, repaired, or accepted use-as-is.
    • No feedback into design and process improvement: Analyze trends in rework, repair, and use-as-is to feed corrective actions, design changes, and process improvements.

    In all cases, the structure and rigor of your dispositions should be proportionate to risk, regulatory expectations, and customer contracts, not just cost and schedule pressure.

  • How do special processes like heat treatment and NDT influence scrap rates?

    Special processes such as heat treatment and non-destructive testing (NDT) affect scrap rates in two different but related ways:

    • They can create or worsen defects that drive scrap (especially heat treatment).
    • They often reveal defects late in the route, so each failure carries a high scrap cost (especially NDT).

    How heat treatment drives scrap

    Heat treatment is both a transformation step and a risk amplifier. It changes material properties and can introduce nonconformances that are difficult or impossible to rework within spec. Typical scrap drivers include:

    In practice, this connects to scrap and rework reduction when teams need to turn the answer into repeatable execution habits.

    • Distortion and dimensional out-of-tolerance: Warping, growth, or shrinkage can push critical features outside tolerance. This is common for long, thin, or asymmetrical parts and assemblies. Poor fixturing, inconsistent load configuration, or unvalidated recipes increase risk.
    • Nonconforming hardness or strength: Incorrect soak time, temperature control issues, quench delay, or furnace uniformity problems can lead to under- or over-hardening. Often this cannot be fully corrected without violating route or specification limits, especially in regulated sectors.
    • Microstructural defects: Improper heat treat can cause undesirable phases, grain growth, decarburization, or case depth issues. These are typically caught via metallography or hardness mapping and usually result in full-part scrap.
    • Surface and quench-related damage: Cracking, quench burns, scaling, and intergranular attack can convert high-value, nearly finished parts into scrap late in the process.
    • Batch effects: A single furnace load, if processed out of spec, can simultaneously scrap a large group of parts. This magnifies the impact of any control or operator error.

    The net effect is that heat treatment tends to increase the probability of scrap per part and, when something goes wrong, can drive large batch scrap events. Because it usually happens late in the route, the financial and schedule impact per scrapped part is high.

    How NDT influences scrap

    NDT (e.g., radiography, ultrasonic testing, penetrant, magnetic particle, eddy current) generally does not create defects, but it does change when and how you see them:

    • Late discovery of defects: In many routes, NDT is scheduled near final inspection or post-heat treat. Any defect detected at this point often leads to scrap after significant value has already been added.
    • Increased detection sensitivity: A more capable or stricter NDT process will identify defects that previously passed. Apparent scrap rates may rise, even though the underlying process quality is unchanged. This is often misinterpreted as “NDT is causing scrap” when it is actually exposing upstream issues.
    • Operator and interpretation variability: Borderline indications and interpretation differences can push parts into scrap instead of rework. Inconsistent techniques, lighting, calibration, and qualification can change the “effective” scrap rate over time.
    • Specification creep: Customer or internal demands for tighter acceptance criteria, more coverage, or additional NDT methods can raise the number of nonconforming findings, again shifting apparent scrap rates.

    Practically, NDT controls the timing and visibility of scrap. Where NDT is the final gate, it concentrates scrap at the most expensive point in the route and can expose systemic issues in casting, welding, forging, machining, or heat treatment.

    Interactions between heat treatment and NDT

    The impact of these processes on scrap rates is often coupled:

    • Heat treatment makes latent issues visible: Quenching or thermal cycling can open up microcracks or amplify defects formed in upstream steps. NDT after heat treat will then show an apparent spike in defects, even though the root cause lies earlier.
    • NDT placement changes where scrap shows up: If NDT is moved earlier (e.g., pre-heat treat), some defective parts are removed before expensive downstream processing. If it is only post-heat treat, the same defects convert into high-cost scrap.
    • Feedback loops often break: In brownfield environments, NDT findings are not always tightly linked back to furnace loads, recipes, fixtures, or heat treat equipment conditions. Without that feedback and traceability, the same special-process issues quietly drive repeat scrap.

    Key factors that determine actual scrap impact

    The true influence of heat treatment and NDT on scrap rates varies significantly by plant, product, and regulatory context. It depends on:

    • Process capability and validation: High-capability, well-validated special processes (qualified procedures, equipment, and personnel) typically have lower scrap, but require substantial up-front qualification, periodic requalification, and disciplined change control.
    • Fixture and load design: Stable, validated fixturing and load patterns reduce distortion and variability in heat treatment. Poor fixture design can dominate scrap drivers even when furnace controls are nominally in spec.
    • Route design and NDT placement: Where NDT sits in the routing directly affects the cost per scrap event. Multiple NDT gates or in-process checks might reduce late scrap but add capacity and cost burdens.
    • Integration and data quality: In mixed MES/ERP/QMS environments, the ability to link NDT results, scrap records, and special-process parameters (load, recipe, equipment, operator, calibration status) is often limited. This weakens root cause analysis and slows scrap reduction.
    • Rework allowances and specifications: Some heat treat and NDT-related nonconformances can be reworked (e.g., re-heat treat within limits, local repair plus re-test), but regulated sectors often constrain this. The tighter the specification and rework rules, the higher the scrap share.
    • Outsourcing vs in-house: External heat treaters or NDT providers add logistics time, queueing, and communication gaps. Scrap can be harder to trace back to specific process conditions without robust data exchange and supplier controls.

    Typical scrap patterns in regulated, long-lifecycle environments

    In aerospace, defense, medical devices, and similar sectors, several patterns are common:

    • Scrap spikes tied to special-process changes: New heat treat recipes, furnace repairs, or NDT technique changes can cause temporary spikes in scrap. Inadequate revalidation and change control make this worse.
    • Chronic, low-level special-process scrap: Even well-run operations see a persistent background level of scrap linked to distortion, hardness variation, or NDT indications. Eliminating this entirely is rarely realistic; the focus is on reducing and containing it.
    • High-cost late scrap events: A single furnace excursion or systematic NDT mis-setup can affect many high-value parts. Recovery is often limited by specification and certification requirements, so the financial impact is disproportional.

    Full replacement of existing heat treat or NDT systems is rarely a quick solution to scrap issues in these environments. New furnaces or NDT platforms typically require significant qualification, correlation, and validation effort, plus downtime and integration risk. Many organizations instead focus on improving recipes, fixturing, calibration, data capture, and feedback loops on their existing assets.

    Practical ways to manage scrap from heat treatment and NDT

    To influence scrap rates in a controlled way, many plants focus on:

    • Improving traceability between part genealogy, furnace loads, recipes, NDT results, and scrap records, even across mixed MES/ERP/QMS and external processors.
    • Analyzing scrap by special-process context, not just part number, so that patterns by furnace, operator, shift, or NDT technique become visible.
    • Adjusting route design to pull at least some NDT earlier in the process where feasible, balancing cost, capacity, and regulatory constraints.
    • Strengthening change control and revalidation for any modifications to heat treat parameters, fixtures, NDT techniques, or acceptance criteria.
    • Targeted capability improvements (e.g., better fixturing for distortion-prone parts, refined quench practices, or more consistent NDT setups) driven by structured root cause analysis rather than ad hoc fixes.

    The net effect is that special processes themselves may not be the sole root cause of scrap, but they are critical leverage points. Their control, validation, and integration with upstream and downstream steps strongly influence both the quantity of scrap and its timing and cost.

  • What is MES and QMS?

    MES and QMS are two different but closely related categories of systems used to manage manufacturing and quality in regulated environments.

    What is an MES?

    A Manufacturing Execution System (MES) is software that coordinates, monitors, and records production activities on the shop floor. In regulated, long-lifecycle operations it typically focuses on:

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

    • Order execution and routing: Translating production orders into operations, work centers, and sequences.
    • Work instructions and data collection: Presenting the right instructions, capturing process parameters, measurements, and operator entries.
    • Traceability: Tracking material lots, components, and process history for each unit or batch.
    • WIP visibility: Real-time status of work-in-progress, bottlenecks, and equipment utilization.
    • Enforcement: Applying basic rules such as required checks, signatures, and holds before proceeding.

    The exact scope varies by vendor and plant. In many brownfield environments, parts of “MES” functionality also live in legacy systems, custom tools, or spreadsheets. Replacing those outright can be difficult due to validation requirements, downtime risk, and complex integrations with ERP, equipment, and test systems.

    What is a QMS?

    A Quality Management System (QMS) governs how an organization plans, executes, documents, and improves quality-related activities. In regulated manufacturing, a QMS is usually a combination of:

    • Processes and procedures: How you handle nonconformances, CAPA, change control, document control, training, and audits.
    • Software tools: Often called eQMS, providing workflows and records for NCs, CAPA, complaints, audits, and document control.

    Typical QMS software functions include:

    • Nonconformance and deviation management.
    • CAPA planning, execution, effectiveness checks, and evidence.
    • Document control and version governance for SOPs, work instructions, and forms.
    • Change control, risk assessments, and approvals.
    • Audit planning, findings, and responses.
    • Training records and qualification tracking.

    The QMS defines how quality is managed overall; MES is one of the operational systems that must comply with and provide evidence to that QMS.

    How do MES and QMS relate in practice?

    In real plants, MES and QMS are separate but intertwined:

    • MES is closer to the line: It captures production data and enforces some checks during execution.
    • QMS is cross-functional: It manages quality events, documents, risk, and improvements across engineering, operations, supply chain, and suppliers.
    • Data flows between them: Nonconformances detected in MES often need to be escalated into QMS; QMS changes (for example, updated procedures) must be reflected in MES content and configuration.

    Because most environments are brownfield, you often see:

    • Multiple MES-like systems for different lines, sites, or product families.
    • A mix of enterprise QMS and local point tools or legacy databases.
    • Manual bridges (exports, emails, spreadsheets) where integration is incomplete.

    These coexistence patterns are common because full system replacement can trigger extensive revalidation, retraining, and integration work, with significant downtime and regulatory risk.

    Can one system replace both MES and QMS?

    Some vendors market platforms that claim to handle both MES and QMS. In regulated, high-criticality manufacturing this is rarely deployed as a full replacement for all MES and QMS functions across the plant network, because:

    • Operational requirements on the line (latency, equipment interfaces, scheduling) differ from enterprise quality workflows.
    • Qualification and validation burdens increase significantly for a single monolithic system that touches everything.
    • Legacy integrations with ERP, PLM, LIMS, and test systems can be extensive and fragile.
    • Changing out proven QMS processes and records carries audit and continuity risk.

    More commonly, organizations:

    • Modernize parts of MES in stages, line by line or site by site.
    • Introduce or upgrade eQMS while maintaining certain legacy or local tools under defined controls.
    • Focus on robust, validated integration and clear ownership of which system is the system of record for each type of data.

    Key dependencies and constraints

    How MES and QMS work for your plant depends heavily on:

    • Process maturity: If SOPs, routings, and quality processes are inconsistent, MES/QMS will mirror that inconsistency.
    • Integration quality: Poor integrations lead to duplicate data entry, gaps in traceability, and audit exposure.
    • Validation and change control: Any MES or QMS changes in regulated environments typically require documented impact assessment, testing, approvals, and controlled rollout.
    • Data readiness: Clean master data (materials, BOMs, routings, specs) is critical for reliable MES execution and meaningful QMS metrics.

    MES and QMS are enabling systems, not guarantees of compliance or quality. Their effectiveness depends on disciplined processes, clear ownership, and sustained investment in maintenance, validation, and integration.

  • Is ISO 9001 part of the ISO 9000 family of standards?

    Yes. ISO 9001 is one of the main standards in the ISO 9000 family of quality management standards.

    The ISO 9000 family includes multiple documents that work together. In broad terms:

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

    • ISO 9000 describes the fundamentals and vocabulary of quality management systems (QMS).
    • ISO 9001 specifies the requirements for a QMS and is the standard that organizations can choose to be certified against.
    • Other related standards (such as guidance documents and sector-specific adaptations) build on the same principles.

    In regulated and aerospace-grade manufacturing environments, ISO 9001 is typically used alongside sector standards (for example, AS9100, which incorporates ISO 9001 requirements) and internal procedures. These are then implemented within existing MES, ERP, PLM, and QMS architectures. None of the ISO 9000 family standards by themselves ensure compliance or audit outcomes; their effectiveness depends on how well they are interpreted, implemented, validated, and maintained over the lifecycle of your systems and processes.

  • What are the different types of non conformance?

    There is no single universal list of nonconformance (NC) types. In regulated manufacturing, the “types” are usually defined in your QMS so that people classify issues consistently, set the right level of response, and maintain traceability for audits. That said, most organizations converge on a similar set of distinctions.

    1. By severity or impact

    Severity levels are typically used to prioritize response and determine whether full CAPA is required. Common patterns are:

    • Critical nonconformance: Has a reasonable potential to affect safety, regulatory compliance, airworthiness/fit-for-purpose, or cause field failure. Often triggers product hold, regulatory/authority notification (where applicable), and formal CAPA. Examples: wrong material on a flight-critical part, unapproved process deviation on a special process, missing mandatory inspection.
    • Major nonconformance: Does not pose an immediate safety risk, but violates a requirement that can affect performance, reliability, or compliance if not corrected. Typically triggers containment and at least a documented root cause analysis. Examples: out-of-tolerance dimensions, incomplete inspection records, failed in-process test.
    • Minor nonconformance: Low impact, often cosmetic or easily reworked without affecting function or compliance. Usually handled via local correction with documented justification. Examples: minor cosmetic defect within customer-acceptable criteria, small paperwork error with clear evidence that work was done correctly.

    The detailed thresholds between critical, major, and minor must be defined in your QMS, trained, and applied consistently. Inconsistent severity assignment is a common audit finding.

    2. By what is nonconforming

    Separating NCs by object helps you understand where the system is failing:

    • Product nonconformance: The manufactured item does not meet specification or drawing requirements. Examples: dimensional out-of-tolerance, wrong revision, incorrect material or special process, missing feature, test failure. These usually link directly to material review and disposition (scrap, rework, use-as-is with justification).
    • Process nonconformance: The process was not followed as defined, regardless of whether the final product passed inspection. Examples: skipped or out-of-sequence operation, use of uncalibrated equipment, unapproved process change, missing in-process check. Even if product looks acceptable, this is still a nonconformance in regulated environments.
    • Documentation / data nonconformance: Required records, approvals, or traceability data are missing, incorrect, or incomplete. Examples: missing signatures, wrong drawing revision used on traveler, incomplete inspection records, mislabeling, incomplete device history record or build history.
    • Systemic / QMS nonconformance: A failure of the quality management system itself, often identified during internal or external audits. Examples: procedure not aligned with a regulatory requirement, lack of required training program, missing process validation, ineffective CAPA system.

    In a mature system, a single event may generate multiple linked NCs (for product, process, and documentation) so that each aspect is treated and traceable.

    3. By source or origin

    Understanding where nonconformances originate is important for supplier management and internal improvement:

    • Internal nonconformance: Detected within your own operations (in-process inspection, final inspection, internal audit, operator self-report). These are usually the majority in a well-controlled system, because issues are caught before shipping.
    • Supplier nonconformance: Nonconforming material or services from external partners, including special process providers. Typically managed through an incoming inspection or receiving process, a supplier NC process, and possibly supplier corrective action requests (SCARs).
    • Customer / field nonconformance: Issues detected by the customer or in service/use. Includes customer complaints, returns, escapes, and regulatory reports where applicable. These often carry higher risk and scrutiny, and frequently trigger formal CAPA and cross-functional review.

    Many plants track these separately (e.g., internal NC, supplier NC, customer NC) for reporting and for different escalation rules.

    4. By frequency and pattern

    NCs can also be categorized based on how they behave over time:

    • Isolated / sporadic nonconformance: A rare or one-off event with no clear trend. Often handled with local correction or contained corrective actions, provided risk is low and recurrence is unlikely.
    • Recurring nonconformance: Same or similar NC appears multiple times, indicating that previous fixes were not effective. Typically requires deeper root cause analysis and systemic corrective action.
    • Systemic nonconformance: Indicates a broad weakness in the QMS or process design, not just execution. Often discovered via trend analysis, internal audits, or repeated customer findings. These usually feed into your CAPA program.

    Trend detection depends heavily on how consistently NCs are logged and coded. In brownfield environments with multiple systems (MES, QMS, spreadsheets), incomplete or fragmented data can hide systemic issues unless integration and data governance are addressed.

    5. By timing in the value chain

    Some organizations distinguish NCs by where in the lifecycle they are detected:

    • Incoming / receiving nonconformance: Detected when materials, components, or documentation arrive from suppliers.
    • In-process nonconformance: Detected during manufacturing or assembly operations.
    • Final inspection / test nonconformance: Detected at the end of the manufacturing process, before shipment or release.
    • Post-delivery / field nonconformance: Detected after shipment, in service, or at the customer site.

    This classification helps target containment and improve early detection. It also feeds cost-of-poor-quality (COPQ) analysis, since later discovery usually has a higher cost and risk impact.

    6. Special regulatory or customer-specific types

    In highly regulated or customer-driven environments, additional categories may be required:

    • Regulatory nonconformance: Direct violation of a regulatory or standard requirement (e.g., missing required validation, failure to follow mandated procedures). These often have specific reporting and corrective-action expectations.
    • Customer-specific nonconformance categories: Many aerospace and medical customers specify their own NC categories and codes. Your internal types then need to map to customer-required categories for reporting and concessions/deviation requests.
    • Configuration/traceability nonconformance: Incorrect serialization, genealogy, or configuration state, especially where as-built must match as-designed and as-certified. Even if physical product is correct, misaligned configuration or genealogy is often treated as a nonconformance in its own right.

    These categories are highly dependent on your product type, regulatory regime, and key customer contracts.

    7. Practical considerations in brownfield environments

    In mixed-system, long-lifecycle plants, nonconformance types often drift over time because of:

    • Multiple QMS/MES/ERP instances with different NC codes and workflows
    • Legacy paper processes coexisting with digital systems
    • Customer-specific portals and coding schemes for supplier NCs

    Before rationalizing NC types, it is important to:

    • Define a clear, controlled list of NC types and severities in your governing procedures.
    • Map old codes and system fields to the new controlled list instead of attempting a disruptive, big-bang replacement of existing systems.
    • Validate any changes to NC workflows and coding logic in your QMS/MES, with appropriate change control and training.

    Full replacement of legacy NC systems purely for standardization often fails in regulated contexts because of qualification burden, downtime risk, integration complexity, and the cost of revalidating processes and retraining personnel. A staged approach (harmonized definitions, code mapping, incremental system changes) is usually more realistic.

    Key point

    The “different types of nonconformance” in your plant should be:

    • Explicitly defined and documented in your QMS.
    • Aligned with severity, object (product/process/document/system), and source.
    • Consistently applied across all systems and sites, with traceability to customer and regulatory expectations.

    Without that discipline, NC data becomes hard to trust, which weakens trend analysis, CAPA effectiveness, and audit readiness.

  • How quickly should suppliers respond to aerospace non conformances?

    There is no single aerospace-wide rule for how fast suppliers must respond to nonconformances. Response timing is usually controlled by:

    • Purchase order (PO) terms and conditions
    • Customer quality clauses and supplier manuals
    • Program- or platform-specific requirements (e.g., flight safety parts)
    • Regulatory context (e.g., EASA/FAA expectations for safety impact issues)

    Typical response expectations in aerospace

    While details vary by OEM and tier, common expectations look roughly like:

    • Immediate / same-day: Acknowledge receipt of the nonconformance or SCAR and confirm that investigation has started. For serious or safety-related issues, this may mean within a few business hours.
    • Within 24 hours (often specified): Provide initial containment status:
      • Confirm whether additional lots, serial numbers, or shipments are affected
      • Stop-ship / stop-use actions where appropriate
      • Quarantine of suspect material and WIP
      • Any immediate mitigations at the supplier and at sub-tier suppliers
    • Within 3–10 business days: Submit a preliminary investigation or 8D/5-Why summary, with:
      • Problem statement and scope
      • Interim corrective actions and verification
      • Early assessment of suspected root causes and contributing factors
    • Within 10–30 days (sometimes longer for complex issues): Provide the full root cause analysis and final corrective action plan, including:
      • Verified root cause(s)
      • Permanent corrective and preventive actions
      • Evidence of implementation and effectiveness checks
      • Updates to control plans, FMEAs, work instructions, and training where needed

    These timeframes are typical patterns, not guarantees. You must use the durations contractually specified by your customer.

    Risk and severity drive response speed

    Response timing should scale with risk:

    • Safety-critical / flight safety / critical characteristics: Expect very short windows for containment and communication (hours, not days). Customers may require immediate joint reviews and more frequent status updates.
    • Major nonconformances affecting form, fit, function, or airworthiness: Rapid containment, short timelines for preliminary analysis, and formal approval before rework or use-as-is.
    • Minor nonconformances (e.g., certain cosmetic issues): Still require timely response, but the customer may allow more time for full root cause and corrective action evidence.

    In regulated aerospace environments, fast and transparent communication is often more critical than having fully completed analysis on day one.

    What “respond” should mean in practice

    When customers ask how fast you will “respond,” they typically mean more than just acknowledging an email. A robust response process usually covers:

    • Acknowledgment: Confirm receipt of the nonconformance or SCAR, responsible owner, and expected next update.
    • Containment confirmation: Documented actions to prevent further escapes, including sub-tier checks if relevant.
    • Data and traceability review: Lots, batches, serial numbers, operators, machines, programs, tools, and inspection records checked and referenced.
    • Joint risk assessment: Early discussion with the customer if the issue may affect in-service hardware, certification status, or field reliability.
    • Structured problem solving: Use of agreed methods (8D, 5-Why, etc.) with clear ownership and milestones.

    A fast but superficial response that misses scope or misidentifies root cause usually causes more rework and customer scrutiny later.

    Brownfield reality: systems and process constraints

    Response speed is heavily dependent on the maturity and connectivity of your systems and processes:

    • Legacy QMS/MES/ERP: When nonconformance, supplier, and manufacturing data live in separate, partially manual systems, even basic containment scoping can take days.
    • Traceability depth: Incomplete or paper-based traceability extends the time to confirm lot, serial, and sub-tier impact. This is particularly acute in long-lifecycle aerospace programs where records span decades.
    • Validation and change control: Rapid fixes that touch manufacturing processes, software, or inspection methods may require formal validation, approvals, and documented change control, which add time.
    • Limited downtime windows: Implementing corrective actions on qualified lines or special processes often must be scheduled around constrained downtime and requalification requirements.

    These constraints do not excuse slow response, but they shape what is realistically achievable. It is better to commit to a realistic, sustainable SLA and meet it consistently than to overpromise based on best-case scenarios.

    Practical guidance for setting and meeting response times

    To define and achieve credible response commitments:

    • Align expectations up front: Clarify with customers how they define “response,” what time clocks apply (receipt vs. acknowledgment), and how risk categories change timing.
    • Standardize SLAs by severity: For example: acknowledge within 4 business hours, containment status within 24 hours, preliminary analysis in 5 days, final in 20 days, unless otherwise contractually defined.
    • Build a cross-functional rapid response team: Ensure engineering, quality, operations, supply chain, and IT roles are predefined, with alternates for off-shifts and holidays.
    • Use existing systems, not only email: Drive NC/SCAR workflows through your QMS/MES or dedicated NCR/CAPA tools, with clear task ownership and due dates.
    • Instrument the process: Track actual response times against SLAs, and analyze chronic delays (e.g., data access, sub-tier responsiveness, lab capacity).
    • Plan for sub-tier lag: For outside processors and material suppliers, define their response times contractually so you are not late with your customer while waiting for their data.

    Why “instant” root cause is rarely realistic

    In aerospace, especially in complex, qualified processes, full root cause analysis often requires:

    • Review of historical build data and inspection results
    • Physical teardown or lab analysis (NDT, metallurgical exams, etc.)
    • Assessment of design, process capability, and special process parameters
    • Coordination across multiple plants and sub-tier suppliers

    These activities do not align with 24-hour expectations. This is why many customers explicitly separate containment timing (very fast) from final root cause and corrective action timing (longer but structured and well-documented).

    How this plays with long lifecycle and qualification constraints

    In long-lifecycle aerospace programs, nonconformance responses often interact with:

    • Existing product qualifications and frozen processes that cannot be changed quickly
    • Large installed bases of parts already flying or in maintenance pipelines
    • Legacy documentation and data formats that slow down investigation

    Attempting to “solve” response timeliness solely by replacing core QMS/MES/ERP systems is risky and often fails due to qualification burden, validation cost, downtime risk, and integration complexity. Incremental improvements to traceability, NC workflows, and evidence capture within the existing stack are usually more realistic and defensible.

    Bottom line

    Suppliers should be ready to:

    • Acknowledge aerospace nonconformances within hours to one business day
    • Provide containment status within roughly 24 hours for most issues
    • Deliver preliminary investigation and interim actions within several days
    • Complete full root cause and corrective actions within 10–30 days, aligned with contractual and risk requirements

    The exact numbers must come from your customer requirements and your validated capability. What matters most is a disciplined, traceable process, clear communication, and realistic, consistently met commitments.