Connect981 – Content Dev

FAQ Tag: change control

  • How does an execution layer reduce risk during safety-critical engineering changes?

    An execution layer reduces risk during safety-critical engineering changes by tightly controlling how, when, and by whom new configurations are executed on the shop floor. It does not remove the need for robust engineering, quality, and configuration control, but it can significantly reduce the operational and human-factor risks associated with putting changes into production.

    1. Enforcing the correct revision at the point of use

    In safety-critical environments, the primary operational risk is often using the wrong revision of a design, routing, or instruction set. An execution layer can:

    In practice, this connects to work orders and digital travelers when teams need to turn the answer into repeatable execution habits.

    • Bind work orders, lots, and serial numbers to specific, approved engineering change revisions.
    • Prevent release of work if the referenced BOM, routing, or work instruction is obsolete or not yet effective.
    • Apply effective dates and configuration rules so the right version is used for each unit or batch.
    • Surface only the current, approved digital work instructions to the operator, reducing reliance on tribal knowledge or printed copies.

    The effectiveness of this depends on accurate and timely data from PLM, ERP, and QMS, and on validated interfaces that keep revision status synchronized.

    2. Controlling who can execute safety-critical steps

    Safety-critical changes often come with new skills, tools, or certifications. An execution layer supports:

    • Role and competency-based access control for specific operations and steps.
    • Enforcement that only qualified operators, inspectors, or special process staff can execute or sign off high-risk steps.
    • Electronic signoffs with user identity, timestamp, and revision context captured for each critical operation.

    This reduces the risk of unqualified personnel executing changed processes, but it requires a maintained skills matrix and integration with HR or training records, plus periodic audit of role mappings.

    3. Driving correct sequencing and interlocks

    Many failures around engineering changes occur when steps are performed out of sequence or prerequisites are skipped. An execution layer can:

    • Enforce process flow so operators cannot move to downstream steps until required checks or measurements are completed.
    • Add interlocks tied to new safety-critical steps, such as torque verification, leak tests, or functional checks introduced by the change.
    • Conditionally branch workflows based on configuration, serial, or test results, avoiding manual interpretation of complex change bulletins.

    This reduces reliance on memory and informal workarounds but depends on accurate modeling of routes and decision logic and on careful change control when flows are updated.

    4. Embedding validation, checks, and data capture

    When engineering changes alter fit, function, or safety margins, data collection and verification must follow the updated requirements. An execution layer can:

    • Require capture of new parameters, measurement ranges, and evidence (e.g., photos, tool IDs, gage IDs) aligned with the change.
    • Validate entries against specification limits in real time, preventing continuation if values are out of tolerance for the new design.
    • Ensure calibration and tool control rules are followed when new tools or fixtures are introduced.

    This helps avoid silent deviations but is only as strong as the underlying specification data, gage management processes, and the validation of the execution logic itself.

    5. Managing deviations, concessions, and controlled experiments

    Safety-critical changes often start with limited pilots, controlled builds, or conditional approvals. An execution layer supports structured risk handling by:

    • Routing specific orders or serials through special pilot flows with additional inspections or tests.
    • Linking temporary deviations, waivers, or concessions to affected work orders, and enforcing associated conditions.
    • Capturing nonconformances in context if the new design or process behaves unexpectedly, with traceability back to the underlying change.

    This reduces the risk of uncontrolled experiments on production hardware, but it requires disciplined configuration of special routes and clear sunset rules for temporary flows.

    6. Providing full traceability of what was built, how, and under which change

    When failures occur in the field, or during qualification, the ability to reconstruct exactly which revision and process were used is critical. An execution layer improves traceability by:

    • Linking each unit or batch to the specific engineering change, work instructions, tooling, and parameters used during manufacture.
    • Recording operator identities, signoffs, measurement data, and test results tied to the effective revision at that time.
    • Maintaining an auditable history of when a change went live, where it was applied, and when it was superseded.

    This does not automatically deliver compliance, but it provides the evidence needed for robust root cause analysis and formal investigations when something goes wrong.

    7. Coordinating across brownfield systems

    In most regulated plants, the execution layer must coexist with existing PLM, ERP, QMS, and sometimes legacy MES, along with paper-based work instructions. Risk reduction depends on:

    • Reliable integration with PLM for controlled release of engineering changes and status updates.
    • Clear ownership of the “source of truth” for parts, BOMs, routings, and instructions, avoiding conflicting versions across systems.
    • Well-defined cutover procedures so old and new revisions are not run in parallel without proper segregation.

    Attempting full system replacement during major engineering changes often increases risk because of validation burden, downtime, and integration complexity. A more practical approach is layering execution control on top of existing systems, then migrating specific functions over time under strict change control.

    8. Supporting staged rollout and rollback of changes

    Engineering changes can fail or have unintended side effects. An execution layer can reduce associated risk by:

    • Allowing staged rollout by line, cell, program, or facility, instead of a big-bang cutover.
    • Tracking adoption progress and issues in near real time through exception and nonconformance data.
    • Supporting controlled rollback plans when a change must be paused or reversed, with clear rules about which units are affected and how to handle them.

    This capability still relies on well-defined engineering and quality governance for go/no-go decisions and for managing partial builds or rework.

    9. Capturing operator feedback and surfacing weak signals

    Even well-modeled engineering changes can introduce subtle risks that only appear in execution. An execution layer can:

    • Provide structured channels for operators to flag unclear instructions, unsafe conditions, or unexpected behavior related to the new process.
    • Aggregate these signals with NCRs and near-miss data to help engineering and quality teams refine the change.
    • Feed into continuous improvement and formal risk assessments without relying on informal communication paths.

    This does not replace formal hazard analyses, FMEA, or safety cases, but it improves practical feedback loops around implementation.

    10. Constraints and what an execution layer cannot do

    Even with a strong execution layer, several risk areas remain outside its direct control:

    • It cannot guarantee the correctness of the engineering change itself; design and analysis quality remain separate responsibilities.
    • It does not, by itself, ensure regulatory or certification outcomes. Evidence and behavior must still meet external expectations.
    • It must be qualified and validated like any other system used in regulated, safety-critical environments.
    • If integrations with PLM or QMS are weak, out-of-date, or manually maintained, the execution layer can enforce the wrong information efficiently.

    In practice, the risk reduction comes from combining a validated execution layer with disciplined configuration management, change control, training, and continuous monitoring.

  • What is the role of the OASIS database in supplier control?

    The OASIS database, managed by the International Aerospace Quality Group (IAQG), is a centralized directory of organizations certified to AS9100-series standards and the certification bodies and auditors that oversee them. In supplier control, its role is to provide trusted, standardized certification and audit information that you can reference as one input to your supplier approval, monitoring, and risk management processes.

    How OASIS supports supplier control

    In practical terms, most aerospace and defense organizations use OASIS in supplier control for:

    In practice, this connects to supplier and supply chain coordination when teams need to turn the answer into repeatable execution habits.

    • Certification verification: Confirming whether a current or candidate supplier holds an active AS9100-series certification, who their certification body (CB) is, and the validity dates.
    • Scope and site coverage: Checking which sites are certified and what activities, products, or services are covered by the certificate scope, so you can align it with the work you intend to place.
    • Audit and nonconformity visibility: Reviewing high-level audit results, including any major nonconformities and whether they have been closed, to inform risk assessments and surveillance planning.
    • Supplier onboarding checks: Using OASIS information as part of due diligence before approving a supplier, especially for higher-risk product categories or special processes.
    • Ongoing surveillance: Periodically confirming that a supplier’s certification remains valid and that there are no significant unresolved issues noted by their CB.

    These uses support a more evidence-based supplier control process, and they reduce reliance on static copies of certificates that can be outdated or incomplete.

    What OASIS does not do in supplier control

    It is important to be clear about what OASIS does not provide. Relying on it alone is not sufficient for robust supplier control in regulated, long-lifecycle environments:

    • No guarantee of performance: OASIS records do not guarantee delivery performance, product quality, or process capability. You still need your own metrics, such as OTD, PPM, NCR rates, and escape severity.
    • No replacement for supplier qualification: OASIS is not a substitute for your internal qualification activities (e.g., technical assessments, process capability reviews, first article inspection, or special process approvals).
    • No detailed process or product data: The database does not provide detailed process flows, PFMEAs, control plans, or part-level quality history. Those remain in your own systems (ERP, MES, QMS) and supplier submissions.
    • No direct integration to your risk model by default: Unless you have built and validated an integration, OASIS information will not automatically feed your supplier scorecards, risk rankings, or approval workflows.

    Typical ways OASIS is embedded in supplier control processes

    In mature aerospace supplier management, OASIS is usually embedded in several control points:

    • Supplier onboarding and approval: Before adding a new aerospace supplier, commodity managers or quality engineers check OASIS to confirm certification status, verify the scope covers the intended work, and note any recent major nonconformities.
    • Periodic supplier review: During annual or periodic supplier reviews, the team confirms in OASIS that certificates are still valid, and reconciles any discrepancies with copies provided by the supplier.
    • Audit planning: When planning on-site supplier audits, internal auditors review the supplier’s OASIS audit history to focus on high-risk areas, repeat findings, or systemic weaknesses identified by the CB.
    • Escalation and containment: If a critical escape or major quality issue occurs, quality and procurement may check OASIS for any recent CB findings at that supplier that may relate to the issue, and consider this when deciding on additional surveillance or probation.

    In all cases, OASIS is one input. It complements, but does not replace, your own technical and commercial assessments.

    Limitations, dependencies, and data quality

    The effectiveness of OASIS in supplier control depends on several factors:

    • Timeliness of CB updates: OASIS relies on certification bodies to maintain data. If CBs are slow to update records, certificate status or findings may lag reality.
    • Access controls and confidentiality: Some detailed audit information is only visible to certain users or by mutual agreement. Your team may not see all underlying evidence without additional arrangements with the supplier or CB.
    • Internal process maturity: If your supplier control process does not systematically reference OASIS, or if checks are not documented in your QMS, the available data will not reliably influence decisions.
    • Integration quality (if used): If you integrate OASIS data into ERP, QMS, or supplier portals, you must validate mapping, synchronization frequency, and error handling. In regulated environments, such integrations should go through formal change control and, where applicable, validation.

    Organizations should define explicitly in their procedures how OASIS is used (e.g., at supplier approval, re-approval, and periodic review) and what to do when OASIS data conflicts with supplier-provided documentation.

    Coexistence with existing systems and brownfield reality

    In most aerospace and defense environments, OASIS coexists with a mix of legacy and modern systems:

    • ERP and supplier master data: OASIS information is typically referenced when creating or updating supplier master records, but the ERP remains the system of record for who is approved to receive particular parts or commodities.
    • QMS and supplier qualification workflows: QMS workflows often include a step to document OASIS checks (e.g., screenshots or reference IDs) as objective evidence in approval and periodic review records.
    • Supplier portals and scorecards: Some organizations replicate key OASIS attributes (certification type, expiry date) into supplier scorecards, but this usually happens via manual entry or light integrations rather than full automation, due to validation, cost, and change control constraints.

    Attempting to treat OASIS as a complete supplier control platform usually fails in practice. Long equipment lifecycles, integration debt, and the burden of qualifying new tools mean that most plants continue to use OASIS as a reference data source while keeping ERP, QMS, and MES as the operational systems of record for supplier control.

    How to use OASIS in a risk-based supplier control strategy

    To use OASIS effectively and realistically:

    • Define when OASIS must be checked: For example, new supplier approval, annual review of strategic suppliers, and before placing work for critical parts or special processes.
    • Link OASIS status to risk ratings: Incorporate certification status, scope fit, and recent major nonconformities as factors in your supplier risk model, alongside your own performance metrics.
    • Document evidence and decisions: Store OASIS references (e.g., printouts or IDs) in your QMS or supplier file so you have traceable evidence during audits.
    • Do not over-rely on it: Treat OASIS as corroborating evidence, not as proof that a supplier is low risk. Continue to monitor actual performance, process capability, and conformance data.

    Used this way, OASIS strengthens supplier control by making certification data more transparent and traceable, while keeping your operational decisions grounded in your own quality and delivery experience.

  • How do we ensure service providers follow IEC 62443-2-4 expectations?

    IEC 62443-2-4 focuses on what service providers must do to support secure industrial automation and control systems. You cannot “ensure” compliance in an absolute sense, but you can significantly increase conformance and reduce risk by making 62443-2-4 a structured part of supplier management, contracts, and technical controls.

    1. Make IEC 62443-2-4 explicit in contracts and SOWs

    Service providers rarely align with 62443-2-4 unless it is concretely required. Start by making expectations visible and binding:

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

    • Reference IEC 62443-2-4 in master service agreements and statements of work, specifying which clauses or capability levels apply to your use case.
    • Define scope: which sites, networks, systems, and environments (e.g., production, test, development) are in scope.
    • State required deliverables: security plans, hardening guides, user management procedures, incident support, and documentation that map to 62443-2-4 requirements.
    • Include right-to-audit or right-to-request-evidence clauses, within reasonable limits for confidentiality and export controls.

    Avoid vague language like “provider follows industry best practices.” Tie expectations to specific, testable outputs and behaviors.

    2. Integrate 62443-2-4 into supplier qualification

    Before the first purchase order, assess the provider’s maturity against 62443-2-4, similar to any quality or safety qualification:

    • Use a structured questionnaire mapped to 62443-2-4 requirements (e.g., account management, patching, remote access, backups, incident support).
    • Ask for existing certifications or third-party assessments only as supporting evidence, not as a guarantee of suitability.
    • Review their documented processes for secure configuration, remote access, and change control in operational technology (OT) environments.
    • Classify providers by criticality (e.g., can they impact safety, product quality, or regulatory data) and scale your depth of assessment accordingly.

    In highly regulated or safety-critical environments, you may need on-site or virtual technical reviews involving OT, IT security, and quality representatives.

    3. Define clear responsibilities and boundaries

    IEC 62443 assumes responsibility is shared between asset owners and service providers. Gaps often occur where boundaries are unclear. Clarify in writing:

    • Who owns network zoning and segmentation, firewalls, and remote access gateways.
    • Who creates, approves, and removes user accounts on OT systems and remote access tools.
    • Who applies OS and application patches, and under what approval workflow.
    • Who maintains backup and recovery procedures, and how often restore tests occur.
    • Who leads incident response for cybersecurity events affecting their scope, and how this integrates with your incident and deviation processes.

    Responsibility matrices (e.g., RACI charts) tied to 62443-2-4 control families are often the most practical way to avoid assumptions.

    4. Align with existing brownfield and validated systems

    In brownfield environments with legacy MES, DCS, PLCs, and validated systems, you cannot simply “upgrade to compliant” services without disruption. When applying 62443-2-4 expectations:

    • Identify systems where changes trigger revalidation or requalification, and require service providers to follow your change control and validation processes.
    • Prohibit unilateral provider changes to configurations, firmware, or network connections without documented change requests and impact assessments.
    • Require versioned configuration baselines and traceability for any changes they implement.
    • Favor additive protections (e.g., secure remote access gateways, jump hosts, monitoring) over wholesale replacement of legacy components, which often fails due to downtime, integration complexity, and regulatory burden.

    Where providers propose major technology changes, insist on a structured risk and impact assessment that includes qualification effort, downtime windows, and rollback plans.

    5. Control and monitor remote access

    Remote access is one of the highest-risk areas governed by 62443-2-4 and often heavily used by vendors for troubleshooting and upgrades. At minimum:

    • Use centrally managed, approved remote access solutions rather than ad hoc VPNs or vendor tools installed directly on OT assets.
    • Require strong authentication (e.g., MFA) and unique identities for each individual, not shared vendor accounts.
    • Limit access by time, system, and role; avoid persistent always-on vendor connections.
    • Monitor and log remote sessions at the network and application layer where feasible, and retain those logs per your retention policy.
    • Include remote access use in periodic reviews with the provider and in your internal cybersecurity governance.

    Where legacy constraints limit technical controls, compensate with stricter procedural controls, escorted sessions, and additional logging at adjacent layers (e.g., jump hosts or firewalls).

    6. Require and review evidence, not just policies

    To move from trust to verification, tie 62443-2-4 requirements to concrete artifacts and periodic reviews:

    • Define what evidence you expect: configuration hardening checklists, user lists, change records, incident reports, and test results for backups or failover.
    • Ask for samples of tickets and change records (appropriately redacted) that show how they handle work in regulated plants.
    • Check that their procedures are actually followed on your systems, not just documented generically.
    • Include provider-related controls and evidence in your internal audits and pre-audit readiness activities, but avoid implying that this guarantees any particular audit outcome.

    Be explicit that missing or weak evidence will affect continued use and future sourcing decisions.

    7. Integrate providers into your change control and risk management

    Service providers frequently act outside plant change processes unless you enforce alignment. To match 62443-2-4:

    • Require that all provider changes go through your formal change control, including risk assessment, testing, and approvals where applicable.
    • Mandate pre-deployment testing on non-production or representative testbeds for impactful changes (patches, firmware, major configuration shifts).
    • Ensure cyber-related risks and mitigations are recorded in your risk registers, not just in vendor documents.
    • Document rollback plans for any change that can disrupt production, quality, or safety-related controls.

    In validated or qualified environments, align provider activities with your validation documentation and release processes to preserve traceability.

    8. Use tiered oversight based on criticality

    Not every service provider needs the same rigor. Define tiers such as:

    • High criticality: Can affect safety functions, product quality, batch records, regulatory data, or core OT networks. These should have full 62443-2-4 alignment, detailed contracts, and regular reviews.
    • Medium criticality: Indirect OT impact or limited-scope remote access. Require essential controls (remote access, user management, incident reporting) and periodic spot checks.
    • Low criticality: No network access to OT, no impact on regulated data. Apply baseline corporate security and supplier expectations.

    This avoids overburdening low-risk providers while still maintaining strong control where it matters most.

    9. Plan for lifecycle, exit, and personnel changes

    IEC 62443-2-4 expectations need to hold over long equipment lifecycles and changing vendor relationships:

    • Include offboarding provisions: how accounts are removed, data returned or destroyed, and access revoked at contract end or scope change.
    • Require timely notification when their key personnel with access to your environment change roles or leave.
    • Plan for what happens if the provider discontinues a service or tool, to avoid unmanageable technical debt or stranded unsupported systems.
    • Review alignment with 62443-2-4 at agreed intervals (e.g., annually) to account for technology and threat changes.

    Lifecycle planning is especially important where providers manage components that would be costly to requalify or replace.

    10. Be explicit about limits and shared responsibility

    No combination of clauses or controls can fully guarantee that a provider will always follow IEC 62443-2-4 in practice. Factors like site-specific configurations, integration quality, and internal process maturity will strongly influence actual risk reduction. You remain responsible for:

    • Defining acceptable risk in the context of your operations and regulatory environment.
    • Maintaining network architecture, monitoring, and incident response that can detect and respond to provider missteps.
    • Ensuring internal teams do not bypass agreed processes for the sake of short-term convenience.

    Treat IEC 62443-2-4 as a shared framework: you set clear expectations, the provider demonstrates capability and evidence, and you validate and monitor that behavior over time.

  • How detailed should non-conformance documentation be for regulators?

    It should be detailed enough that a regulator, customer auditor, or internal reviewer can reliably reconstruct the event without relying on tribal knowledge. In practice, that means the record should clearly show what the non-conformance was, how it was detected, what material or product was affected, who reviewed it, what disposition was made, what evidence supported that decision, and what corrective action was required if applicable.

    No, the right answer is not “document everything possible.” Excess detail that is inconsistent, duplicated across systems, or unsupported by evidence can create its own risk. Regulators usually care less about volume than about whether the record is accurate, contemporaneous, traceable, reviewable, and aligned to your approved procedures.

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

    What the record usually needs to show

    • A clear description of the non-conformance, including the requirement or specification that was not met.

    • Identification of the affected item, lot, serial number, batch, work order, operation, supplier receipt, or equipment context as applicable.

    • When and where it was found, and by whom.

    • The immediate containment action, including segregation, hold status, or production impact.

    • The material review or disposition decision, with approval traceability.

    • Objective evidence supporting the decision, such as measurements, inspection results, photos, test records, or linked documents.

    • Any rework, repair, deviation, concession, or scrap action taken, including revision-controlled instructions where required.

    • Whether escalation to CAPA, supplier corrective action, or risk review was required.

    • Closure evidence showing the action was completed and the record was reviewed per procedure.

    How much detail is enough

    The level of detail should scale with risk and impact. A cosmetic issue on non-critical hardware does not normally require the same depth as a dimensional escape on a flight-critical feature, a sterility-related deviation, or a recurring supplier defect. Higher-risk events usually require stronger evidence, clearer decision rationale, broader impact assessment, and tighter review controls.

    A useful test is this: if the original finder, supervisor, and engineer were unavailable two years from now, could another qualified reviewer understand exactly what happened and why the final decision was acceptable under your procedures? If not, the record is probably too thin.

    What regulators typically look for

    Regulators and auditors generally look for consistency between the non-conformance record and the rest of the quality system. They may compare the NCR to inspection data, device history or manufacturing records, training records, calibration status, change history, and CAPA records. If the NCR says rework was performed, they will often expect to see the approved instruction, execution evidence, and final verification. If the NCR says use-as-is or deviation, they will expect the rationale and approvals to be traceable.

    This is why short narrative summaries alone are usually not enough in regulated environments. The documentation must connect to the evidence trail.

    Common failure modes

    • Vague descriptions such as “out of spec” with no requirement reference.

    • Missing product scope, so affected units cannot be reliably identified.

    • Disposition recorded without objective evidence or required approvals.

    • Rework documented in one system but not reflected in the device history, traveler, or as-built record.

    • Root cause language added prematurely without investigation support.

    • Free-text narratives that differ across MES, QMS, ERP, and paper records.

    • Late data entry that weakens contemporaneous record credibility.

    Brownfield reality

    In many plants, non-conformance documentation is split across QMS, MES, ERP, email, shared drives, and paper attachments. That is common, but it increases retrieval risk and inconsistency risk. If your systems coexist, the practical goal is not necessarily a full platform replacement. It is to make sure the authoritative record, linked evidence, approval trail, and item traceability are unambiguous.

    Full replacement strategies often fail in long-lifecycle regulated environments because of validation burden, downtime risk, integration complexity, qualification concerns, and the need to preserve traceability across legacy records. In many cases, improving linkage, data discipline, and review workflow across existing systems is more realistic than replacing everything at once.

    Practical standard to use

    Your documentation should be complete enough to support investigation, disposition, traceability, and later review under your own procedures and applicable regulatory expectations. If a record cannot withstand cross-checking against related quality and production records, it is not detailed enough. If it is so verbose that reviewers cannot identify the controlling facts, it is probably poorly structured rather than well documented.

    The best target is controlled completeness: enough detail to prove what happened and why the decision was made, with evidence and approvals that are easy to retrieve and verify.

  • Where should aerospace manufacturers handle configuration control: ERP, MES, or a dedicated system?

    There is no universal right answer. In aerospace, configuration control usually has to be split across systems, with one system clearly designated as the master for each aspect of configuration. Trying to force all configuration control into a single system (ERP or MES alone) often creates more risk than it removes, especially in brownfield, highly validated environments.

    What “configuration control” actually touches

    Before choosing a system, separate the different layers of configuration you are trying to control:

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

    • Product configuration: part numbers, effectivity, options/variants, engineering BoM, drawings, models.
    • Manufacturing configuration: routing, operations, work instructions, tooling, NC programs, inspection plans.
    • Commercial / supply configuration: sellable SKUs, contract items, approved manufacturer lists, supplier part numbers.
    • As-built / as-maintained configuration: serialized build records, installed configuration, change history in the field.

    ERP, MES, and dedicated configuration or PLM systems are each strong in different parts of this stack.

    Typical roles for each system

    In most aerospace plants today:

    • ERP is the commercial and planning system of record: customer part, internal part, revision identifier, planning BoM, and MRP. It is not usually the place to manage detailed process-level configuration or complex change workflows.
    • MES is the execution system of record: which specific serialized unit was built to which revision, under which routing, with which operations, NC programs, inspection results, and concessions. It is usually where as-built configuration and genealogy are anchored.
    • Dedicated configuration / PLM / CM system (sometimes called PDM or CMDB in this context) is often the engineering configuration authority: full engineering BoM, effectivity, baselines, and formal change control from ECN/ECR through release.

    In many regulated aerospace environments, engineering configuration control sits in PLM or a dedicated CM tool, with ERP and MES consuming that data in controlled, versioned ways.

    When to anchor configuration in ERP

    ERP can be the primary configuration system for:

    • Commercial identifiers: sellable SKUs, customer part numbers, contract-level revisions.
    • High-level BoM: planning or manufacturing BoM without deep process detail.
    • Effectivity at the order level: which revision a customer order or work order is for.

    Advantages:

    • ERP already drives MRP, purchasing, and shipment; using it for high-level configuration keeps those consistent.
    • Finance and supply chain teams typically already trust ERP as the commercial system of record.

    Limitations and risks:

    • ERP is usually weak at detailed process configuration: work instructions, NC program versions, inspection plan details, or operation-level effectivity.
    • Engineering change workflows in ERP are often crude or bolt-ons; tracing from ECN to as-built item at operation level can be difficult.
    • Heavily customizing ERP to act as a full configuration management system increases upgrade risk and validation burden.

    If you make ERP the master for configuration, you still need tight, validated integration to MES or a configuration-aware system to ensure as-built records match ERP intent.

    When to anchor configuration in MES

    MES can be the primary configuration system for:

    • Manufacturing process configuration: routings, operation definitions, work instructions, inspection steps, NC program references, process parameters.
    • As-built configuration and genealogy: which serial number followed which routing and revision, at which station, using which consumables.
    • Process-level change control: ensuring that only released instructions and routings are used, with audit trails for who changed what and when.

    Advantages:

    • MES is close to the shop floor, so routing-level and instruction-level changes can be controlled and enforced at execution.
    • It naturally links configuration to evidence: operator signoffs, inspection results, nonconformance records, and test data.
    • It can represent operation-level effectivity (e.g., operation 20 changed at serial X) more naturally than ERP.

    Limitations and risks:

    • MES is usually not the source of engineering truth; it consumes from PLM or ERP. If MES starts inventing independent part numbers or revs, you get divergence.
    • If MES becomes the de facto master without clear rules, you can end up with conflicting definitions between MES, ERP, and PLM.
    • Retrofitting full configuration discipline into a legacy MES can be as hard as buying or building a dedicated configuration system.

    MES is generally the right place to anchor as-built configuration, but it should take engineering and commercial configuration from PLM/CM and ERP, not replace them.

    When to use a dedicated configuration or PLM system

    A dedicated configuration management or PLM system is usually the best place for engineering configuration control in aerospace, especially for complex assemblies and long lifecycles:

    • Engineering BoM and variant structures.
    • Formal baselines (prototype, qualification, production).
    • Effectivity across serials, lots, customers, or programs.
    • ECN/ECR workflows, impact analysis, and approvals.

    Advantages:

    • Tools are designed around configuration management principles and standards.
    • Separates engineering change control from operational planning and execution, reducing pressure to shortcut CM for schedule reasons.
    • Can support digital thread use cases: linking models, drawings, requirements, and downstream manufacturing data.

    Limitations and risks:

    • Requires robust integration to ERP and MES so that part numbers, BoMs, and revisions flow in a controlled, traceable way.
    • Introducing a new dedicated system in a brownfield environment adds validation and change management burden.
    • If not governed carefully, you can have conflicting “masters” across PLM, ERP, MES for the same part or routing.

    Dedicated CM/PLM is rarely a drop-in replacement for ERP and MES. It becomes the upstream authority, and ERP/MES become execution consumers within a defined digital thread.

    Practical patterns that work in aerospace

    In regulated aerospace plants, successful patterns usually look like one of the following:

    1. PLM/CM as engineering master, ERP for commercial, MES for as-built
      • PLM/CM owns engineering BoM, effectivity, and ECN workflows.
      • ERP owns part master, planning BoM, and revision key for orders.
      • MES owns routings, work instructions, and as-built genealogy, but cannot create or change key part/rev identifiers without PLM/ERP.

      This is the most common for complex OEMs and tier-1s with strong engineering organizations.

    2. ERP as part / revision master, MES as process and as-built master
      • ERP holds part numbers, high-level BoMs, and top-level revision.
      • MES holds detailed routings, work instructions, and links them to ERP part/rev.

      This is common where PLM is limited or absent, particularly at tier-2/tier-3 suppliers, but requires discipline to keep engineering artifacts aligned.

    3. Dedicated CM system with light ERP and MES integrations
      • CM system or PLM is authoritative for engineering and product configuration.
      • ERP is primarily finance/MRP with limited configuration responsibility.
      • MES focuses on execution, tightly constrained by CM data and rules.

      Common in highly regulated defense programs, but integration and validation costs are significant.

    Why “full replacement” strategies often fail

    Trying to turn a single system into the universal configuration authority (“we will do all configuration in ERP now,” or “MES will be the only configuration control system”) frequently breaks down because:

    • Qualification and validation burden: Replatforming critical configuration control requires extensive testing, documentation, and requalification with customers and authorities.
    • Downtime and cutover risk: Migrating all configuration into one system demands big-bang cutovers that many aerospace plants cannot tolerate.
    • Integration complexity: Existing QMS, PLM, and supplier portals are already wired to multiple systems. Ripping those out often causes more issues than it solves.
    • Traceability and change control: Long asset lifecycles mean you must retain and interpret legacy configuration data for decades; consolidating it into a new system without loss or misinterpretation is nontrivial.

    Incremental, clearly scoped changes to system roles, with strong integration and governance, tend to be more successful.

    How to decide for your environment

    When deciding where to handle configuration control, focus on:

    • What is already validated: Changing the system of record for configuration can require revalidation or customer approval.
    • Where data is most trusted today: For example, if quality audits always rely on MES traceability, anchoring as-built configuration elsewhere will be disruptive.
    • Integration maturity: If ERP–MES and PLM–MES integrations are immature or manual, introducing a dedicated CM system or shifting ownership could increase actual risk.
    • Scope of configuration you really need: Do you need variant and effectivity control at the serial level, or just at the order level? Answers change which system is realistic.
    • Governance capability: A dedicated CM system without strong governance can create a new failure point instead of solving the problem.

    In most aerospace manufacturers, a pragmatic target state is:

    • Engineering configuration in PLM or a CM system.
    • Commercial and planning configuration in ERP, tightly linked to engineering data.
    • Process and as-built configuration in MES, constrained by engineering and ERP masters.

    The specifics will depend on your existing stack, integration readiness, and the regulatory and customer expectations you operate under.

  • What is the primary purpose of ISA-88?

    The primary purpose of ISA‑88 (S88) is to provide a consistent, modular model for batch control so that product recipes are clearly separated from equipment control and system implementation. It defines a common architecture, terminology, and set of models that different teams and vendors can use to design, integrate, and maintain batch processes in a predictable way.

    What ISA‑88 is trying to achieve

    At its core, ISA‑88 aims to:

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

    • Separate recipes from equipment: Make product and process logic (recipes, procedures) distinct from physical assets (units, modules, phases) so that changing a product does not always require changing control code.
    • Standardize batch models and language: Provide a shared way to describe processes, equipment, and control activities so engineering, operations, quality, and vendors can communicate without ambiguity.
    • Support modular, reusable design: Encourage unit, equipment module, and phase-based control that can be reused across products and sites, reducing custom code and integration complexity.
    • Improve lifecycle manageability: Make it easier to maintain, validate, and evolve batch systems over long equipment lifecycles by reducing tight coupling between control logic and product definitions.
    • Enable better traceability of execution: Provide a consistent structure for capturing which recipe, which equipment, and which actions were executed, in what order, to support investigations and regulatory expectations.

    What this means in regulated, brownfield environments

    In regulated and long‑lifecycle operations, ISA‑88 is primarily useful as a design and integration reference, not as a standalone solution. Its practical role is to:

    • Guide how batch control is structured in DCS/PLC/SCADA and batch execution systems, so changes to recipes and equipment can be managed with clearer impact analysis and change control.
    • Provide a backbone for integration to MES, historian, and QMS, because the standard models (procedures, unit procedures, operations, phases, units, equipment modules) give stable integration points.
    • Support validation and traceability by making the relationship between recipes, equipment behavior, and execution data more explicit and easier to document and test.

    Using ISA‑88 does not guarantee compliance, audit success, or validation outcomes. Benefits depend heavily on:

    • How consistently the ISA‑88 models are applied across legacy and newer systems.
    • The quality of integration between control systems, MES, historians, and quality systems.
    • How recipe management, change control, and configuration management are implemented on top of the standard.

    Limits and tradeoffs

    • Not a replacement strategy: Adopting ISA‑88 does not require ripping out existing DCS/PLC or MES. In fact, full replacement to “go pure S88” is rarely practical in highly regulated plants because of validation burden, downtime risk, and integration debt.
    • Interpretation varies by vendor: Different control and batch platforms implement ISA‑88 concepts differently. The standard reduces ambiguity, but it does not eliminate vendor‑specific behavior or configuration.
    • Requires discipline to realize value: Without governance around naming, modular design, and recipe/equipment separation, plants can claim “S88‑compliance” yet still end up with tightly coupled, hard‑to‑maintain systems.

    In practice, many organizations use ISA‑88 as a reference model to incrementally improve existing batch systems: cleaning up equipment models, standardizing phases, and restructuring recipes, rather than attempting a disruptive, full‑scale replacement.

  • Which ISO 9001 clauses are mandatory for certification?

    For ISO 9001:2015, certification is based on meeting all applicable requirements in the standard, not on a fixed subset of “mandatory” clauses. In practice, every clause that contains the word “shall” is mandatory unless it is legitimately not applicable to the scope of your quality management system (QMS).

    Clauses that are always applicable

    Certification bodies will expect the following core clauses to be implemented for every organization, regardless of industry or size:

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

    • 4: Context of the organization
    • 5: Leadership
    • 6: Planning
    • 7: Support
    • 8: Operation (with limited, justified exclusions)
    • 9: Performance evaluation
    • 10: Improvement

    Within these, all “shall” requirements are considered mandatory unless your organization can justify them as not applicable under clause 4.3 (scope of the QMS). In regulated industrial environments, auditors typically challenge scope limitations more strictly, especially where product safety, airworthiness, or contractual requirements are involved.

    What can be excluded or marked not applicable

    ISO 9001:2015 allows exclusions only where requirements cannot be applied due to the nature of your organization and its products and services. The classic example is clause 8.3 (Design and development of products and services).

    • Clause 8.3 (Design and development): May be justifiably excluded if your organization truly does not perform design and development under its QMS scope (for example, pure build-to-print machining with no in-scope product or process design authority). You must still control customer specifications, drawings, and changes appropriately.
    • Other operational sub-clauses in 8.x: In practice, most manufacturers find that nearly all of 8.x is applicable, because they procure, produce, inspect, and deliver product. Claims of non-applicability for these requirements are often heavily scrutinized in certification and regulatory audits.

    Any exclusion must be:

    • Explicitly described in your QMS scope (clause 4.3).
    • Consistent with your actual operations, contracts, and regulatory obligations.
    • Defensible with evidence during audit (for example, no design records, no design authority, contracts that clearly allocate design to another party).

    If your operations, contracts, or regulatory environment evolve over time (for example, you start doing in-house tooling design, special process development, or configuration control), previously excluded requirements like 8.3 may become applicable and need to be brought into scope with proper change control and, where required, validation.

    Implications in aerospace and other regulated manufacturing

    In aerospace, defense, and other regulated sectors, ISO 9001 is often embedded in or superseded by sector standards (for example, AS9100). Even when your certification is directly to ISO 9001, regulators and primes usually expect:

    • Very limited use of exclusions, typically only 8.3 and only with strong justification.
    • Robust linkage between ISO 9001 clauses and your documented procedures, records, and digital systems (MES, ERP, PLM, QMS).
    • Evidence that brownfield systems and legacy processes are included in the QMS scope, not treated as “out of scope” for convenience.

    Because equipment lifecycles are long and system replacement carries qualification and downtime risk, many plants run a mix of legacy and newer systems. Auditors focus on whether ISO 9001 requirements are met across that entire ecosystem, not just in newer tools. For example, document control, configuration management, and traceability must work coherently whether records originate in an old on-prem MES or a newer cloud QMS.

    How to determine applicability in your environment

    To decide which ISO 9001 clauses are applicable for your certification scope:

    1. Map your processes from customer requirement through delivery and support, including outsourced processes and special processes.
    2. Identify which ISO 9001 requirements touch each process. Most manufacturers find that nearly all of clauses 4 to 10 apply.
    3. For any requirement you believe is not applicable, document a specific, factual justification in the scope statement (clause 4.3) and ensure it aligns with contracts and regulatory requirements.
    4. Verify that supporting systems (MES, ERP, PLM, QMS, paper-based processes) actually implement the requirement consistently, including in older lines and legacy equipment.
    5. Treat scope or exclusion changes under formal change control, with impact assessment on validation, training, and audit trails.

    Certification bodies will not accept a generic claim that certain clauses are “not mandatory.” They will expect a clear, justified scope and evidence that all applicable “shall” requirements are implemented and effective across your real operational landscape.

  • What information must be included in an aerospace non-conformance report?

    An aerospace non-conformance report (NCR, NCMR, NCD, DR, QN, etc.) must contain enough structured information to fully identify the part, describe the defect, assess risk, and support traceable disposition and corrective action. Field names and layouts will vary by customer, site, and system, but the required content is broadly consistent.

    1. Identification and traceability

    At minimum the NCR must allow someone outside the immediate team (auditor, customer, investigator) to uniquely identify the event and link it to the affected product and records:

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

    • NCR identifier: unique NCR / DR number, revision, and status.
    • Date/time: when the non-conformance was detected and recorded.
    • Reporter: name/ID and organization (e.g., inspector, operator, supplier, customer).
    • Location: facility, building, line/cell, station, and operation/inspection step.
    • Customer link: customer program/aircraft/platform, contract/SOW, and any customer defect report ID if applicable.

    2. Part, configuration, and documentation data

    Aerospace non-conformance records must allow reconstruction of the exact configuration involved. Typical required fields:

    • Part identification: part number, description, dash level or variant, and configuration if applicable.
    • Serial/lot/heat/batch: serial numbers, lot numbers, heat numbers, cast numbers, or other unique identifiers for all affected units.
    • Quantity: total quantity affected, and used/scrapped/quarantined quantities.
    • Revision and configuration: drawing revision, model revision, planning revision, software/hardware revision as applicable.
    • Process routing: operation number, work order/traveler number, router/planning ID, and revision under which work was performed.
    • Referenced documents: drawing numbers, specifications, work instructions, special process instructions, and any deviation/concession already applicable.

    3. Detection details (how and when it was found)

    Auditors and customers will look for evidence that your detection and inspection system is functioning. The NCR should record:

    • Detection point: in-process inspection, final inspection, receiving, test, field/service, customer site, or supplier.
    • Detection method: visual, dimensional, NDT, functional test, software verification, torque check, leak test, etc.
    • Inspection tools/equipment: gauge or test equipment ID, calibration status reference, automated test system ID if relevant.
    • Trigger: routine inspection, sampling, SPC alarm, operator observation, customer complaint, or escape report.

    4. Detailed description of the non-conformance

    The defect description needs to be specific enough that another engineer could understand it without access to the part. Aerospace customers and standards typically expect:

    • Requirement violated: clear reference to the requirement not met, such as drawing dimension and tolerance, spec paragraph, procedure step, process limit, or software requirement ID.
    • As-found condition: factual description of what is wrong, avoiding interpretation or blame (e.g., “Ø12.000 mm feature measured Ø12.065 mm; tolerance 12.000 ±0.020 mm”).
    • Defect category and code: standardized defect type or code (e.g., dimensional, surface defect, documentation error, process escape, material non-conformance).
    • Location of defect: feature ID, station, face, hole number, zone, frame-stringer location, rib number, or coordinate system location as appropriate.
    • Extent and pattern: number of occurrences per part, which serials are affected, and whether the issue is isolated or systemic.
    • Visual/test evidence: references to photos, test results, CMM reports, NDT results, or measurement records stored elsewhere.

    5. Risk and impact assessment

    Regulated aerospace environments require a structured evaluation of impact on safety, airworthiness, performance, and compliance. The NCR should capture:

    • Application/use: where and how the part is used (primary/secondary structure, flight control, engine, cabin, ground test only, tooling).
    • Safety/airworthiness impact: preliminary assessment of potential safety impact, including whether the issue is potentially safety-critical or reportable.
    • Functional impact: potential impact on performance, reliability, maintainability, or interoperability.
    • Regulatory/contractual impact: potential effect on certification basis, customer requirements, or regulatory commitments.
    • Escape status: whether non-conforming product has shipped, been installed, or entered service, and how that was determined.

    6. Containment and immediate actions

    Containment steps must be recorded clearly for traceability and to demonstrate control of non-conforming material:

    • Quarantine details: where affected items are physically located (MRB area, quarantine cage, bond room) and how they are segregated.
    • Inventory check: scope of stock search and results (WIP, finished goods, in-transit, at supplier, at customer).
    • Production impact: whether operations were stopped, slowed, or allowed to continue under temporary controls.
    • Temporary controls: additional inspections, holds, tags, or process changes applied pending disposition.

    7. Disposition and approvals

    Formal, documented dispositions are essential in aerospace due to airworthiness and contractual requirements. Depending on your procedures and customer rules, the NCR should include:

    • Disposition type: scrap, rework to drawing, repair (non-standard), use-as-is, return to supplier, re-grade (for material), reclassify to non-flight or ground test use.
    • Repair/rework instructions: clear, approved instructions tied to engineering authority, including new drawings or sketches, process steps, and any additional inspections or tests required.
    • Authority reference: MRB authority numbers, engineering concessions/deviations, customer-approved permits, or controlled repair procedures.
    • Affected documentation: any updates or notes required on travelers, as-built records, configuration management systems, or digital models.
    • Validation requirements: additional proof tests, analysis, or inspections needed to justify the disposition and confirm conformity after action.
    • Approvals: signatures or electronic approvals for quality, MRB engineer, design authority, program/customer representative when required, and date/time stamps.

    8. Root cause and corrective / preventive action (as applicable)

    In many aerospace organizations, the non-conformance record also serves as the entry point to CAPA or problem-solving processes. At a minimum, the NCR should link to these records, and in some systems it will contain them:

    • Cause analysis reference: 5-Whys, fishbone, fault tree, or other analysis used, and where that record is stored.
    • Verified root cause(s): distinct identification of direct cause, contributing factors, systemic/root causes as determined.
    • Corrective actions: actions to prevent recurrence for the same part/location (e.g., fixture correction, updated tool, clarified work instruction).
    • Preventive/systemic actions: broader actions that prevent similar escapes elsewhere (e.g., training, changes to design rules, FMEA updates, additional poka-yoke).
    • Effectiveness checks: how and when you will verify that actions worked, metrics to monitor, and responsible owner.

    9. System integration and brownfield considerations

    In real aerospace plants, NCR information is often spread across multiple systems (MES, QMS, PLM, ERP, supplier portals). To avoid gaps and inconsistencies:

    • Ensure identifiers: the NCR should carry or reference the IDs used in upstream and downstream systems (work orders, as-built records, supplier lots, customer notifications).
    • Link, do not duplicate: where possible, link to source records (CMM reports, NDT logs, test data, concessions) rather than copying data that will get out of sync.
    • Respect long lifecycle: avoid designs where changing NCR formats requires revalidating large portions of the MES/QMS stack unless you have a strong justification and a migration plan.
    • Change control: treat NCR schema and workflow changes as controlled changes, with traceability, training, and, where relevant, revalidation.

    10. Dependencies and variability

    The exact information you must include is constrained by:

    • Customer and regulatory requirements: prime OEMs and authorities often define mandatory fields, codes, and workflows in contracts, quality clauses, or supplier manuals.
    • Internal procedures: your QMS, MRB procedures, and engineering authority processes may add requirements beyond typical industry practice.
    • System capabilities: legacy QMS/MES solutions may not support every desirable field; in those cases, you will need controlled workarounds (attachments, linked records, or upgraded systems) and careful validation.
    • Product type and risk: safety-critical and flight hardware usually demand more detailed risk, analysis, and approval data than ground equipment or test rigs.

    Because of this variability, you should treat the list above as a reference checklist, then map it to your actual forms, electronic workflows, customer requirements, and validation constraints rather than adopting it blindly.