Connect981 – Content Dev

FAQ Category: cross-plant standardization

  • How do I know whether to use the Low, Moderate, or High baseline?

    “Low, Moderate, and High baselines” typically refer to pre-defined control baselines from frameworks like NIST 800-53 / 800-82 (often via the NIST Risk Management Framework) or similar profiles used for OT and manufacturing. In regulated industrial environments, you do not pick a baseline by preference; you select and justify it based on a structured risk and impact assessment.

    1. Start from the applicable standard or mandate

    Before deciding on a baseline, you need to know which framework and regulatory drivers actually apply. Examples include:

    In practice, this connects to industrial security evidence when teams need to turn the answer into repeatable execution habits.

    • NIST 800-53 / 800-82 baselines mapped to Low / Moderate / High impact systems.
    • IEC 62443 security levels or profiles that your organization has mapped to Low / Moderate / High internally.
    • Customer or government contract clauses that prescribe specific minimum control sets.

    The correct baseline is constrained by these obligations. If your customer, corporate security, or regulator mandates a minimum level, you cannot choose a lower baseline even if your local plant risk seems small.

    2. Assess impact in four key dimensions

    Baselines are normally tied to potential impact, not likelihood. A common pattern is to assess impact of compromise or failure in at least these areas:

    • Safety and environment: Could loss of control, integrity, or availability create realistic scenarios of serious injury, fatality, or major environmental release?
    • Product quality and compliance: Could a failure or breach directly affect conformance to specifications, batch release, airworthiness, lot genealogy, or other regulated quality outcomes?
    • Regulated / sensitive data: Does the system store or process export-controlled data, controlled unclassified information (CUI), PHI, PII, or customer proprietary technical data?
    • Operational and business continuity: Would a prolonged outage materially affect delivery to critical customers, defense programs, or safety-critical aftermarket support?

    In many formal schemes, these factors are translated into impact levels for confidentiality, integrity, and availability, which then drive the baseline selection.

    3. Typical characteristics of Low, Moderate, and High

    The exact definitions vary by organization and framework, but the following patterns are common in manufacturing and OT:

    • Low baseline
      • Systems with limited safety or quality impact and no regulated/sensitive data.
      • Loss or compromise is inconvenient but does not materially affect regulated product, worker safety, or contractual obligations.
      • Examples: non-critical utility dashboards, training kiosks, non-sensitive internal informational sites.
    • Moderate baseline
      • Systems where compromise could significantly affect product quality, traceability, or operations, but not typically cause catastrophic safety or national security impacts.
      • Often includes plant-floor MES functions, batch records, maintenance systems, and many engineering tools.
      • Common default for mixed-use OT networks where some safety and compliance impact exists but is managed with layers of protection.
    • High baseline
      • Systems where compromise could plausibly lead to serious injury/fatality, major environmental damage, or severe regulatory or mission impact.
      • Includes safety-instrumented systems, systems controlling high-hazard processes, or systems processing highly sensitive defense or regulated data.
      • Often requires strict configuration control, segregation, enhanced monitoring, and strong assurance measures.

    In many regulated industrial environments, very few systems truly qualify for Low. Most business-critical and quality-relevant systems fall into Moderate, with a targeted subset at High.

    4. Apply a repeatable, documented decision process

    To avoid inconsistent or optimistic baseline selection, use a structured, auditable approach, for example:

    1. Define criteria: Adopt clear written definitions for Low, Moderate, and High aligned to your corporate risk framework and any mandated standard.
    2. Classify each system: For each application or asset (MES, QMS, SCADA, historian, PLC cells, document control, etc.), assess safety, quality, data sensitivity, and operational impact.
    3. Map impact to baseline: Use your organization’s mapping (for example, any system with potential severe safety impact or highly sensitive data defaults to High).
    4. Document justification: Record the rationale for the chosen baseline, including assumptions about safeguards, network segmentation, and procedures.
    5. Review through governance: Have security, quality, operations, and IT jointly review classifications, especially for systems proposed as Low.

    This documentation is critical in regulated settings where auditors and customers will challenge why controls differ between apparently similar systems.

    5. Consider brownfield and coexistence constraints

    In existing plants, you often cannot immediately raise every legacy system to a High baseline without creating significant validation, downtime, and integration burdens. Practical implications include:

    • Mixed baselines on shared infrastructure: High and Moderate systems often share networks and support teams with Low systems. Network design, zoning, and access control may need to meet the highest baseline present in a zone or cell.
    • Legacy systems that cannot meet High: Older PLCs, control panels, or homegrown apps may not realistically satisfy all High-baseline controls without hardware changes, wrappers, or compensating controls.
    • Validation and qualification cost: Increasing the baseline for a GxP or aerospace-relevant system cascades into more rigorous validation, documentation, and change control. This is sometimes more constraining than the technical implementation.
    • Downtime and cutover risk: Raising baselines often involves patching, segmentation, or architecture changes. In 24/7 plants, the operational windows may force phased or partial implementation.

    Because full replacement strategies are expensive and risky, a common approach is to classify systems, set target baselines, and then define a risk-based, multi-year roadmap to close gaps through upgrades or compensating controls instead of immediate wholesale change.

    6. When you should not choose the Low baseline

    In many organizations, “Low” is overused to reduce control overhead. Situations where Low is usually not appropriate include:

    • Systems that directly record, control, or release regulated product.
    • Any system involved in electronic records or signatures that support audit trails or batch/lot release decisions.
    • Systems storing or transferring export-controlled designs, CUI, or customer-proprietary technical data.
    • Supervisory systems where loss of visibility would impair safe operation or emergency response.

    If there is reasonable debate between Low and Moderate for a system with compliance or quality impact, most regulated organizations err on the side of Moderate to avoid difficult audit justifications later.

    7. Operational guidance for getting started

    If your organization has not yet formalized baseline use, a pragmatic approach is:

    1. Adopt a reference scheme (for example, NIST 800-53/800-82 or an IEC 62443-based profile) if corporate has not already mandated one.
    2. Define a short, plant-appropriate set of impact criteria in terms operations and quality leaders recognize.
    3. Run a pilot classification exercise on a small set of systems: one MES or SCADA instance, a QMS or LIMS, and a couple of OT cells.
    4. Refine criteria and decision rules based on where disagreements occur, then scale across the asset inventory.
    5. Integrate baseline selection into change control, system onboarding, and project approval workflows so it is not a one-time activity.

    Across all of this, the most important point is that baseline choice is a documented, risk-based decision tied to impact and obligations, not an ad hoc local preference. In regulated, long-lifecycle manufacturing, the cost of under-classifying a system usually surfaces later in audits, incidents, or difficult retrofit projects.

  • Which organizational levels should ISO 22400 KPIs be reported at?

    ISO 22400 does not prescribe a single, mandatory reporting level for KPIs. Instead, it defines standard KPI concepts, structures, and relationships that you can apply across different organizational levels. In regulated, multi-plant environments, ISO 22400 KPIs are typically reported at several layers, with different audiences and decisions in mind.

    Core levels where ISO 22400 KPIs are usually reported

    Most organizations that adopt ISO 22400 in a manufacturing setting use a tiered approach:

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    1. Equipment / cell / line level

      • Audience: Operators, line leads, maintenance.
      • Typical KPIs: Equipment availability, microstops, cycle time, NPT, OEE components, alarms, changeover time.
      • Purpose: Real-time control, troubleshooting, short-interval control, and root cause capture.
      • System reality: Often sourced directly from MES/SCADA/PLC and may not match ERP-level quantities without good integration and reconciliation rules.
    2. Work center / value stream / area level

      • Audience: Supervisors, process engineers, industrial engineering, maintenance planners.
      • Typical KPIs: Area OEE, throughput, WIP, rework rate, first pass yield, schedule adherence for the line or cell cluster.
      • Purpose: Bottleneck identification, staffing and changeover planning, cross-shift comparison, continuous improvement.
      • System reality: This is where MES, LIMS, QMS and manual logs often need to be reconciled; data models and time-bucketing rules matter.
    3. Plant / site level

      • Audience: Plant management, operations excellence, quality leadership, plant IT/OT.
      • Typical KPIs: Aggregated OEE, capacity utilization, on-time delivery versus plan, scrap and rework cost, customer escape rate, deviation volume, energy per unit.
      • Purpose: S&OP alignment, capital planning, labor planning, CI program tracking, risk and resilience discussions.
      • System reality: Requires consistent KPI definitions across areas and a governed interface between MES, ERP, QMS, and maintenance systems. Without this, plant-level KPIs are not trusted.
    4. Business unit / corporate level

      • Audience: Executive operations leadership, finance, program leadership.
      • Typical KPIs: Aggregated OEE or capacity indices, COPQ, OTIF, backlog risk, major program adherence, site comparison indices.
      • Purpose: Portfolio decisions, investment prioritization, risk assessments, cross-plant benchmarking.
      • System reality: Best handled through a data warehouse or analytics layer that can harmonize ISO 22400-based metrics from multiple, heterogeneous MES and ERP systems.

    How ISO 22400 helps across levels

    ISO 22400 is most valuable when you use it to standardize definitions and calculation logic across levels, rather than trying to force the same dashboard everywhere. For example:

    • OEE and its components (availability, performance, quality) use the same formulas at equipment, area, and plant levels, but with different aggregation windows and audiences.
    • NPT, downtime categories, and loss models are defined once, then applied consistently across lines and sites, improving comparability.
    • Traceability to source events (e.g., specific machines, orders, deviations) supports root cause analysis and regulated evidence requirements.

    The key is that while the calculation is standardized, the granularity and consumption are tailored to each level.

    Constraints and dependencies in brownfield environments

    In mixed-vendor, legacy environments, how far you can push ISO 22400 across levels depends on:

    • Data completeness and resolution: If some equipment lacks reliable run/stop or quality signals, line-level OEE will be uneven and plant-level rollups misleading.
    • Integration quality: Misaligned work order, routing, and time-bucket logic between MES, ERP, and QMS will produce conflicting KPIs at different levels.
    • Validation and change control: In regulated plants, changing KPI calculations or data sources may trigger revalidation, SOP updates, and retraining. This slows down “big bang” KPI redesigns.
    • Long equipment lifecycles: Older assets may never produce all the signals envisioned by ISO 22400. You may need proxies, manual classifications, or partial adoption.

    Because of these realities, full replacement of existing KPI frameworks with a pure ISO 22400 implementation rarely happens in one step. Most sites layer ISO 22400 concepts on top of existing systems and then converge definitions over time.

    Practical guidance: deciding which levels to start with

    When introducing or formalizing ISO 22400 KPIs, many regulated manufacturers follow a staged approach:

    • Start at equipment/line and work center level where operators and supervisors can act on short-interval metrics.
    • Stabilize definitions and governance for a small number of KPIs (for example, OEE, NPT, scrap rate) and validate them against existing reports.
    • Then extend to plant-level aggregation, ensuring that rollup logic is documented, version-controlled, and tested against historical data.
    • Only after plant-level adoption should you standardize corporate-level KPIs for cross-site comparison, to avoid driving decisions on noisy or inconsistent data.

    The question is therefore less “which single level” and more “which <strongcombination of levels” you can support with trustworthy, traceable data today, while planning for broader coverage later.

    Tradeoffs in reporting at multiple levels

    Reporting ISO 22400 KPIs across many levels introduces clear tradeoffs:

    • More levels: Better local decision-making and traceability, but higher burden on integration, master data, and governance.
    • Fewer levels: Easier to manage and validate, but weaker linkage between corporate metrics and shop-floor reality, and limited root cause capability.
    • Highly standardized KPIs: Strong comparability across lines and sites, but may require compromises for special processes or legacy equipment.
    • Locally customized KPIs: Better local fit, but weak cross-plant benchmarking and more confusion at senior levels.

    For regulated operations, a typical compromise is to standardize a small set of ISO 22400 KPIs end-to-end (equipment to corporate), while allowing additional local KPIs for specific technologies, programs, or customers.

  • What does 100% OEE mean?

    100% Overall Equipment Effectiveness (OEE) is a theoretical condition where, over the period you are measuring, the asset operates at its designed capability with no losses at all:

    • Availability = 100%: No unplanned downtime, no minor stops, and no unaccounted changeovers or setups. All planned production time is truly available.
    • Performance = 100%: The line runs at or above its defined ideal cycle time with no speed losses, micro-stops, or intentional speed reductions.
    • Quality = 100%: Every unit produced is conforming, with no scrap, no rework, and no test or hold failures.

    Because OEE is the product of these three factors, 100% OEE means:

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

    • You are using 100% of planned production time for actual running, and
    • During that time you are producing only good units at the maximum designed rate.

    Why 100% OEE is essentially never achieved in practice

    In real plants, especially regulated environments, some losses are unavoidable:

    • Availability losses: Preventive maintenance, calibrations, qualification runs, changeovers, line clearance, investigations, and periodic verifications all consume time.
    • Performance losses: Intentional speed derates to protect quality, operator learning curves, variable material behavior, and upstream/downstream constraints prevent sustained ideal-cycle operation.
    • Quality losses: Incoming variation, process drift, first-article issues, and periodic nonconformances mean some scrap, rework, or holds will occur.

    In high-consequence, long-lifecycle sectors (aerospace, medical devices, pharma, nuclear-adjacent suppliers), additional factors further limit practical OEE:

    • Validation and qualification runs that are not at full speed or do not count as saleable product.
    • Change control that slows implementation of improvements which could raise OEE.
    • Equipment design constraints on older assets that cannot reliably sustain nameplate speeds.

    As a result, using 100% OEE as a literal target is misleading and can incentivize people to manipulate definitions (for example, moving problem time into “unplanned” or “not in scope” buckets) rather than improving the process.

    What 100% OEE is useful for

    Even though 100% OEE is unrealistic in most brownfield, regulated plants, it is still useful as a reference point:

    • Conceptual benchmark: It clarifies that OEE is about three dimensions (availability, performance, quality) and that all three must be strong to approach world-class performance.
    • Gap analysis: Comparing current OEE to 100% highlights which loss category dominates. For example, 90% availability, 65% performance, 98% quality points you at speed and micro-stop issues first.
    • Scenario testing: You can model the impact of realistic improvements (e.g., raising availability from 85% to 92%) without implying you should or could get to 100%.

    Interpreting OEE in brownfield and regulated environments

    To make OEE meaningful in your context, you need to be precise about definitions and scope:

    • Define “planned production time” explicitly: Decide, document, and enforce what counts as planned versus unplanned stops. Activities such as validation runs, engineering trials, qualification lots, and mandatory cleanings need deliberate treatment.
    • Align cycle time definition: Make sure the “ideal” or “standard” cycle time reflects a validated, repeatable rate for the specific mix and process, not just the OEM brochure speed.
    • Quality definition and data source: Clarify whether you treat rework as a loss, how you handle scrap discovered downstream, and which system is the source of truth (MES, QMS, test systems).
    • Traceability and auditability: In regulated environments, your OEE calculations and loss codes should be reconstructable from underlying events and logs. This is important for investigations and for defending operational decisions during audits.

    In most mature operations, leadership chooses a realistic OEE range by asset type, product mix, and regulatory demands. World-class figures often cited in generic literature (e.g., 85% OEE) are not universally applicable; a complex, validated cell running low-volume, high-mix work under strict controls may have a fundamentally different ceiling than a high-volume consumer packaging line.

    Coexistence with existing systems

    Achieving high, credible OEE does not require replacing existing MES, ERP, SCADA, or QMS systems. In brownfield environments:

    • Data often comes from multiple systems: Availability from equipment/SCADA, quality from MES/QMS, performance from counters or PLCs. Integration quality will limit how close you can get to real-time, accurate OEE.
    • Full OEE “platform” replacements carry risk: Replacing existing systems purely for OEE can create validation workload, integration debt, and downtime that outweighs the benefits. Incremental integration and reporting layers are more common.
    • Consistency beats sophistication: A simple OEE calculation used consistently across assets, backed by traceable event data, is more valuable than an elaborate but poorly trusted metric.

    In summary, 100% OEE represents a theoretical perfection point: only good parts, as fast as designed, with no stops. In regulated, long-lifecycle environments, you should treat it as a conceptual upper bound, not a realistic operational target, and focus on transparent definitions and incremental loss reduction instead.

  • How can we estimate the cost of a non-conformance in aerospace production?

    There is no single universal formula for the cost of a non-conformance in aerospace. What you can build is a structured, repeatable model that uses your existing MES/ERP/QMS data and a set of assumptions. The goal is not perfect accuracy, but a consistent way to compare and prioritize issues and investments.

    1. Start with a clear cost-of-poor-quality structure

    Most aerospace plants use a COPQ-style breakdown as a starting point:

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

    • Internal failure costs: scrap, rework, MRB, inspections triggered by the NCR.
    • External failure costs: returns, concessions, field repairs, penalties, program reputation impact.
    • Appraisal/containment costs: extra inspections, special audits, temporary checks put in place to contain the issue.
    • Prevention costs (optional in this estimate): engineering changes, training, fixture redesigns. These are often tracked separately from the NCR itself.

    Decide which buckets you will always include in an NCR cost estimate and make that policy explicit. In regulated environments, consistency and traceability of assumptions matter more than precision on any one event.

    2. Quantify the direct "visible" costs first

    Direct costs are typically the easiest to estimate and to pull from existing systems.

    • Scrap material cost
      Use your ERP/finance item cost: unit cost × quantity scrapped. Include special processes or coatings if they cannot be salvaged.
      Dependencies: accurate BOM costs and scrap booking practices.
    • Rework labor
      Estimate hours spent on rework × loaded labor rate (wages + burden). Hours should include:
      • Operators doing rework
      • Inspectors re-verifying
      • Setups required only because of the NCR

      Dependencies: time-tracking discipline, realistic standard times for rework operations, or at least a documented estimating guideline.

    • Rework materials and consumables
      Special tooling, replacement components, consumables (abrasives, chemicals, hardware) that are used only because of the NCR. These are usually small per event but can be significant for complex assemblies.
    • MRB / engineering / quality analysis time
      Estimate time spent by MRB, quality, and engineering on:
      • Dispositioning the NCR
      • Risk assessments
      • RCCA / 8D or similar activities attributable to this issue

      Multiply total hours by appropriate loaded rates or by a standard blended rate for "technical problem-solving hours."

    For many plants, putting in place a simple template for these four elements already improves NCR cost visibility dramatically.

    3. Add internal disruption and schedule impact where material

    Internal disruption is harder to quantify, but for significant NCRs it often dominates the actual economic impact.

    • Line stoppage / lost capacity
      When an NCR halts a cell, line, or key machine, estimate:
      • Duration of effective stoppage or slowdown
      • Typical value-add per hour (often from OEE, revenue per capacity hour, or a proxy)

      Cost impact ≈ hours of lost capacity × value per capacity hour.
      Constraint: This is a model, not a GAAP number. Make its use explicit and use it mostly for prioritization.

    • Expediting and rescheduling
      Include extra changeovers, overtime, or premium freight specifically caused by the NCR. These are often visible already as separate cost codes in ERP or finance if your plant uses them.
    • Work-in-process disruption
      When the NCR affects assemblies already in flow, include:
      • Extra handling / segregation operations
      • Additional inventory days in WIP (if you cost inventory holding)

      These are often rough-order estimates unless you have a mature value-stream accounting model.

    4. Include external and customer-facing costs when applicable

    In aerospace, the risk of external non-conformance is often far more consequential than internal scrap. You should distinguish between:

    • Confirmed external events (e.g., field finding, return, or OEM escape):
      • Direct repair or replacement cost (parts, labor, travel if field repair)
      • Customer charges, fees, or penalties documented in contracts
      • Additional inspections mandated by customer or regulator
    • Potential external impact (e.g., escapes caught before flight or before delivery):
      • Recall or containment activities in downstream plants or depots
      • Data reviews and documentation updates required to demonstrate continued airworthiness or compliance

    Many organizations choose to separate "accounting" cost from "risk" cost. For example:

    • Use actuals (documented invoices, chargebacks, travel expenses) for the NCR cost record.
    • Track potential or avoided cost in a separate risk/lessons-learned log, rather than in the NCR cost field itself.

    This avoids mixing speculative risk numbers into financial reporting while still acknowledging the real exposure.

    5. Use your existing systems, but accept brownfield limits

    In most aerospace plants, NCR cost data is spread across multiple systems:

    • ERP: material cost, scrap postings, labor bookings, freight, overtime codes.
    • MES / digital travelers: where and when the defect occurred, rework operations, routing changes.
    • QMS / NCR system: MRB decisions, defect classification, containment actions, 8D / RCCA records.
    • PLM / change control: engineering changes, redesigned tooling or process updates.

    Replacing these systems outright just to improve NCR costing is rarely realistic in regulated, long-lifecycle environments due to validation burden, qualification, and downtime risk. A more practical approach is:

    • Define a standard NCR cost model (what to include, at what level of precision).
    • Implement lightweight integrations or reports that pull a minimal data set from ERP/MES into the NCR record.
    • Use standard fields and picklists in the QMS or MES NCR module so data can be analyzed over time.
    • Validate only the data flows that matter for decisions and audit trails, not a fully automated costing engine from day one.

    Expect some manual inputs to remain, especially for engineering and MRB labor time, disruption estimates, and special customer actions.

    6. Make assumptions explicit and repeatable

    Whatever model you use, document it. In regulated aerospace environments, auditors and customers will often ask "how did you come up with these cost numbers?" You should be able to show:

    • Which cost elements must be filled out for every NCR.
    • Which elements are only for major NCRs (e.g., line-stoppage cost, external impact).
    • Standard rates and rules, such as:
      • Loaded labor rate assumptions by role
      • Default time estimates for typical MRB review steps, if actual time is not tracked
      • How you assign disruption cost to a specific NCR when many issues occurred in a period
    • Who can override or adjust estimates and how changes are documented.

    This both improves internal decision-making and reduces friction during audits and customer reviews.

    7. Use NCR cost data for trends and prioritization, not just "true cost"

    Even with a disciplined approach, single-event NCR cost numbers will always be approximations. They are most powerful when used in aggregate:

    • Identify top cost drivers by defect type, product, process, supplier, or cell.
    • Compare internal vs external failure mix and track shift over time.
    • Build a business case for automation, fixturing, digital work instructions, or supplier development using trend data rather than anecdote.

    Be careful not to over-rotate on a single dramatic NCR cost. Focus on patterns supported by consistent data.

    8. Practical starting template for an aerospace NCR

    If you do not yet have a structured method, a simple, implementable template for each NCR is:

    1. Scrap cost: material + special process cost.
    2. Rework labor cost: rework hours × loaded rate.
    3. Rework material / tooling cost: parts and consumables.
    4. MRB / engineering / quality time: hours × blended technical rate.
    5. Disruption cost (if applicable): model-based estimate of lost capacity or premium freight.
    6. External / customer cost (if applicable): documented charges, returns, travel, or mandated inspections.

    Sum 1–4 for a baseline internal NCR cost. Add 5–6 for full impact on significant events. Use clear flags in your system so you can analyze "baseline" and "full impact" separately.

    9. Dependencies and limitations to acknowledge

    When communicating NCR cost numbers internally, be transparent about:

    • Data quality limits: missing labor bookings, inaccurate routings, or inconsistent scrap coding will reduce precision.
    • Scope decisions: whether you exclude prevention costs or long-term reputation/contract impacts.
    • Attribution challenges: when multiple issues affect the same schedule slip or disruption, cost allocation is a management decision, not a precise science.
    • Validation boundaries: which parts of your costing approach are validated or relied on in formal reporting versus used only for operational decision support.

    Being explicit about these constraints usually improves confidence in the data, because stakeholders understand what the numbers are and are not.

  • 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.

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

    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.

  • Can we integrate ISO 27001 with our existing AS9100 system?

    Yes. ISO 27001 can be integrated with an existing AS9100-based management system, and in aerospace and defense this is common. But it is not a simple overlay. The level of effort, risk, and benefit depend heavily on how your current AS9100 system is designed and implemented.

    What “integration” typically means in this context

    In practice, integration usually means:

    • Using a single, shared management system for quality and information security (common policies, governance, and document control).
    • Aligning risk, nonconformance, audit, and corrective action processes so they work for both standards.
    • Avoiding conflicting requirements across QMS, IT, and security procedures.
    • Consolidating evidence and records to support both AS9100 and ISO 27001 audits.

    It does not mean ISO 27001 is automatically covered by AS9100, or that adding some cybersecurity wording to existing procedures is sufficient.

    Where ISO 27001 and AS9100 align

    ISO 27001 and AS9100 both follow the Annex SL high-level structure. That gives you natural integration points:

    • Context, leadership, planning: You can maintain a single set of top-level policies, objectives, and management review that considers both product quality and information security.
    • Risk and opportunity: You can extend your existing risk processes to cover information security risks, provided your methods are robust enough for cyber and data risks.
    • Support and operation: Training, competence, communication, and document control can usually be shared across both standards.
    • Performance evaluation and improvement: Internal audit, KPIs, nonconformity, and CAPA can be expanded to include information security.

    Where you already have a reasonably mature, process-based AS9100 system, this alignment can significantly reduce duplication.

    Key gaps you will need to address

    Even with alignment, ISO 27001 introduces requirements that go beyond a typical AS9100 QMS:

    • Information security risk treatment: ISO 27001 requires defined risk assessment and treatment processes focused on information assets, threats, vulnerabilities, and control selection. Your AS9100 risk tools (e.g., FMEA, program risk registers) may not be sufficient without adaptation.
    • ISMS scope definition: You must clearly define the scope and boundaries of the Information Security Management System (ISMS), which may not match your existing QMS scope exactly (for example, including specific IT systems, networks, and data centers).
    • Annex A / control framework: Implementing and maintaining a control set (technical, physical, and organizational) and showing traceability from risks to controls and to evidence. This is usually the biggest lift.
    • IT and OT involvement: ISO 27001 requires active involvement from IT and, often, OT and engineering for production systems. This is a cultural and governance change if your AS9100 system is driven mainly by quality and operations.
    • Incident management for information security: You may need to expand beyond production nonconformance and safety events to include security incidents, data breaches, and near misses.

    Integration options and tradeoffs

    There are several ways to integrate, each with tradeoffs:

    1. Single, fully integrated management system

    Approach: Extend your existing QMS architecture (policies, procedures, templates, IT tools) to include ISO 27001.

    • Advantages: One set of processes, one document control system, easier cross-standard audits, less duplication long term.
    • Risks/constraints: Higher design complexity; more stakeholders (IT, security, engineering) embedded into quality-driven processes; harder to change without broad impact; more regression risk when you update anything.
    • Brownfield impact: You may need to retrofit legacy workflows and forms, and you can be constrained by old QMS tools or MES/PLM/ERP integrations that were never designed with security in mind.

    2. Loosely coupled ISMS alongside the QMS

    Approach: Maintain a distinct ISO 27001 ISMS, but align key elements (governance, risk, internal audit, CAPA) with AS9100 where practical.

    • Advantages: Lower disruption to existing AS9100 system; allows security and IT to move at a different pace; easier if you already have separate security tooling (GRC, ticketing, SIEM).
    • Risks/constraints: Risk of conflicting procedures; duplicate training and audits; more effort to keep policy and risk decisions consistent; more complex to demonstrate integrated governance to customers and auditors.
    • Brownfield impact: Often easier in highly constrained plants where changing validated QMS or MES tooling is difficult, but requires disciplined interfaces between QMS and ISMS processes.

    3. Incremental, process-by-process integration

    Approach: Start by integrating specific processes that naturally overlap (e.g., document control, internal audit, CAPA), then expand.

    • Advantages: Lower implementation risk; easier change control; early wins without a system-wide redesign.
    • Risks/constraints: Temporarily messy hybrid state; need clear mapping to show auditors how AS9100 and ISO 27001 requirements are met during the transition.
    • Brownfield impact: Usually the most realistic approach when you have long-qualified equipment and software that cannot be dramatically reconfigured.

    Impact on existing tools and records

    In regulated, long-lifecycle environments you rarely replace QMS, MES, ERP, or PLM outright just to support ISO 27001. Instead you:

    • Extend your document control system to manage security policies, standards, and procedures under the same change control discipline.
    • Reuse your CAPA / nonconformance system for security incidents and corrective actions, possibly with new categories and workflows.
    • Integrate with IT or security tools (e.g., ticketing, vulnerability scanners, SIEM) through interfaces or manual evidence capture, acknowledging integration limitations.
    • Align configuration management for critical systems so that changes affecting information security go through appropriate review and approval.

    Full replacement of core systems just to “integrate” ISO 27001 usually fails in aerospace-grade environments because of validation and qualification costs, constrained downtime, and the need to preserve historical traceability.

    Governance, ownership, and change control

    Effective integration depends more on governance than on documentation templates:

    • Shared leadership: Clarify how quality, operations, IT, and information security share responsibilities for the integrated system. RACI conflicts are a common failure mode.
    • Common change control: Changes to IT/OT security controls can have quality, safety, and regulatory implications. Integrate change review so that security and quality impacts are assessed together.
    • Traceability: Maintain clear mappings from AS9100 clauses and ISO 27001 clauses to internal processes, owners, and records. This is essential for audits and for managing long-lived systems.

    Typical pitfalls and failure modes

    • Superficial integration: Renaming existing QMS procedures with “information security” language but not addressing underlying asset inventories, access control, or technical safeguards.
    • Overloading quality: Expecting the quality team to own ISO 27001 without sufficient IT and security involvement.
    • Tool-centric projects: Buying a security or GRC tool and assuming that equates to an integrated system; auditors will still expect coherent processes and evidence across both standards.
    • Neglecting OT and production systems: Treating ISO 27001 as an IT-only exercise while leaving production networks, test stands, and legacy equipment outside of scope without a defensible rationale.

    Practical starting steps

    If you decide to integrate ISO 27001 with your AS9100 system, a low-risk sequence is:

    1. Define and approve ISMS scope relative to your existing AS9100 scope.
    2. Perform a gap assessment against ISO 27001 requirements and Annex A controls, mapped to your current QMS processes and records.
    3. Decide your integration pattern (single system, side-by-side with alignment, or incremental) based on process maturity and tooling constraints.
    4. Align top-level policies, management review, and risk governance first, then drill down into detailed procedures and technical controls.
    5. Plan changes with formal change control and validation/qualification considerations, especially where IT/OT changes can impact production or regulated data.

    This approach respects existing AS9100 commitments while adding information security discipline in a controlled, auditable way.

  • How do we manage NCM differently for serialized versus lot-controlled parts?

    You do not manage them the same way in practice, even if the NCR workflow and approval steps look similar on paper.

    For serialized parts, NCM is usually handled at the individual unit level because each item has its own identity, history, and status. For lot-controlled parts, NCM is usually handled at the lot, batch, or sub-lot level unless you can prove which specific units are affected and which are not.

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

    What changes between serialized and lot-controlled parts

    • Containment scope: Serialized parts let you quarantine exact serial numbers. Lot-controlled parts often require holding the full lot, or a broader suspect population, until impact is understood.

    • Traceability basis: Serialized parts rely on unit history. Lot-controlled parts rely on lot genealogy, material segmentation, process step records, and sampling rationale.

    • Disposition precision: Serialized parts can be reworked, scrapped, accepted under deviation, or returned individually. Lot-controlled parts may need lot split, regrade, additional inspection, rework of the full lot, or partial scrap if segregation is defensible.

    • Risk of escape: For lot-controlled parts, the main risk is false segregation. If your records cannot prove separation, narrowing the affected population may not be credible.

    • Evidence burden: Serialized parts usually need unit-specific evidence. Lot-controlled parts need evidence that the lot definition, sampling approach, and segregation logic are valid and consistently executed.

    Serialized parts

    For serialized items, the normal expectation is to preserve a complete chain from the nonconformance to the exact affected serial numbers, their current location, prior operations, components, inspections, and any downstream assemblies they entered.

    In practice, that usually means:

    • place the affected serial numbers on hold immediately

    • prevent further movement, consumption, shipment, or installation of those units

    • record defect details against each serial number or against a common NCR linked to all affected serials

    • capture disposition by serial number if outcomes differ between units

    • maintain as-reworked or as-scrapped history without overwriting the original event

    • check upward and downward genealogy if the part is already consumed into a higher assembly

    The benefit is precision. The tradeoff is administrative load and system discipline. If operators can bypass scans, if serial numbers are reused or mislabeled, or if MES and ERP status are not synchronized, serialized control can look strong while still producing gaps.

    Lot-controlled parts

    For lot-controlled material, the first question is not just what is nonconforming, but what population is credibly suspect.

    That usually means you need to determine:

    • the exact lot or batch definition in use at the time

    • whether the issue is uniform across the lot or limited to a time window, machine state, cavity, tool, operator, or incoming material segment

    • whether the lot was ever split, merged, repacked, relabeled, or partially consumed

    • whether downstream genealogy can identify where the affected lot was used

    If you cannot answer those questions reliably, the conservative path is often to hold the entire lot and any downstream material produced from it. That is operationally expensive, but narrower containment without supporting evidence creates obvious traceability and audit problems.

    Lot-controlled NCM often requires extra decisions that serialized flow does not, including:

    • whether to create sub-lots after investigation

    • whether additional inspection can separate conforming from nonconforming material

    • whether a statistically based release is actually appropriate for the defect mode

    • whether rework changes lot identity, status, or documentation requirements

    A common failure mode is using sampling logic to justify release when the defect mechanism is not random. If the issue is tied to a specific machine condition, setup state, heat lot, or process excursion, sampling may not protect you.

    System and data implications

    The process difference is not only procedural. It is also a data-model difference.

    Serialized NCM works best when your systems can track individual-unit status and genealogy across receiving, production, inspection, rework, inventory, and shipment. Lot-controlled NCM depends more heavily on accurate lot definitions, split and merge controls, quantity integrity, and consumption genealogy.

    In brownfield plants, this usually spans multiple systems. A QMS may own the NCR, ERP may own inventory status, MES may own execution history, and spreadsheets may still be used for segregation or rework queues. That coexistence can work, but only if status changes, identifiers, and timestamps stay aligned. If they do not, investigators end up reconciling records manually, which slows containment and weakens evidence.

    That is one reason full replacement programs often struggle in regulated environments. Rebuilding serialization, lot genealogy, dispositions, and evidence trails across MES, ERP, PLM, and QMS is not just an IT exercise. It carries validation effort, downtime risk, retraining burden, and requalification implications that many plants underestimate.

    Practical policy difference

    A workable rule is:

    • Serialized: contain, investigate, disposition, and release by individual serial number whenever the unit identity is maintained.

    • Lot-controlled: contain and investigate by suspect population first, then narrow to sub-lot or unit level only if your records and physical segregation controls can support that decision.

    If your site cannot reliably prove segregation, do not assume you can manage lot-controlled material with serial-like precision.

    So the answer is yes: NCM should be managed differently for serialized versus lot-controlled parts, mainly in containment scope, evidence model, disposition granularity, and genealogy expectations. The underlying workflow may be shared, but the traceability logic is not.

  • What are NIST security controls?

    NIST security controls are a catalog of standardized security and privacy safeguards defined primarily in NIST Special Publication 800-53 and related guidance. They describe what protections an information system and its environment should have, not a specific product or tool.

    What NIST security controls cover

    The controls are grouped into control families that span technical, administrative, and physical protections, such as:

    In practice, this connects to industrial security evidence when teams need to turn the answer into repeatable execution habits.

    • Access control (who can do what, where, and when)
    • Audit and accountability (logging, monitoring, traceability)
    • Configuration management (baselines, change control, approvals)
    • Identification and authentication (accounts, credentials, MFA)
    • System and communications protection (network security, encryption)
    • System and information integrity (malware protection, patching)
    • Contingency planning (backup, recovery, continuity)
    • Physical and environmental protection (facility access, equipment protection)
    • Incident response (detection, triage, containment, lessons learned)
    • Risk assessment and security assessment (periodic evaluation, testing)

    Each family contains individual controls and control enhancements that describe specific outcomes to achieve (for example, unique user identification, least privilege, or time-synchronized logs).

    Key references

    • NIST SP 800-53: Main catalog of security and privacy controls for federal information systems and many critical infrastructure environments.
    • NIST SP 800-53B: Baselines (Low, Moderate, High) that define which controls generally apply at each impact level.
    • NIST SP 800-82: Guidance on applying controls in industrial control system and OT environments.
    • NIST SP 800-171: A subset/interpretation of controls for protecting controlled unclassified information in nonfederal systems (often relevant to aerospace and defense suppliers).

    How NIST controls are used

    Organizations typically do not implement every control as written. Instead they:

    1. Determine the system or environment scope and impact level.
    2. Select a starting control baseline (for example, Moderate from SP 800-53B or the set from 800-171).
    3. Tailor controls based on risk, regulatory obligations, and practical constraints (for example, legacy equipment that cannot be patched).
    4. Implement the controls using a mix of processes, technology, and governance.
    5. Document, test, and periodically assess that the controls are effective.

    In regulated manufacturing, this work needs to align with existing change control, validation, and configuration management processes so that control implementations are traceable and auditable over the long life of equipment and systems.

    Brownfield and OT realities

    In industrial and OT environments, NIST security controls are often applied partially and in layered form because:

    • Legacy PLCs, DCS, and older MES/SCADA may not support modern controls like strong encryption or fine-grained access control.
    • Downtime for upgrades is limited and sometimes heavily constrained by production and qualification schedules.
    • System replacements can trigger extensive revalidation and requalification, making full rip-and-replace approaches high risk and high cost.
    • Responsibility is shared across IT, OT, quality, and operations, which can slow decision making and implementation.

    As a result, organizations often implement NIST controls through compensating measures, such as network zoning and segmentation, tightly controlled remote access, enhanced monitoring, and procedural controls where technical controls are not feasible on legacy assets.

    Limits and what NIST controls do not provide

    • They are not a product or certification. Implementing them does not guarantee a particular audit outcome.
    • They do not remove the need for risk assessment, engineering judgment, and safety analysis in OT environments.
    • They must be tailored and validated in the context of your specific systems, integrations, and regulatory obligations.
    • They do not guarantee that a specific plant or vendor configuration will be secure; effectiveness depends heavily on correct implementation, maintenance, and monitoring.

    Used correctly, NIST security controls provide a structured, widely recognized framework for defining and assessing security expectations across your IT and OT systems, including MES, ERP, QMS, and plant-floor assets. They are a foundation for consistent policies and evidence, not a guarantee of compliance or safety.

  • Which clauses in AS9100 Rev D focus on product safety?

    AS9100 Rev D treats product safety as a cross-cutting requirement. There is one dedicated clause plus several closely related clauses that most auditors will expect you to connect in your quality management system.

    Primary clause explicitly focused on product safety

    The main clause is:

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

    • 8.1.3 Product safety – Requires the organization to plan, implement, and control processes needed to assure product safety during the entire life cycle, as appropriate to the organization and the product. This includes defining responsibilities, managing safety-related events, and maintaining safety-related information.

    Key supporting clauses that impact product safety

    While 8.1.3 is the explicit product safety clause, several other clauses are directly relevant and usually need to be aligned in procedures, training, and records:

    • 4.1 & 4.2 (Context of the organization and interested parties) – Safety expectations from customers, regulators, and end users should be reflected in your QMS scope and risk priorities.
    • 5.1.1 & 5.1.2 (Leadership and customer focus) – Top management is expected to demonstrate commitment to product safety as part of customer and regulatory focus.
    • 6.1 (Actions to address risks and opportunities) – Product-safety-related risks should be identified, evaluated, and mitigated. In practice, this often links to FMEA, hazard analyses, and special characteristics.
    • 6.2 (Quality objectives and planning) – Safety-critical performance (e.g., escape defects, special processes, escapes on critical items) can be reflected in objectives and KPIs.
    • 7.2 (Competence) – Requires you to ensure competence for personnel whose work affects product safety, including training and authorization for safety-critical tasks.
    • 7.5 (Documented information) – Controls safety-relevant documents and records, including work instructions, inspection plans, and configuration baselines for safety-critical items.
    • 8.1.1 (Operational risk management) – Aerospace-specific requirement to manage operational risks, including those that influence product safety (e.g., process changes, capacity constraints, special process risks).
    • 8.1.2 (Configuration management) – Ensures that safety-critical configurations are defined, controlled, and traceable. Mismanaged configuration is a common safety failure mode in complex, long-life aerospace products.
    • 8.2 (Requirements for products and services) – Ensures that safety-related requirements from contracts, drawings, specifications, and regulations are identified, reviewed, and flowed down to operations and suppliers.
    • 8.3 (Design and development of products and services) – Where design is in scope, this clause drives systematic identification and control of safety requirements, verification, and validation, including management of changes affecting safety.
    • 8.4 (Control of externally provided processes, products, and services) – Requires safety-related requirements and controls to be flowed down to and monitored at suppliers and special process providers.
    • 8.5.1 (Control of production and service provision) – Includes the use of suitable equipment, controlled conditions, and documented instructions, especially for safety-critical operations and special processes.
    • 8.5.2 (Identification and traceability) – Enables tracking of safety-critical parts, materials, and configurations to support investigation and containment when safety concerns arise.
    • 8.5.6 (Control of changes) – Requires evaluation and control of process and product changes, including assessment of impact on product safety and re-approval where needed.
    • 8.6 (Release of products and services) – Ensures that all planned inspections, tests, and approvals related to safety requirements are complete and acceptable prior to release.
    • 8.7 (Control of nonconforming outputs) – Addresses identification, segregation, disposition, and risk assessment of nonconformances that could affect product safety, including customer and regulatory notification where applicable.
    • 9.1.1 & 9.1.3 (Monitoring, measurement, analysis and evaluation) – Data on safety-related defects, escapes, and events should be monitored and used for decision-making.
    • 10.2 (Nonconformity and corrective action) – Requires structured investigation of nonconformities that affect or could affect product safety, and verification that corrective actions are effective.
    • 10.3 (Continual improvement) – Supports ongoing reduction of safety-related risks through process and system improvements.

    Clauses linked to human factors and reporting culture

    AS9100 Rev D also ties product safety to human factors and reporting behavior:

    • 7.3 (Awareness) – Requires personnel to be aware of their contribution to product safety, including the impact of nonconformity and the importance of ethical behavior.
    • 7.4 (Communication) – Includes internal and external communication of safety-related information, including how safety issues are escalated.
    • 10.2 (Nonconformity and corrective action) – Often used to formalize safety reporting, trend analysis, and escalation of systemic safety concerns.

    Implementation notes for regulated, long-lifecycle environments

    The specific clauses are fixed, but how they apply in your environment depends on scope (design vs build-to-print), legacy QMS structure, and system integration. In brownfield operations with older ERP/MES/QMS stacks, product safety controls usually span several systems and paper-based workflows. Trying to implement product safety as an isolated “module” in a single new system often fails because:

    • Configuration management, nonconformance, and change control are already distributed across multiple validated tools and paper forms.
    • Revalidating or replacing core systems to centralize product safety can trigger significant downtime, requalification, and retraining risk.
    • Auditability and traceability expectations typically require incremental changes with strong change control, not wholesale system swaps.

    Most organizations address AS9100 Rev D product safety expectations by tightening procedures, clarifying responsibilities, improving cross-system traceability, and adding targeted digital controls on top of existing infrastructure, rather than attempting a full replacement of legacy platforms.