Connect981 – Content Dev

RSC Colour: Red

  • Non-conformance (NCR)

    Non-conformance (NCR) commonly refers to a documented instance where a product, process, service, or system does not meet defined requirements. These requirements can come from drawings, specifications, contracts, procedures, work instructions, standards, or regulatory obligations.

    In industrial and regulated manufacturing environments, a non-conformance is usually captured on a Non-Conformance Report or Non-Conformance Record, often abbreviated as NCR. The NCR provides formal traceability of the issue, its scope, and the actions taken.

    What a non-conformance includes

    Depending on the quality system, a non-conformance typically includes:

    • Identification of the non-conforming item or process (part number, serial/lot number, work order, process step)
    • Description of the requirement that was not met (tolerance, spec clause, procedure step)
    • Actual condition found (dimension out of tolerance, missing operation, wrong material, incomplete record)
    • Classification (e.g., minor/major, internal/external, critical/high/low risk)
    • Containment and disposition (scrap, rework, repair, use-as-is with deviation/concession, return to supplier)
    • Responsibilities and approvals (operators, inspectors, MRB, quality, engineering, customer if required)
    • Links to related records (CAPA, rework instructions, concessions, test results, cost-of-poor-quality data)

    Non-conformances may arise from:

    • Non-conforming product (dimensions, materials, cosmetic or functional defects)
    • Non-conforming process (unqualified equipment, unapproved method, skipped or out-of-sequence operation)
    • Non-conforming documentation or data (missing signatures, incorrect revision, incomplete traceability)
    • Non-conforming system behavior (procedures not followed, QMS process failing to meet its own criteria)

    Operational meaning in manufacturing systems

    In practice, non-conformances are managed through coordinated workflows across OT/IT systems such as MES, ERP, PLM, and QMS. Typical operational aspects include:

    • Detection and logging of the issue at inspection, in-process checks, receiving, or test (often by operators, inspectors, or automated gauges)
    • Digital NCR creation within MES or QMS, capturing data automatically from work orders, routings, travelers, and equipment
    • Segregation and containment to prevent unintended use or shipment of suspect product (quarantine locations, quality holds)
    • Material Review Board (MRB) or equivalent decision to determine disposition and required approvals
    • Execution of disposition (rework routing, repair instructions, scrap transactions in ERP, supplier return)
    • Cost tracking as part of cost of poor quality (COPQ), including scrap, rework labor, delays, and external impacts
    • Linkage to corrective and preventive action (CAPA) or 8D/RCCA when systemic causes are identified

    Cost and performance context

    Non-conformances are a core input to quality and operational performance analysis. Organizations often:

    • Classify NCRs by source (internal, supplier, customer/field), defect type, product family, process, or supplier
    • Use NCR data to estimate cost of poor quality (COPQ), including scrap, rework, line stoppages, schedule impact, and external failures
    • Feed NCR metrics into dashboards for yield, defect rates, and continuous improvement programs

    Common confusion

    • Non-conformance vs. defect: A defect is the actual flaw or non-fulfillment of a requirement in a product or service. A non-conformance usually refers to the documented event and record within the quality system that a defect (or process/system failure) occurred.
    • Non-conformance vs. CAPA: A non-conformance documents that something did not meet requirements and how it was contained and dispositioned. CAPA focuses on investigating causes and implementing corrective and preventive actions, often for recurring or high-risk non-conformances.
    • NCR vs. deviation/concession: An NCR records non-conforming conditions. A deviation or concession is an authorized decision to accept a non-conforming condition under defined terms (for example, customer-approved use-as-is) and may be linked to one or more NCRs.

    Use in regulated and aerospace contexts

    In aerospace and other highly regulated sectors, non-conformances and NCR workflows are tightly controlled and auditable. They are typically integrated with:

    • AS9100-based quality management systems
    • AS9102 First Article Inspection (FAI) records, where FAI findings can trigger NCRs
    • Traceability and genealogy requirements linking NCRs to serial numbers, lots, and configurations
    • Supplier management processes for supplier NCRs and returns

    Digital NCR management in MES/QMS/ERP helps maintain consistent records, link issues to work orders and serialized parts, and support audits and continuous improvement without implying any specific compliance outcome.

  • cost of poor quality

    Core meaning

    Cost of poor quality (COPQ) commonly refers to the total costs a business incurs because products, processes, or services do not meet specified quality requirements. It aggregates the measurable financial impact of defects, errors, and nonconformances across the value chain.

    In industrial and regulated manufacturing environments, COPQ is usually tracked as a distinct component of overall cost of quality, focusing on what is spent due to quality failures rather than on prevention or appraisal activities.

    Typical components

    COPQ is often structured into categories such as:

    – **Internal failure costs**
    Costs incurred before the product leaves the plant or is released, for example:
    – Scrap and wasted materials
    – Rework and repair labor
    – Yield losses and retesting
    – Line stoppages and changeovers caused by defects

    – **External failure costs**
    Costs incurred after delivery or release, for example:
    – Warranty and field repair costs
    – Returns, replacements, and recalls
    – Concessions, credits, and penalties to customers
    – Investigation, containment, and corrective actions in the field

    Depending on the organization, COPQ may also include:

    – **Schedule-related impacts**, such as expediting, overtime, or liquidated damages linked to quality issues.
    – **Logistics and handling**, such as re‑shipping, sorting, or segregating suspect material.
    – **Administrative effort**, such as extra inspections, deviations, and nonconformance processing.

    Intangible or harder-to-quantify effects (brand damage, opportunity cost) are sometimes discussed alongside COPQ but are not always included in formal calculations.

    Use in manufacturing workflows and systems

    In operational practice, COPQ is:

    – **Measured using production and quality data** from MES, QMS, ERP, and PLM systems, tying specific nonconformances and rework to material, labor, and overhead costs.
    – **Tracked by product, line, plant, supplier, or program** to understand where quality failures are most costly.
    – **Linked to events and traceability records**, such as deviations, nonconformance reports, CAPAs, concessions, or rework orders.
    – **Aggregated into key metrics**, such as COPQ per unit, per batch, or as a percentage of sales or manufacturing cost.

    In regulated industries, COPQ calculations typically rely on validated data sources and traceable event histories to support internal reporting, management reviews, and operational decision-making.

    Boundaries and what COPQ is not

    – **Not the same as total cost of quality (CoQ)**:
    COPQ focuses on failure-related costs. Total cost of quality usually includes prevention and appraisal costs in addition to failure costs.

    – **Not limited to scrap and rework**:
    While scrap and rework are major elements, COPQ also encompasses downstream effects like warranty work, penalties, and schedule impacts attributable to quality issues.

    – **Not an official accounting standard**:
    COPQ is a management and operational metric. Its precise definition and calculation rules may vary between organizations and should be explicitly documented internally.

    Common confusion and misuse

    – **COPQ vs. nonconformance count**:
    A high number of defects does not always translate into high COPQ if their economic impact is small. COPQ quantifies financial impact, not just defect frequency.

    – **COPQ vs. yield loss only**:
    Yield loss is one component of COPQ. Focusing only on scrap underestimates the broader cost of poor quality.

    – **Including prevention activities**:
    Activities like training, FMEAs, and process capability studies are typically classified as prevention costs, not COPQ, even though they are quality-related.

    Site context: COPQ in MES and industrial operations

    Within manufacturing execution systems (MES) and integrated OT/IT environments, cost of poor quality is commonly:

    – Calculated by combining **event data** (e.g., nonconformances, rework orders, NFF findings, yield losses) with **cost data** from ERP or cost accounting.
    – Used as a key **operations-intelligence metric** for aerospace and other regulated industries, where rework, NFF (no-fault-found) investigations, and schedule-driven penalties can be significant.
    – Segmented by **asset, program, configuration, or supplier**, leveraging traceability captured in MES, QMS, and PLM to attribute COPQ to specific causes or value-stream segments.

    These uses do not change the fundamental definition of COPQ; they illustrate how the concept is implemented in data-driven manufacturing environments.

  • Can I reuse scrap pattern models across different plants or programs?

    Yes, but only with qualification and local validation. A scrap pattern model trained in one plant or program is rarely portable without adjustment.

    The main reason is that scrap behavior is usually influenced by local conditions: machine configuration, tooling wear, routing differences, material lots, inspection methods, operator practices, shift patterns, rework rules, and how nonconformance data is coded. Even when two plants make the same part family, the data-generating process may not be equivalent.

    If those differences are not addressed, the model may still produce scores, but the predictions can be misleading. In practice, that means false alarms, missed scrap drivers, poor trust from operations, and decisions based on patterns that do not hold in the target environment.

    What usually transfers well

    • Feature engineering logic, such as how you derive setup-to-run transitions, lot-level context, environmental windows, or machine state sequences.

    • Modeling approach, such as classification versus anomaly detection, if the target process has similar failure mechanisms and enough labeled history.

    • Data pipelines, governance patterns, and review workflows for traceability, approvals, and change control.

    • Shared failure taxonomies, but only if defect and scrap codes are actually standardized across sites.

    What usually does not transfer cleanly

    • Model thresholds and alert logic.

    • Importance rankings for input variables.

    • Direct interpretation of defect classes when local coding practices differ.

    • Performance claims from one plant to another.

    Conditions for reuse

    Reuse is most defensible when the source and target share most of the following:

    • Comparable product families, materials, tolerances, and process steps

    • Similar equipment types, maintenance condition, and control logic

    • Consistent definitions for scrap, rework, concession, and yield loss

    • Stable routings and work instruction governance

    • Enough target-site history to test drift and recalibrate the model

    • Reliable integration between MES, ERP, QMS, historian, and machine data sources

    If those conditions are weak, you are not really reusing a model. You are reusing a starting point.

    Recommended approach in brownfield environments

    In most regulated manufacturing environments, the practical path is not a global model pushed unchanged to every site. It is a controlled template approach:

    1. Standardize core data definitions where possible.

    2. Map local tags, event codes, routing identifiers, and defect codes.

    3. Retrain or fine-tune using target-site data.

    4. Validate performance locally against known scrap events.

    5. Run in parallel before using outputs for operational decisions.

    6. Version the model, inputs, thresholds, and approval history.

    That is slower than copying one model everywhere, but it is usually more credible and more sustainable.

    Full replacement of existing MES, QMS, or data collection systems just to make model reuse easier is often a poor strategy in long-lifecycle regulated operations. The qualification burden, validation effort, downtime risk, integration complexity, and traceability impact are usually higher than the benefit. Coexistence with existing systems is more common, which means portability depends heavily on integration quality and data normalization.

    Key tradeoffs

    • A single enterprise model gives more standardization, but it can hide local failure modes.

    • Plant-specific models are often more accurate, but they are harder to govern at scale.

    • Transfer learning can reduce development time, but only if target data is sufficient and representative.

    • Tighter standardization improves reuse, but may require process and coding changes that plants resist or cannot absorb quickly.

    So the short answer is: yes, sometimes, but not as an assumption and not without evidence. Reuse should be treated as a controlled transfer with local validation, not as proof that one plant’s scrap behavior generalizes to another.

  • Threat scenario

    A threat scenario is a structured description of how a potential adverse event could occur, including the source of the threat, the vulnerable assets or processes, the path of attack or failure, and the possible impact on operations. It is used in risk assessments to move from abstract threats to concrete, analyzable situations.

    Scope in industrial and manufacturing environments

    In industrial operations and regulated manufacturing, a threat scenario commonly refers to a plausible chain of events that could disrupt production, compromise product quality, expose sensitive data, or affect safety and compliance. It typically includes:

    • Threat source: for example, a cyber attacker, insider, equipment supplier, environmental event, or process misuse.
    • Target or asset: OT systems, MES/ERP integrations, quality systems, production equipment, data repositories, or utilities.
    • Attack or failure path: how the threat interacts with vulnerabilities, such as weak network segmentation, outdated firmware, poor access control, or uncontrolled change.
    • Consequences: lost batches, out-of-spec product, unplanned downtime, data integrity issues, or reportable incidents.

    Threat scenarios are often documented as part of:

    • Cybersecurity risk assessments for OT and IT systems.
    • Business continuity and disaster recovery planning.
    • Process hazard and safety analyses.
    • Data integrity and quality risk management exercises.

    Operational use

    Practitioners use threat scenarios to:

    • Identify and prioritize risks to manufacturing systems and critical assets.
    • Evaluate the effectiveness of existing controls across IT, OT, MES, and quality systems.
    • Support decisions about technical safeguards, procedures, and training.
    • Develop playbooks and response procedures for specific events, such as ransomware affecting a plant network or a configuration error propagating through integrated systems.

    Common confusion

    • Threat vs. threat scenario: A threat is a potential cause of an unwanted incident (for example, malware or insider misuse). A threat scenario is the detailed narrative of how that threat could exploit vulnerabilities and what might happen as a result.
    • Threat scenario vs. use case: A use case typically describes intended, normal system usage. A threat scenario focuses on misuse, failure, or attack patterns that could harm the organization or disrupt compliant operations.

  • use-as-is

    In regulated manufacturing and aerospace, use-as-is is a formal nonconformance disposition that allows a part, assembly, or product to be accepted and released without restoring full conformance to the original specification or drawing, provided it is judged acceptable for its intended use.

    What use-as-is includes

    Use-as-is disposition typically means:

    • The nonconformance is documented on a nonconformance report (NCR) or similar record.
    • Technical authorities (often quality, engineering, and sometimes the design or customer authority) have reviewed the deviation.
    • The part or product is determined to be functionally acceptable, safe for its intended application, and compatible with system performance requirements.
    • No rework or repair will be performed to bring it back exactly to the original specification, although minor administrative updates (such as records or markings) may still occur.

    What use-as-is does not include

    Use-as-is does not mean:

    • Ignoring or hiding the nonconformance.
    • Automatically accepting all deviations without engineering or quality review.
    • Rework or repair actions to change the physical condition of the item (those are separate dispositions).
    • A permanent design change. If the design itself is updated, that is handled through configuration or change control, not just a use-as-is decision.

    Operational context in manufacturing

    In production environments, especially aerospace, defense, automotive, and other regulated sectors, use-as-is is one of several standard dispositions on an NCR, alongside options such as rework to specification, repair, or scrap. MES, QMS, and ERP systems often implement use-as-is as a selectable code or status, tied to workflows for:

    • Routing the NCR to appropriate approvers (e.g., quality, design engineering, customer or regulatory representative).
    • Recording justifications, risk assessments, and any conditional limitations (for example, limited life, restricted application, or traceability notes).
    • Linking the disposition to affected serial numbers, lots, or work orders for traceability.

    Common confusion

    • Use-as-is vs. rework to spec: Rework to spec involves processing the item so it fully meets the original requirements. Use-as-is accepts the deviation without restoring full conformance.
    • Use-as-is vs. repair: Repair typically introduces a controlled deviation from the original design (often requiring specific repair instructions). Use-as-is does not change the item further; it accepts the current condition.
    • Use-as-is vs. waiver/deviation: A waiver or deviation is a formal authorization to depart from a requirement. A use-as-is disposition may rely on a waiver or deviation, but the terms are not identical. Waiver/deviation refers to the requirement; use-as-is refers to how the specific nonconforming item is handled.

    Link to aerospace NCR processes

    In aerospace, use-as-is dispositions often require approval from quality and design engineering, and sometimes from the customer or regulatory design authority, depending on configuration control, contract terms, and the criticality of the nonconforming feature. Local procedures define who is authorized to approve use-as-is and how such decisions are documented for audit and traceability.

  • Containment

    Core meaning

    Containment commonly refers to temporary actions taken to isolate, control, or limit the impact of a detected problem, nonconformance, or risk. In industrial and manufacturing environments this usually involves preventing suspect product, data, or processes from progressing further in the value stream until the issue is understood and longer‑term corrective actions are defined.

    Containment may apply to:
    – Physical product (e.g., batches, lots, units, materials)
    – Digital records (e.g., electronic batch records, MES transactions, quality data)
    – Processes or equipment (e.g., temporarily stopping, bypassing, or restricting use)

    It is generally time‑bound and scoped, and it does not by itself eliminate the underlying root cause.

    Use in manufacturing and regulated operations

    In regulated and quality‑critical manufacturing, containment is used when a deviation, defect, or process failure is detected or suspected. Typical activities include:

    – **Identifying scope of impact**: Determining which lots, batches, orders, time windows, or equipment may be affected.
    – **Isolating product**: Quarantining or blocking release of in‑process or finished goods, often through inventory holds in MES or ERP.
    – **Controlling process flow**: Stopping production, disabling specific routes or recipes, or adding additional checks at certain operations.
    – **Protecting downstream operations and customers**: Preventing suspect material from reaching subsequent process steps, customers, or patients.

    Containment is typically documented in deviation reports, nonconformance records, or CAPA workflows in quality systems.

    Containment in OT/IT and MES contexts

    In operations technology (OT) and manufacturing execution systems (MES), containment often appears as system‑enforced controls, for example:

    – **Hold statuses and quarantine**: Automatically putting lots, batches, or work orders on hold based on alarms, test failures, or operator input.
    – **Electronic segregation**: Routing suspect material to dedicated inspection or rework operations instead of normal processing.
    – **Access and usage restrictions**: Temporarily disabling recipes, equipment, or test plans in MES or related systems until an investigation is complete.
    – **Data containment**: Flagging or excluding suspect measurement data from release decisions, analytics, or compliance reports.

    Integration with ERP and quality management systems allows containment actions in one system (e.g., a quality hold) to propagate and block related transactions elsewhere.

    Boundaries and what containment is not

    Containment:
    – **Is**: A short‑term control to prevent further impact while an issue is being investigated.
    – **Is not**: The same as corrective action or preventive action; it does not remove the root cause.
    – **Is**: Often the first step after a problem is detected.
    – **Is not**: A permanent process change, redesign, or improvement strategy.

    In many formal problem‑solving methods, containment is required before root cause analysis proceeds, to ensure ongoing production does not worsen the situation.

    Common confusion and related terms

    – **Containment vs. correction**: Correction is the act of fixing a specific detected nonconforming item (e.g., reworking a defective unit). Containment is broader and focuses on controlling all potentially affected items or processes, including those not directly inspected.
    – **Containment vs. corrective action (CA)**: Corrective action addresses the root cause so the problem does not recur. Containment only limits immediate risk and may be removed once effective corrective actions are in place.
    – **Containment vs. preventive action (PA)**: Preventive action addresses potential problems that have not yet occurred. Containment reacts to a problem that is already known or suspected.

    Recognizing these distinctions is important for accurate use of quality system terminology and for structuring investigations and documentation.

    Use in risk and safety management

    In a broader risk and safety context, containment can also describe:

    – **Physical containment**: Using barriers, enclosures, or zones to confine hazards (e.g., chemicals, biologics, energized equipment) to controlled areas.
    – **Procedural containment**: Implementing temporary work instructions, access controls, or emergency measures to prevent hazard propagation.

    In regulated environments, such measures are often linked to formal risk assessments and incident management processes.

  • What are examples of non-conformance?

    In regulated manufacturing environments, a non-conformance is any departure from an approved requirement: drawings, specifications, procedures, software configuration, regulatory constraints, or contractual terms. It is broader than just a bad part.

    1. Product & material non-conformances

    • Dimensional out-of-tolerance: Features outside drawing tolerance (e.g., hole diameter, flatness, runout) even if the part could still “work.”
    • Material mis-match: Wrong alloy, resin grade, heat treat condition, or temper versus the bill of material or material specification.
    • Special process failure: Plating thickness, hardness, surface finish, or bonding strength not meeting the approved process specification or certificate of conformance.
    • Contamination or foreign object debris: Particulate, oil, or foreign material found where the specification or cleanliness standard prohibits it.
    • Labeling and identification errors: Incorrect part number, revision level, serial number, or expiry date on labels, tags, or nameplates.
    • Out-of-spec environmental conditions for product: Parts processed or stored outside required temperature, humidity, or cure conditions when those are specified.

    2. Process & procedural non-conformances

    • Using an unapproved or obsolete procedure: Work performed using a superseded work instruction or a locally modified copy that is not under document control.
    • Skipping required process steps: Missing in-process inspection, verification, torque check, leak test, or pressure test defined in the routing or control plan.
    • Operating outside process parameters: Heat treat cycle, curing profile, welding parameters, or CNC program feeds/speeds outside validated or approved limits.
    • Unapproved tooling or fixtures: Using unqualified gauges, expired fixtures, or personal tools where controlled tooling is specified.
    • Bypassing interlocks or controls: Overriding safety or quality interlocks to run equipment outside the validated or approved mode.
    • Unauthorized rework or repair: Rework performed without an approved rework instruction, engineering disposition, or proper traceability.

    3. Documentation & record non-conformances

    • Incomplete batch or lot records: Missing signatures, dates, measured values, test results, or lot/serial traceability information.
    • Illegible or ambiguous records: Handwritten entries that cannot be read or interpreted reliably.
    • Backdating or out-of-sequence entries: Records completed after the fact without clear annotation or justification, undermining data integrity expectations.
    • Using uncontrolled documents: Shop floor using personal printouts or local spreadsheets not tied to the controlled document system.
    • Mismatched records vs. actual build: Record says operation completed or test passed, but physical evidence or system data indicates it did not occur or used different parameters.

    4. Supplier & incoming non-conformances

    • Vendor material off-spec: Certificates of analysis or conformance that do not match required callouts, missing test results, or incorrect revision of a referenced standard.
    • Unapproved source or process: Parts produced by a supplier, sub-tier, or process step not on the approved supplier or special process list.
    • Packaging & transport damage: Dents, corrosion, moisture ingress, or broken seals on incoming product where shipping and handling requirements are defined.
    • Documentation gaps from suppliers: Missing FAI reports, traceability, special process certs, or software documentation required by purchase order.

    5. Software, data, and system non-conformances

    • Unvalidated software changes: MES, PLC, CNC programs, or test stand software changed without going through required validation and change control.
    • Wrong configuration or master data: Incorrect routings, BOMs, inspection plans, or control limits in ERP/MES that cause work to deviate from the approved design or control plan.
    • Bypassing electronic controls: Using “test” or “maintenance” modes in production without authorization and documentation.
    • Data integrity issues: Incomplete, overwritten, or untraceable electronic records where regulations or internal policy require reliable audit trails.
    • Interface failures between systems: Missing or misaligned data during handoffs (e.g., PLM to MES, MES to QMS) that lead to building to the wrong revision or inspection criteria.

    6. Regulatory & contractual non-conformances

    • Ignoring regulatory constraints in process: Operating outside environmental, sterility, or cleanliness conditions that are part of a regulated process description.
    • Missing required inspections or sign-offs: Not performing inspections or approvals required by customer contract, drawing notes, or regulatory dossier.
    • Improper handling of export-controlled data: Manufacturing or documentation practices that do not align with export control classifications and associated handling rules.
    • Use of non-qualified equipment: Using equipment that is not installed, qualified, or maintained per your own regulated procedures where such qualification is required.

    7. How context affects what “counts” as non-conformance

    Which events are formally logged as non-conformances depends on:

    • Your specifications and procedures: If a requirement is not written, it is harder to define deviation, but regulators will still expect reasonable controls.
    • System maturity and integration: In brownfield environments with mixed MES/ERP/PLM/QMS stacks, some deviations surface as paperwork issues rather than visible scrap, even though risk is real.
    • Validation and change control: In validated or qualified systems, minor configuration changes may still be non-conformances if they bypass defined change control pathways.

    The same physical issue (for example, running a furnace 5 °C above target) may be an informal process deviation in one plant and a formal non-conformance in another, depending on how the process is specified, validated, and linked to regulatory submissions or customer approvals.

    8. Practical rule of thumb

    In practice, treat the following as non-conformance candidates in a regulated, long-lifecycle environment:

    • Anything that departs from documented requirements (drawings, specifications, validated parameters, SOPs).
    • Anything that cannot be fully reconstructed with evidence (traceability or data gaps).
    • Anything that bypasses approved controls (process, system, or organizational) meant to ensure quality or regulatory alignment.

    Deciding how to classify and handle each case should be done within your existing quality system, with appropriate traceability, risk assessment, and change control rather than ad hoc judgment.