Connect981 – Content Dev

RSC Content Type: FAQ

Direct answers to common technical or compliance questions.

  • Do we need separate manuals for quality and information security?

    You do not always need completely separate manuals for quality and information security, but you do need clearly separated scope, responsibilities, and evidence. How you achieve that separation can be through two manuals or one integrated manual with clearly partitioned sections.

    When separate manuals are usually preferred

    Many regulated manufacturers keep distinct manuals (for example, a Quality Management System (QMS) manual and an Information Security Management System (ISMS) or cybersecurity manual) because it simplifies:

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

    • Audit handling: Different auditors (regulatory, customer, certification, IT/cyber) care about different clauses and evidence sets. Separate manuals allow you to share only what is relevant.
    • Ownership and change control: Quality is typically owned by QA/Operations; information security by IT/cyber. Separate manuals reduce cross-team friction in approvals and change cycles.
    • Lifecycle differences: Quality processes around production and validation often change slower than security controls, which must react to changing threats and IT landscapes.
    • Scope boundaries: Quality often focuses on product realization, nonconformance, and CAPA, while information security spans enterprise systems, networks, and sometimes third-party services well outside manufacturing.

    In brownfield environments with legacy MES/ERP/QMS and long-qualified equipment, this separation helps avoid frequent rework of quality documentation every time a security configuration or network architecture changes.

    When a single integrated manual can work

    A single manual can be workable if:

    • Your management system is intentionally integrated: For example, a combined ISO 9001 / 27001 / 13485 / AS9100 structure with a common policy framework.
    • Document control is mature: You can reliably manage section-level ownership, versioning, and change logs so edits to security sections do not unintentionally affect quality sections and vice versa.
    • Auditor expectations are aligned: You have validated with key customers, certifiers, or notified bodies that an integrated manual is acceptable if the structure clearly maps to applicable requirements.
    • Traceability is explicit: You maintain a clause-to-section matrix showing where each quality and security requirement is addressed, so that combined content is still easy to navigate during audits.

    Even in a single manual, it is wise to keep separate top-level sections and role-based access controls in your document management system, so security-sensitive details are restricted while high-level process descriptions remain broadly available.

    Key decision factors

    When deciding whether to separate or integrate, consider:

    • Regulatory and customer drivers: Some customers or regulatory schemes implicitly expect distinct quality and security governance, even if they do not mandate separate manuals.
    • Audit load and frequency: If you face frequent product audits plus separate cybersecurity assessments, separate manuals often reduce preparation effort and cross-impact risk.
    • Organization structure: If quality and information security report into different leadership chains with separate review boards, separate manuals usually create fewer conflicts over content and priorities.
    • Systems landscape: In mixed, brownfield IT/OT environments, information security content tends to change more often as you harden networks, patch legacy systems, or deploy compensating controls. Housing all of that in the QMS manual can introduce unnecessary revalidation work.
    • Validation and change control burden: In regulated manufacturing, changes to quality documentation may force impact assessments, training updates, and sometimes system re-validation. Tightly coupling fast-moving security content to the QMS manual can slow necessary security changes.

    Practical middle ground: linked but distinct

    A practical compromise in many plants is:

    • Separate manuals: Maintain a QMS manual and an information security / cybersecurity manual as standalone, controlled documents.
    • Shared framework elements: Use a common policy hierarchy, risk management principles, and CAPA concepts so terminology aligns.
    • Cross-references: In the QMS manual, reference the security manual where data integrity, access control, or OT cybersecurity are relevant. In the security manual, reference quality documents where product data and regulated records are in scope.
    • Shared procedures where necessary: For example, incident management, change control, and supplier management can be defined once and referenced by both manuals with clear role ownership.

    This approach keeps boundaries clear for audits and change control, while acknowledging that product quality and information security are interdependent in modern manufacturing systems.

    Coexistence with existing systems

    Whatever you choose, align the manual structure with your existing QMS, document control, and IT/security tooling:

    • Document control system: Ensure both manuals, and all referenced procedures, are under consistent version governance, with traceable approvals and training records.
    • Legacy MES/ERP/PLM: If quality processes are tightly coupled to legacy systems, avoid embedding detailed, system-specific security configurations in the QMS manual. Instead, keep those in the security manual or technical standards and reference them.
    • OT environments: For industrial control systems and plant-floor networks, define security controls in a way that acknowledges long equipment lifecycles and limited downtime windows, and link those controls to relevant quality risks (for example, data integrity, batch records, and traceability).

    Full replacement of existing manuals or management systems purely to “unify” everything is rarely justified in aerospace- or medical-grade environments, given validation effort, audit disruption, and the risk of introducing documentation gaps. Incremental restructuring with clear cross-references is usually safer.

    Summary

    You are not universally required to have separate quality and information security manuals, but combining them into a single document often increases complexity, especially in regulated, brownfield environments. Most organizations benefit from either two manuals or a carefully structured integrated manual with clearly distinct sections, explicit ownership, and strong document control.

  • How does tolerance stacking and model-based definition misinterpretation contribute to hidden scrap risk?

    Tolerance stacking and model-based definition (MBD) misinterpretation create hidden scrap risk when parts are produced and accepted as “in tolerance,” yet the assembled system cannot meet fit, functional, or regulatory requirements. The risk is amplified in regulated, multi-vendor environments where CAD, CAM, CMM, and MES/QMS systems do not interpret the model consistently.

    How tolerance stacking creates hidden scrap

    Even when each feature is within its specified tolerance, the combined variation across multiple parts and features can push the assembly outside its functional limits. This is the core of hidden scrap: nothing looks obviously nonconforming at the part level, but the assembly cannot be released without rework, concession, or redesign.

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

    Typical mechanisms include:

    • Linear stack-up across features: Small, allowed deviations on hole locations, thickness, and flatness can accumulate so that datums shift and mating features no longer align, even though every measurement falls within its drawing or MBD limits.
    • Ignoring assembly-level requirements: Part tolerances are set without a proper statistical or worst-case tolerance analysis at the assembly or system level. Parts are accepted to their own specs, but the assembly cannot pass functional test, leak test, or performance verification.
    • Overly optimistic assumptions about process capability: Tolerances are set assuming processes are centered and stable. In reality, drift, wear, or lot-to-lot variation can bias several dimensions in the same direction, making worst-case stack-ups more likely.
    • Local optimization of individual parts: Teams relax tolerances on individual components to reduce machining cost or cycle time without re-running the stack-up analysis, pushing cumulative variation beyond what the assembly can absorb.

    In practice, the hidden scrap is often discovered:

    • At assembly, when parts will not fit without shimming, hand-fitting, or rework.
    • At functional test, when the unit cannot meet performance or safety limits even though all incoming inspection data shows compliance.
    • During field issues or reliability testing, when accumulated variation causes premature wear, leakage, or misalignment.

    Because each part appears compliant, the nonconformance is often coded as “assembly issue” or “special cause,” and the true cost of poor tolerance management remains underreported in standard scrap metrics.

    How MBD misinterpretation adds to the problem

    Model-based definition is intended to reduce ambiguity, but in brownfield environments it can introduce new failure modes. Hidden scrap risk grows when downstream systems or people interpret the model differently from the design intent.

    Typical MBD-related mechanisms include:

    • Inconsistent datum interpretation: CAM programmers, CMM programmers, and machinists may select different practical datums than those defined in the MBD, especially when fixtures or tooling are legacy or not fully aligned to the datum scheme. Parts are made and measured consistently to the wrong reference frame, which only shows up at assembly.
    • Loss or corruption of PMI during data exchange: Translating models between CAD systems, or from CAD to CAM/CMM, can drop or alter product manufacturing information (PMI). For example, a true position tolerance may be misinterpreted as a coordinate tolerance, or a material modifier may be lost, changing the functional envelope without obvious visual cues.
    • Different software math for GD&T evaluation: Not all CMM or analysis packages implement GD&T the same way. Bonus tolerances, datum mobility, or boundary conditions may be evaluated differently, so a part that “passes” in one system would fail per the original standard or design intent.
    • Incomplete or ambiguous MBD: In early or immature MBD deployments, the model may not fully define all features, notes, or process-critical requirements. Shop-floor personnel fill gaps with tribal knowledge or local conventions, which can diverge from what downstream assemblies or regulators expect.
    • Partial MBD adoption in a mixed environment: When some components are fully model-based and others still rely on 2D drawings, there can be misalignment between how tolerances are applied and how they are measured. Mixed documentation sets can hide systemic errors in one domain until assemblies fail.

    All of these can create a situation where part-level inspection data shows compliance, but the parts are not truly conforming to the design intent. The result is apparent “mystery” scrap or recurring assembly-level nonconformances.

    Why this risk is often hidden in regulated environments

    In regulated, long-lifecycle industries, several factors make these issues harder to detect and correct:

    • Fragmented data: CAD, PLM, CAM, CMM, MES, ERP, and QMS often sit in separate systems with weak integration. Stack-up analyses, MBD definitions, and measurement results are not easily compared or trended across the lifecycle.
    • Qualification and validation burden: Once a process, program, or software toolchain is qualified, there is strong pressure not to change it, even when tolerance or MBD issues are suspected. Fixing the root cause can trigger requalification, making interim workarounds (rework, concessions, manual adjustments) more likely.
    • Concession and rework masking: Deviations may be routinely accepted via concessions or repair instructions to protect schedule, but the accumulated cost of these actions is not always attributed back to tolerance stack-up or MBD issues.
    • Supplier boundaries: Suppliers may work from derivative models or neutral formats and apply their own interpretation of GD&T and MBD. Assemblies at the OEM may then exhibit fit or performance issues that are hard to link back to the original digital definition.

    Typical signals that hidden scrap is driven by tolerance and MBD issues

    Patterns that often indicate an underlying tolerance or MBD problem include:

    • High rework and adjustment rates at assembly stations, especially for fitting, shimming, or aligning supposedly conforming parts.
    • Assemblies failing functional or leak tests with no clear single-component defect.
    • Different plants or suppliers showing systematically different assembly yields using the same nominal design.
    • Frequent drawing or MBD clarification questions from suppliers and internal machinists.
    • Discrepancies between CMM results from different facilities or vendors on the same features.

    Practical ways to reduce hidden scrap risk

    Mitigation rarely means replacing entire systems. In most brownfield environments, improvements focus on tightening definitions and checks at interfaces:

    • Formal assembly-level tolerance analysis: Ensure worst-case or statistical stack-up analysis is part of design release for critical assemblies. Use this to set realistic but protective part tolerances, and to identify which features require tighter control and more robust MBD.
    • Datum strategy alignment: Verify that fixture design, machining setups, and CMM probing strategies are consistent with the MBD datum scheme. Involve manufacturing and metrology in design reviews for critical components.
    • MBD data exchange validation: Systematically test CAD-to-CAM and CAD-to-CMM workflows for a few representative, GD&T-rich parts. Look for lost PMI, altered tolerances, or misinterpreted modifiers between systems.
    • Standardized GD&T and MBD practices: Provide training and reference examples for design, manufacturing, and inspection teams on how GD&T and MBD are to be applied and interpreted within your environment. This is especially important when multiple CAD or CMM tools are used.
    • Closed-loop feedback from assembly and test: Link assembly nonconformances and test failures back to specific features and tolerances in PLM or equivalent systems. Over time, this exposes which tolerances or datum schemes are driving rework and concessions.
    • Pilot projects instead of wholesale MBD replacement: Where MBD maturity is low, start with a limited set of critical parts or assemblies to refine practices and tools before scaling. Full replacement of legacy drawings or systems without this learning phase often fails in high-regulation contexts because of validation and change-control overhead.

    Ultimately, tolerance stacking and MBD misinterpretation create hidden scrap when there is a gap between design intent and how parts are manufactured, measured, and assembled. Managing that gap requires disciplined tolerance analysis, robust digital definition practices, and practical verification of how your specific toolchain interprets the model, not just better part-level inspection.

  • What is the difference between scrap, rework, repair, and concession in aerospace?

    In aerospace and other regulated industries, the terms scrap, rework, repair, and concession describe distinct ways of handling nonconforming product. They are not interchangeable, and each has different implications for airworthiness, approvals, documentation, and cost reporting.

    Scrap

    Scrap is product or material that cannot or will not be used as part of a delivered configuration. Typically:

    • It does not meet requirements and cannot be brought back into conformity in a technically and economically justified way, or
    • It could be reworked or repaired, but the organization decides not to, based on cost, risk, schedule, or customer requirements.

    Key characteristics:

    • Removed permanently from the production flow and from any airworthy configuration.
    • Physically rendered unusable or clearly segregated, then disposed of following internal and regulatory controls.
    • Recorded as nonconformance and as scrap in cost-of-poor-quality metrics.
    • Usually does not go through design approval, because it will not fly or enter service.

    In brownfield environments, scrap tracking is often fragmented across paper travelers, ERP scrap codes, and local spreadsheets, which can distort actual scrap cost if not aligned.

    Rework

    Rework means processing a nonconforming item so that it fully meets the original, released design definition and specifications.

    Key characteristics:

    • The end state is indistinguishable from product that never had a nonconformance when compared to the approved design and specification.
    • Uses the same or equivalent processes already approved by design (e.g., re-machining within allowed stock, repeating an approved heat treatment, re-assembling to the same drawing).
    • Usually handled through standard nonconformance control, with rework instructions documented, controlled, and traceable (e.g., in an NCR, MRB record, or MES nonconformance workflow).
    • Does not require a design deviation, because the final configuration equals the baseline design.

    If you must introduce a new process, change a critical dimension tolerance, or alter material properties beyond existing allowances, you have likely moved from rework into repair or design change territory.

    Repair

    Repair means processing a nonconforming item so that it is acceptable for use, but does not fully conform to the original design definition. Instead, it conforms to an approved repair disposition or repair scheme.

    Key characteristics:

    • Final condition is safe and acceptable, but not identical to the original design (for example, material is blended out of a noncritical area, or a bushing is installed as a permanent corrective feature).
    • Requires formal engineering disposition (e.g., MRB engineering, design authority approval, or use of an approved structural repair manual or standard repair scheme).
    • May require stress analysis, fatigue assessment, or other justification, especially in aerospace primary structure or critical systems.
    • Often creates a “repaired” configuration that must be traceable on the as-built record, including any limitations, inspections, or life restrictions.

    In regulated aerospace, repair dispositions usually need higher-level engineering and, in some cases, regulatory or delegated authority approval. The level of rigor depends on part criticality and applicable regulations or customer contracts.

    Concession (Deviation/Waiver)

    A concession is formal permission from the design or customer authority to accept, ship, or operate an item that does not meet specified requirements, under defined conditions. In some organizations or standards this may be called a deviation or waiver, and the detailed definitions can differ.

    Key characteristics:

    • The product remains nonconforming to the original specification on at least one point.
    • The nonconformance is acknowledged, risk-assessed, and accepted by the responsible design or customer authority for a limited scope (specific parts, serials, or time period).
    • Conditions and restrictions may apply (e.g., inspection intervals, limited life, configuration markings, or operational limits).
    • Requires strong traceability, because regulators and customers often review concessions closely during audits and investigations.

    Concessions are typically used when the cost, schedule impact, or technical risk of rework/repair is high, but engineering analysis shows the deviation does not compromise fitness for intended use or safety margins.

    How they relate and why the distinctions matter

    The four dispositions are related but not interchangeable:

    • Scrap vs rework/repair: Scrap removes the item from service permanently. Rework and repair return the item to use.
    • Rework vs repair: Rework restores full compliance with the original design; repair restores acceptable performance under a modified, approved condition.
    • Repair vs concession: Repair changes the hardware or processing. A concession formally accepts a deviation that may remain as-is, with or without physical change.

    These distinctions affect:

    • Regulatory expectations: Authorities and customers expect documented processes for each disposition, especially repair and concession, and may require specific approvals or delegated signatories.
    • Traceability and records: Repaired and conceded items need clear traceability in the as-built record, often across multiple systems (ERP, MES, QMS, PLM). In brownfield stacks, this usually involves workarounds and interfaces rather than a single clean workflow.
    • Cost of poor quality (COPQ): Mislabeling rework as repair or repair as scrap distorts data on systemic issues and investment decisions.
    • Lifecycle impact: Repairs and concessions can carry inspection or life limits. Losing that link when systems change or are upgraded is a common long-term risk.

    Dependencies and plant-to-plant variation

    The precise boundaries between rework, repair, and concession can vary based on:

    • Contractual definitions with OEMs or primes.
    • National or regional regulations and the way your design approval or delegated authority is structured.
    • Internal procedures in your QMS, including how MRB authority is defined.
    • The maturity and integration level of your MES/ERP/PLM/QMS stack.

    When updating processes or systems, it is important not to “simplify” these categories into a single nonconformance bucket. In long-lifecycle aerospace programs, losing these distinctions can create major issues years later during incidents, retrofit campaigns, or design changes.

  • What is the meaning of non-conformance?

    In regulated manufacturing environments, a non-conformance (often abbreviated as NC or NCR for non-conformance report/record) is a documented failure to meet a defined requirement.

    The requirement can come from many sources, for example:

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

    • Product requirements: drawings, models, material specifications, tolerances, test limits
    • Process requirements: work instructions, validated process parameters, control plans
    • System and documentation requirements: procedures (SOPs), forms, records, approvals
    • External requirements: customer contracts, standards (e.g., ISO 9001, AS9100), regulatory commitments

    Whenever actual results, conditions, or behavior deviate from these approved requirements, you have a non-conformance. This includes, but is not limited to:

    • Defective or out-of-tolerance parts
    • Use of unapproved or expired material or tooling
    • Skipping or partially completing required process steps, checks, or sign-offs
    • Incorrect, missing, or late records in MES/ERP/QMS or on paper travelers
    • Software or system behavior that leads to incorrect or incomplete execution or documentation

    How non-conformance is handled in practice

    In most regulated operations, identifying a non-conformance triggers a controlled process, typically within a QMS or a mix of QMS, MES, and paper systems. Common elements include:

    • Containment: isolating affected product, lots, or data to prevent unintended use or shipment.
    • Disposition: deciding how to handle the non-conforming product or situation (e.g., use-as-is, rework, repair, scrap, return to supplier), with appropriate approvals.
    • Root cause and corrective actions: for significant or repetitive non-conformances, performing structured root cause analysis and implementing corrective and sometimes preventive actions (often via CAPA).
    • Traceability: ensuring the non-conformance, its impact, and all decisions are documented and linked to parts, lots, work orders, and relevant systems.

    In brownfield environments, non-conformances often touch multiple systems (e.g., inspection in one tool, disposition in a QMS, execution data in MES, inventory in ERP). Inconsistent integration and data quality can make it difficult to reliably identify all affected product or to show a complete history during audits, which is why disciplined documentation and change control are important.

    What non-conformance does not mean

    • It is not a guarantee of a safety issue or regulatory non-compliance, but it can contribute to both if not properly controlled.
    • It is not limited to physical defects; process, documentation, and system gaps can also be non-conformances.
    • Raising a non-conformance does not imply that any certification or audit status is lost; it is part of normal, expected quality management in regulated industries.

    Ultimately, non-conformance is the formal mechanism by which an organization recognizes that the operation has deviated from defined requirements and must respond in a controlled, traceable way.

  • Does ISO 9001 help reduce production costs?

    ISO 9001 can contribute to lower production costs, but it does not do this automatically and it is not a cost-reduction program by design. It is a management system standard. Whether your costs go down, stay flat, or even increase depends on how you implement and use it in daily operations.

    Where ISO 9001 can enable cost reduction

    In a regulated, mixed-system environment, ISO 9001 can support cost reduction through:

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

    • More consistent processes: Defined and controlled processes reduce operator-to-operator variation, which can lower scrap, rework, and troubleshooting time.
    • Structured handling of nonconformances and CAPA: When NCR and corrective action processes are actually used, ISO 9001 supports root cause analysis and sustained fixes that reduce chronic defect and rework cost.
    • Risk-based thinking: Better identification of process and supply risks can prevent expensive escapes, field failures, or late-stage scrap.
    • Change control and document control: Clear control of revisions, routings, and work instructions reduces build-to-wrong-revision events and associated rework or MRB costs.
    • Measurement and analysis: The standard expects you to define and monitor process performance and quality metrics, which can be tied to yield, scrap, and throughput improvements.

    All of these are enablers of lower Cost of Poor Quality (COPQ), not guarantees. They only translate to savings if leadership and middle management use the system to remove waste, not just generate records.

    When ISO 9001 does not reduce costs

    There are many cases where ISO 9001 has little or no positive impact on production cost, including:

    • Paper-only or checkbox implementations: If procedures exist only to pass audits and are not used in operations, you add overhead without improving yield or scrap.
    • Parallel systems: When ISO 9001 documentation is disconnected from MES/ERP/PLM/QMS, operators follow one reality and auditors see another. This typically increases confusion, misbuilds, and administrative labor.
    • No link to improvement projects: If NCR, internal audit, and customer complaint data are not feeding into structured improvement work, the same issues recur and COPQ remains high.
    • Overly complex procedures: Writing heavy, hard-to-follow procedures to “satisfy the standard” can slow operators and introduce new failure modes.

    In those situations, ISO 9001 compliance can raise the cost of doing business (documentation, audits, training) without any measurable reduction in production costs.

    Dependencies in brownfield and regulated environments

    In long-lifecycle aerospace and similar environments, the impact of ISO 9001 on cost is heavily dependent on:

    • Integration with existing systems: Aligning ISO 9001 processes with your existing MES, ERP, PLM, and QMS is critical. If you create new, standalone ISO 9001 workflows instead of embedding requirements into current systems, you usually add cost.
    • Process maturity: Plants with unstable, tribal-knowledge-driven processes may see more benefit, but only if they invest in standard work, training, and enforcement, not just documentation.
    • Data readiness and traceability: You need reliable data on scrap, rework, delays, and supplier defects to prioritize improvements. Without that, ISO 9001 becomes high-effort, low-impact paperwork.
    • Change control burdens: In heavily validated or qualified lines, every process change to capture ISO 9001 requirements may trigger requalification, validation testing, or customer approvals. That effort can offset some of the cost savings unless changes are targeted and justified.

    Full system replacement initiatives justified by “we need ISO 9001 compliance” often struggle or fail in these environments. Replacing MES, QMS, or ERP to align with a textbook interpretation of ISO 9001 usually runs into qualification burden, downtime risk, integration complexity, and long asset lifecycles. Incremental improvements on top of existing systems are more realistic.

    How to make ISO 9001 materially support cost reduction

    To get real cost impact from ISO 9001, organizations typically need to:

    • Tie ISO 9001 objectives to operational metrics: Connect quality objectives directly to COPQ, scrap, rework hours, and on-time delivery, not just audit findings.
    • Use NCR and CAPA as engines for improvement: Prioritize high-cost issues for root cause analysis and structured corrective action, with clear ownership and deadlines.
    • Integrate standard work into the operator experience: Ensure work instructions, routings, and inspection plans used to meet ISO 9001 are the same ones visible on the shop floor (paper or digital), not a separate audit-only set.
    • Control change pragmatically: Use risk-based change control so you can refine processes for cost and quality without triggering unnecessary requalification churn.
    • Continuously audit for effectiveness, not just conformance: Internal audits and layered process audits should test whether controls prevent defects and delays, not merely whether forms are filled out.

    When these practices are in place, ISO 9001 can become the backbone of a continuous improvement system that steadily reduces COPQ and stabilizes production. Without them, it is mainly an overhead line item.

    Bottom line

    ISO 9001 can help reduce production costs, but only as part of a disciplined, data-driven quality and operations strategy that is integrated with your existing systems. It does not guarantee savings, and a poorly designed implementation can increase cost without improving performance.

  • What are the 5 M’s of manufacturing?

    The 5 M’s of manufacturing are a common way to organize potential causes when you are analyzing process performance or quality problems. The letters stand for:

    • Man: People and human factors involved in the process. In modern usage this typically means operators, technicians, engineers, and supervisors, including training, qualifications, workload, shift patterns, and communication. In regulated environments, competence records, training matrices, and documented responsibilities are part of this category.
    • Machine: Equipment, tools, fixtures, software-driven systems, and automation used to produce or inspect the product. This includes maintenance status, calibration of equipment, control system configuration, and known limitations. In brownfield plants, this often spans multiple vintages of machines and control systems.
    • Material: Raw materials, components, consumables, and intermediates. This covers specifications, certificates of analysis or conformity, storage conditions, shelf life, lot-to-lot variability, and supply chain issues that may affect consistency.
    • Method: The way work is performed, including procedures, work instructions, set-up sheets, recipes, programs, and process parameters. In regulated settings, this also includes change control around process definitions and how well actual practice matches approved documentation.
    • Measurement: Inspection and test methods, gauges and instruments, sampling plans, data collection systems, and analytical methods. This includes measurement system analysis, calibration status, data integrity, and how results are recorded and used for decisions.

    In practice, the 5 M’s are often used to structure fishbone (Ishikawa) diagrams, 5-Whys, and other root cause analysis tools. They are a thinking aid, not a standard or a guarantee of completeness. In complex, regulated operations you will usually need to extend or adapt them (for example, adding categories like Environment or Management) to reflect site-specific risk, system interfaces, and regulatory expectations. Any conclusions drawn using the 5 M’s should be supported by evidence, traceable records, and validated data rather than assumptions.

    In practice, this connects to lean and process improvement when teams need to turn the answer into repeatable execution habits.

  • What is NC in quality?

    In quality management, NC almost always stands for nonconformance (or nonconformity). It refers to any product, process, documentation, or system condition that does not meet a defined requirement.

    What counts as an NC?

    Typical examples include:

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

    • Parts outside drawing or specification limits (dimensions, material, performance).
    • Process parameters outside validated or approved ranges.
    • Missing or incomplete required records (inspection data, batch records, device history records).
    • Using unapproved, expired, or superseded documents, tools, or software versions.
    • Supplier material that fails incoming inspection or agreed acceptance criteria.

    What is formally treated as an NC depends on your quality management system (QMS), procedures, and regulatory context. Many plants distinguish between minor deviations handled locally and NCs that must be logged in a system and reviewed.

    How is NC used in systems and documentation?

    In regulated, brownfield environments, NC can appear in multiple places:

    • QMS / eQMS: NC records or nonconformance reports (NCRs) capturing the issue, requirements, evidence, and disposition.
    • MES / LIMS / shop-floor systems: NC status for a lot, batch, order, or serial number, often triggering holds, rework routes, or additional inspections.
    • ERP / MRP: NC-related stock statuses (e.g., quality hold, quarantine) affecting availability and costing.
    • Documentation: NC referenced in deviations, waivers, concessions, and sometimes CAPA records.

    Because most regulated plants are brownfield with mixed systems, NC handling is often fragmented across MES, ERP, and QMS. Integration and data quality strongly affect how reliably NC status follows the product through its lifecycle.

    NC vs. CAPA and other quality terms

    NC is related to, but different from, other quality concepts:

    • NC (Nonconformance): The actual failure to meet a requirement.
    • Deviation: Authorized departure from a requirement, usually preapproved or formally documented; may or may not be treated as an NC, depending on procedure.
    • CAPA: Corrective and Preventive Action; a structured process to eliminate root causes and prevent recurrence. Not every NC requires a full CAPA, especially in high-volume production, but significant or recurring NCs typically do.
    • Defect / nonconforming product: The physical product impact of an NC.

    Many organizations use terms like NCR (Nonconformance Report) or NCMR (Nonconforming Material Report) for the formal record associated with an NC.

    Why NC management matters in regulated manufacturing

    In regulated and aerospace-grade environments, NCs are important because they affect:

    • Traceability: You must be able to show which serials, lots, or batches were impacted and how they were dispositioned.
    • Risk and safety: Some NCs can have direct safety or regulatory implications; these need structured assessment and escalation.
    • Documentation and evidence: Auditors and regulators expect consistent, retrievable NC records, with clear links to requirements, decisions, and responsibilities.
    • Change control: Systemic NCs often drive changes to specifications, methods, or equipment that must be controlled and validated.

    Efforts to “replace” existing NC processes or tools wholesale often run into problems: long equipment lifecycles, qualification and validation effort for new systems, downtime constraints, integration with legacy ERP/MES/QMS, and the need to preserve historical NC data for traceability. Incremental improvements and better integration usually carry less risk than full replacement.

    Key dependencies and variability

    How NCs are defined, coded, and processed in your plant will depend on:

    • The specific QMS procedures and work instructions in force.
    • The regulations and standards you operate under (for example, FDA, EASA, AS9100, IATF 16949).
    • Your system landscape (legacy MES/ERP/PLM/QMS and their integrations).
    • The maturity of root cause analysis and CAPA processes.

    Because of this, the exact meaning of an NC code or NC status can vary by site and by system. When in doubt, rely on your internal definitions in the QMS and system configuration documentation.

  • How do clauses 4–10 of ISO 9001 relate to the PDCA cycle?

    Clauses 4 to 10 of ISO 9001:2015 are intentionally structured around the Plan-Do-Check-Act (PDCA) cycle. The fit is not one-to-one for every subclause, but the overall alignment is clear and useful when designing or auditing a quality management system in industrial and regulated environments.

    High-level mapping of clauses 4–10 to PDCA

    The most widely accepted mapping is:

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

    • Plan: Clauses 4, 5, 6, and 7
    • Do: Clause 8
    • Check: Clause 9
    • Act: Clause 10

    This mapping reflects the lifecycle of establishing context and requirements, planning and resourcing processes, executing operations, measuring performance, and driving corrective action and improvement.

    Plan: Clauses 4, 5, 6, 7

    • Clause 4: Context of the organization
      Defines internal and external issues, interested parties, and the scope of the QMS. This is foundational planning input for a realistic PDCA cycle in a brownfield environment with legacy systems and constraints.
    • Clause 5: Leadership
      Addresses policy, roles, responsibilities, and leadership commitment. It frames how PDCA will be governed and who is accountable for each stage, including cross-functional ownership across operations, engineering, quality, and IT.
    • Clause 6: Planning
      Covers risks and opportunities, quality objectives, and planning changes. This is the core of the “Plan” phase: deciding what to improve, what risks to mitigate, and how to structure change while respecting validation, traceability, and downtime limits.
    • Clause 7: Support
      Includes resources, competence, awareness, communication, and documented information. It ensures the planned processes are realistically resourced, documented, and trained so that the later “Do” phase is executable in real operations.

    In practice, these clauses drive how you design processes that sit across QMS, MES, ERP, PLM, and other systems, and how you plan for data integrity, evidence, and configuration control before changing anything on the shop floor.

    Do: Clause 8

    • Clause 8: Operation
      Represents the “Do” phase. It covers operational planning and control, requirements review, design and development, control of externally provided processes, production and service provision, release of product, and control of nonconforming outputs.

    This is where plans interact with reality: work instructions, travelers, inspection plans, supplier controls, and NCR workflows are executed across existing equipment and IT/OT stacks. In regulated aerospace and similar sectors, Clause 8 often spans multiple systems and manual controls that must be coordinated instead of replaced outright due to validation and downtime risk.

    Check: Clause 9

    • Clause 9: Performance evaluation
      Corresponds to the “Check” phase. It includes monitoring, measurement, analysis, evaluation, internal audit, and management review.

    Here, organizations verify that the “Do” activities are delivering what was planned. This typically includes KPI monitoring (such as scrap, rework, and on-time delivery), process performance analysis, customer feedback, and internal audits. In brownfield environments, the main challenge is aggregating consistent, trustworthy data from multiple systems to make this checking meaningful and auditable.

    Act: Clause 10

    • Clause 10: Improvement
      Represents the “Act” phase. It covers nonconformity and corrective action as well as continual improvement.

    This is where findings from audits, metrics, and operations drive corrective actions, CAPA, and broader improvement projects. In highly regulated manufacturing, Clause 10 actions must respect change control, validation, and configuration management. Large-scale system replacements here often fail or stall because the Act phase becomes unmanageable if you attempt to change too much at once across qualified equipment and interfaces.

    Why this mapping matters in regulated, brownfield environments

    Understanding the PDCA alignment helps you:

    • Structure your QMS documentation, workflows, and evidence so that each stage of PDCA is explicitly covered and traceable.
    • Map existing systems (QMS, MES, ERP, PLM, LIMS) to PDCA stages instead of assuming a new platform will replace everything.
    • Plan incremental, low-risk improvements that respect validation, data integrity, and limited shutdown windows.
    • Clarify where metrics and audits (Check) are weak, and how corrective actions (Act) should be designed to realistically change operations (Do) while remaining within the boundaries of the planned system design (Plan).

    This mapping does not guarantee any specific certification outcome or audit result, but it provides a practical backbone for organizing and improving a quality management system in complex industrial operations.

  • What does non-conformant mean?

    In regulated manufacturing environments, “non-conformant” (or “nonconforming”) means that a product, component, material, process, document, or system does not meet one or more defined requirements.

    Those requirements usually come from:

    • Technical specifications and engineering drawings
    • Approved bills of material and routings
    • Standard operating procedures (SOPs) and work instructions
    • Quality standards, validation protocols, and test methods
    • Regulatory filings or customer contracts

    When something is classified as non-conformant, it typically triggers formal quality control steps such as recording a nonconformance, segregating affected product, assessing impact and risk, deciding on disposition (rework, use-as-is with justification, scrap, or return to supplier), and potentially opening corrective and preventive actions (CAPA) or root cause analysis.

    Non-conformant does not automatically mean unsafe or unusable, but it does mean the item cannot be treated as conforming product or process until it has been properly evaluated, documented, and dispositioned under the plant’s quality and change-control procedures.

  • How are lessons learned from incidents incorporated into AS9100?

    AS9100 does not have a single, named “lessons learned” clause. Instead, it embeds learning from incidents across multiple requirements. To incorporate lessons learned in a way that stands up in a regulated aerospace environment, you have to connect several parts of the standard into a closed loop.

    Key AS9100 mechanisms where lessons learned must show up

    • Nonconformity and corrective action (AS9100 10.2)
      • Incidents (quality escapes, customer complaints, audit findings, process deviations, in-service events) are documented as nonconformities.
      • Root cause analysis is performed and recorded (often via 8D, fishbone, 5-Whys, or equivalent methods).
      • Corrective actions are defined, implemented, and evaluated for effectiveness, not just closed on paper.
      • Verified corrective actions become the primary vehicle for institutionalizing lessons learned.
    • Risk-based thinking and operational risk (e.g., 6.1 and 8.x)
      • Incident learnings should update risk registers, FMEA, PFMEA, control plans, and similar tools.
      • Known failure modes discovered through incidents should be reflected as higher risk ratings or new risks, with revised controls.
      • There should be traceable linkage from the incident to the updated risk mitigation documented in your QMS.
    • Configuration management and change control
      • If a lesson learned drives a process, document, design, or software change, it must go through established configuration and change control.
      • Evidence should show which incident or CAPA triggered which change, and which part numbers, routings, or work instructions are affected.
      • In aerospace environments with long lifecycles, ensuring backward and forward traceability is critical to avoid conflicting configurations in the field.
    • Documented information and work instructions
      • Lessons learned typically drive updates to procedures, specifications, checklists, inspection plans, and work instructions.
      • AS9100 expects controlled document changes with versioning, approvals, and records of distribution.
      • There must be a clear path from incident to revised documented information and, ultimately, to the point of use on the shop floor or in MRO.
    • Training, awareness, and competency
      • When incident learnings affect how work is done, impacted roles should receive targeted training.
      • Training records, sign-offs, or digital acknowledgments are often used as objective evidence that the lesson has been communicated.
      • In brownfield plants, this often requires bridging paper training records, legacy HR systems, and MES/QMS operator certifications.
    • Management review (AS9100 9.3)
      • Significant incidents, systemic corrective actions, and recurring themes should be inputs to management review.
      • Top management is expected to evaluate whether controls, resources, and priorities are adjusted in light of those lessons.
      • Evidence includes management review minutes showing discussion of trends, systemic risks, and decisions taken.
    • Internal audits and process monitoring
      • Internal audits should verify that lessons learned are actually embedded in day-to-day practice.
      • Common approaches include targeted audits or layered process audits focused on areas that generated serious incidents.
      • Audit trails should show checks against prior incidents or CAPAs, not just generic compliance checks.

    What effective “lessons learned” looks like in an AS9100 QMS

    In practice, an aerospace organization can demonstrate that it has incorporated lessons learned from incidents when it can:

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

    • Trace each significant incident to a documented nonconformance and corrective action.
    • Show root cause analysis and justification for chosen corrective and preventive actions.
    • Point to specific changes in procedures, work instructions, inspection plans, tooling, or controls tied to that CAPA.
    • Produce evidence that affected personnel were trained on the new methods.
    • Show follow-up data or audits confirming the issue is controlled and not recurring at the same rate or severity.
    • Demonstrate updates to risk assessments and, where relevant, design or process FMEA.
    • Show that serious or systemic issues were escalated and reviewed by management.

    This is less about a single “lessons learned” database and more about an integrated QMS that turns incidents into controlled, verified changes.

    Digital systems, brownfield reality, and tradeoffs

    In most aerospace and defense environments, lessons learned must cross multiple legacy systems and paper processes. Typical patterns include:

    • QMS / CAPA system used to log incidents, perform root cause analysis, and track corrective actions.
    • ERP/MES/PLM used to manage routings, BOMs, engineering changes, and work instructions.
    • Standalone tools (spreadsheets, email, shared drives) holding risk registers, FMEAs, and historical notes.

    Tradeoffs and failure modes include:

    • Fragmented traceability: Incidents are analyzed in one system, but changes in work instructions or routing are made elsewhere without robust linkage. Auditors then see isolated actions, not a closed loop.
    • Partial adoption on the shop floor: Even if lessons learned are documented, outdated paper travelers or tribal knowledge may override new instructions, especially in brownfield plants with mixed equipment and slow change cycles.
    • Over-ambitious replacement projects: Attempts to replace QMS, MES, and document control in a single step often stall due to validation burden, downtime risk, and integration complexity. Incremental integration and phased digitization usually work better in AS9100 environments.
    • Validation and qualification overhead: Any software or process change intended to embed lessons learned must be validated to the level appropriate for the organization and customers. This slows response if not planned for in the change management process.

    Because of these constraints, many organizations focus first on strengthening linkage between nonconformances/CAPA, change control, and document/work-instruction updates, then gradually integrate MES, PLM, and training records to close gaps.

    Minimum expectations vs. stronger practices

    • Minimum to align with AS9100 intent (interpretation varies by auditor and customer):
      • All significant incidents are documented as nonconformities.
      • Root cause, corrective action, and effectiveness checks are recorded.
      • Resulting changes to processes and documents are controlled and traceable.
      • Recurring issues and major risks are visible in management review.
    • Stronger, more mature practices:
      • Systematic trend analysis of incidents, near-misses, and audit findings across programs and sites.
      • Shared, searchable repository for lessons learned, linked to specific part numbers, processes, or platforms.
      • Proactive use of incident data to update FMEAs and design/process reviews.
      • Tight integration between QMS, MES, and document control so that lessons learned automatically drive changes at the point of use, with audit-ready traceability.

    Ultimately, AS9100 requires that you learn from incidents and prevent recurrence, but it leaves flexibility in how that learning is operationalized. The burden is on each organization to design a traceable, validated mechanism that fits its legacy systems, integration constraints, and customer/regulator expectations.