Connect981 – Content Dev

RSC Content Type: FAQ

Direct answers to common technical or compliance questions.

  • Who is considered the asset owner in a contract manufacturing arrangement?

    In a contract manufacturing arrangement there is no single, universal “asset owner.” Ownership depends on the type of asset, the commercial structure, and what is explicitly defined in the contracts and quality/technical agreements. In regulated and long-lifecycle environments, you should assume that different parties may own different asset classes and that this must be documented clearly.

    Major asset types and typical ownership

    Common asset categories in contract manufacturing include:

    • Production equipment and facilities: CNC machines, assembly lines, HVAC, building infrastructure.
    • Tooling and fixtures: Dedicated tools, jigs, test fixtures, molds.
    • IT/OT systems: MES, SCADA, historians, QMS, LIMS, local databases, and their configurations.
    • Product definition: Drawings, BOMs, routings, specifications, software/firmware, control plans.
    • Process knowledge & validation: Work instructions, validated parameters, recipes, test methods.
    • Data & records: Batch records, genealogy, deviations, CAPA records, equipment maintenance logs.

    In practice:

    • Physical equipment and facilities are usually owned by the contract manufacturer (CM). The CM is typically the asset owner for maintenance, calibration, qualification, and lifecycle management, except where the sponsor funds and retains title to specific equipment.
    • Customer-funded dedicated equipment or tooling may be owned by the brand owner/sponsor even though it is operated by the CM. Contracts often specify that the sponsor owns the tooling, while the CM is the “custodian” with defined responsibilities for care, use, and change control.
    • IT/OT systems (MES, SCADA, local QMS, etc.) are usually owned and administered by the CM. The sponsor rarely owns these systems in a brownfield plant, but may own specific interfaces, templates, or reports provided to the CM.
    • Product definition and IP (drawings, specifications, software, process requirements) are normally owned by the sponsor/brand owner. The CM is granted limited rights to use this information to manufacture and support the product.
    • Process knowledge, recipes, and work instructions may be jointly developed. Ownership is often split: the sponsor may own product-specific methods, while the CM retains rights to generic process know-how. “Joint ownership” is a legal construct and must be defined in the contract, not assumed.
    • Data and quality records (batch records, device history records, test results) are frequently created and controlled by the CM, but the sponsor typically has rights to full access, copies, and retention for regulatory, traceability, and customer support purposes.

    Contractual definition of asset ownership

    Because these arrangements vary, the contract and associated quality/technical agreements should:

    • List asset categories explicitly: equipment, tooling, IT/OT systems, product definition, data, and records.
    • Assign legal ownership for each category (who holds title), and where relevant, who is the custodian or operator.
    • Define control and decision rights: who can approve process changes, who can decommission equipment, who defines data retention and access requirements.
    • Specify validation and change control responsibilities: who funds and performs qualification/validation when equipment, systems, or processes change, and how this is documented.
    • Clarify data and record rights: who owns the underlying data vs. who is responsible for storage, retrieval, and providing evidence for audits and investigations.
    • Address end-of-life and exit: what happens to sponsor-owned tooling, data copies, and configuration baselines if the relationship ends.

    In regulated industries, these allocations must be consistent with applicable regulations and your own quality system. The sponsor may not be the IT system owner at the CM site, but remains responsible for product quality and regulatory compliance for its products.

    Impact on systems and integration in brownfield environments

    In a typical brownfield contract manufacturing environment:

    • The CM owns and operates its MES/SCADA/ERP/QMS stack, with existing validation, integrations, and workarounds that cannot be easily replaced without major disruption.
    • The sponsor owns the product definition and regulatory responsibilities, but depends on data generated in the CM systems for traceability, genealogy, and compliance evidence.
    • Data interfaces and integration configurations (e.g., between sponsor PLM and CM MES) are often treated as shared assets: the sponsor may own the specification and some middleware, while the CM owns the runtime systems where integrations terminate.

    This means that a full replacement of the CM’s core systems by the sponsor is rarely viable. Qualification burden, downtime risk, and integration complexity usually make it impractical. Instead, the contract should clarify who owns:

    • The interface specifications and mappings.
    • The middleware or integration platform, if used.
    • Test evidence and validation documentation for those interfaces.

    These clarifications reduce ambiguity when systems change, when audits occur, or when the relationship transitions to another CM.

    Practical way to determine the asset owner

    If the current contracts are unclear, a pragmatic approach is:

    1. Inventory asset types: list specific equipment, tooling, software systems, data repositories, and key documents used to produce and release the product.
    2. Check legal title and purchase history: who bought and capitalized what, and how is it recorded in each organization’s asset register.
    3. Review the manufacturing, quality, and technical agreements: look for explicit clauses on ownership, IP, data rights, and records management.
    4. Map operational control vs. legal ownership: it is common for the CM to control assets day to day while the sponsor owns the IP and has audit rights and data access.
    5. Update agreements where ambiguous: if uncertainty exists, formally clarify ownership, control rights, and responsibilities under change control.

    Ultimately, in a contract manufacturing arrangement, the “asset owner” is whoever the contracts and supporting quality/technical agreements designate for each specific asset class. When this is not explicit, it becomes a risk area for compliance, traceability, and operational continuity, and should be corrected.

  • Who should own ISO 27001 in organizations with both IT and OT teams?

    ISO 27001 should be owned at the enterprise risk and governance level, not by a single technical team. In organizations with both IT and OT, the usual pattern is:

    • A single business owner for the ISMS (often CISO, CIO, or central Risk/Compliance) accountable for the management system, scope, risk methodology, and interfaces to regulators and auditors.
    • IT leadership responsible for implementing and operating controls on corporate IT and cloud systems.
    • OT leadership (often an OT/plant digital lead or engineering leader) responsible for implementing and operating controls on plant-floor and industrial control systems.

    This separation recognizes that ISO 27001 is a management system standard, not a pure technology standard. The accountable owner must be able to balance risk, cost, and operational impact across both IT and OT, and must sit high enough to resolve conflicts between them.

    Practical ownership model in IT/OT environments

    In regulated, brownfield manufacturing environments, a workable pattern is:

    • ISMS Owner (Accountable): CISO, CIO, or VP Risk/Compliance.
      • Owns the ISO 27001 scope, policy framework, risk assessment methodology, statement of applicability, internal audit program, and management review.
      • Ensures interfaces with quality systems, safety processes, and change control are defined and followed.
    • IT Owner (Responsible for IT scope): Head of IT / Infrastructure / Enterprise Applications.
      • Implements and maintains controls for enterprise networks, servers, workstations, business apps, identity and access management, and cloud services in scope.
      • Coordinates with OT on shared infrastructure (e.g., identity, backup, logging, DMZs).
    • OT Owner (Responsible for OT scope): OT leader / Automation engineering lead / Plant digitalization lead.
      • Implements and maintains controls on ICS/SCADA, DCS, PLCs, historians, MES, and plant networks, with explicit alignment to safety, quality, and validation constraints.
      • Ensures changes respect process safety, qualification, validation, and downtime limits.
    • Supporting functions: Quality, EHS, Legal, HR, and Procurement.
      • Contribute to risk assessment, supplier requirements, training, incident response, and alignment with existing QMS and safety processes.

    Formally, this is usually documented via a RACI that shows who is accountable for the ISMS overall, and who is responsible for each control area across IT and OT.

    Why not let OT or IT “own” ISO 27001 alone?

    Assigning ISO 27001 ownership solely to IT or OT usually fails for at least one of these reasons:

    • Scope gaps: An IT-only owner may under-scope OT networks, vendor remote access, or plant data flows. An OT-only owner may under-scope corporate identity, remote workstations, or cloud services that touch OT data.
    • Conflicting priorities: OT optimizes for uptime and safety; IT often optimizes for standardization and strong technical controls. Neither side alone can reliably balance the tradeoffs at the IT/OT boundary.
    • Regulated change control: Many OT changes require engineering review, validation, or requalification. An IT-only owner may push control changes that are not feasible within existing change-control workflows or shutdown windows.
    • Supplier and lifecycle realities: OT systems have long lifecycles and limited patchability. An OT-only view may under-leverage corporate capabilities (e.g., central logging, vulnerability management), while an IT-only view may set expectations that current OT assets cannot safely meet.

    A central risk or security function is usually better positioned to arbitrate these tradeoffs and decide where risk is accepted, mitigated, or transferred.

    Key design points for shared ownership

    Regardless of where the ISMS owner sits, you will need to make the following explicit:

    • Scope definition: Exactly which plants, networks, systems, and data are in the ISO 27001 scope, including shared IT/OT components (e.g., plant domain controllers, DMZ firewalls, data diodes, VPNs, cloud historians).
    • Interfaces with other management systems: How ISO 27001 interacts with the QMS, safety management, validation/qualification, and change-control processes. In many regulated plants, ISO 27001 controls cannot override quality or safety requirements.
    • Control ownership by domain: For each relevant Annex A control, who is responsible for implementation on IT systems, on OT systems, and for shared infrastructure.
    • Change and downtime constraints: How OT downtime windows, turnaround schedules, and qualification testing are considered when planning security controls like patching, segmentation, or MFA rollouts.
    • Incident response integration: How cyber incidents in OT are triaged, escalated, and resolved, including coordination with safety, operations, and quality incident processes.

    Brownfield and long-lifecycle considerations

    In brownfield plants with legacy MES, SCADA, and control systems, full “replacement” of existing practices with ISO 27001-style controls is rarely realistic. The ISMS owner should focus on:

    • Mapping, not replacing, controls: Identify where existing QMS, safety, and engineering controls already meet or partially meet ISO 27001 requirements, and document equivalence instead of forcing new parallel processes.
    • Risk-based prioritization: Concentrate on high-risk interfaces (e.g., remote access into OT, cross-plant connectivity, vendor support routes) rather than trying to standardize every legacy asset at once.
    • Change-control alignment: Ensure that any new security controls go through established change-control, validation, and qualification gates for regulated equipment.

    This is another reason why ownership at the enterprise risk/security level is important: they can negotiate realistic timelines and risk acceptances that respect operational and regulatory constraints.

    How to decide in your organization

    When you formalize ISO 27001 ownership:

    1. Place accountability with the function that already owns enterprise risk or information security policy (commonly CISO/CIO or central risk/compliance), not within a single plant or a single IT/OT team.
    2. Form an ISMS steering group with IT, OT, Quality, and operations leadership to agree on scope, priorities, and risk criteria.
    3. Document a RACI that clearly distinguishes ISMS-level accountability from domain-level responsibility for control implementation in IT and OT.
    4. Align with existing management systems (QMS, safety, validation) to avoid duplicate processes and to ensure security changes do not disrupt qualified and validated operations.

    The result is a single accountable ISO 27001 owner, with shared responsibility across IT and OT that reflects how your plants actually run.

  • Which KPIs best reflect supplier collaboration performance in aerospace?

    No single KPI is enough. In aerospace, supplier collaboration performance is best measured with a small balanced set that covers delivery, quality, responsiveness, engineering alignment, and traceability. If you only track on-time delivery, you can hide expediting, partial shipments, paperwork defects, recurring nonconformances, and late engineering responses.

    The most useful KPI groups are:

    • Delivery reliability: on-time delivery to committed date, request date adherence, lead-time stability, and schedule change frequency. Distinguish original commit versus last promise date, or the metric can be gamed.
    • Receipt quality: incoming defect rate, supplier NCR rate, repeat escape rate, defect severity mix, and cost of poor quality tied to the supplier. In aerospace, recurrence often matters more than isolated defect count.
    • Response and closure speed: time to acknowledge issues, time to containment, time to corrective action submission, and time to verified closure. These show whether the supplier can work problems in a controlled way, not just ship parts.
    • Engineering and change execution: ECO or revision adoption lag, document package completeness, FAI resubmission cycle time where applicable, and deviation or concession turnaround. This is critical when parts are configuration-sensitive.
    • Traceability completeness: percentage of receipts with complete certs, lot or serial linkage, required test records, and approved documentation at receipt. A part that arrives physically on time but cannot be released is not truly on time.
    • Recovery and resilience: shortage recovery time, premium freight incidence, supplier-driven line-stop events, and performance on critical parts. These show whether collaboration works under disruption, which is usually where scorecards fail.

    If you need a practical shortlist, many teams start with 6 to 8 KPIs:

    1. On-time delivery to original commit date
    2. On-time delivery to need date for critical parts
    3. Supplier NCR rate
    4. Repeat nonconformance rate
    5. Corrective action closure cycle time
    6. Documentation and cert completeness at receipt
    7. Engineering change adoption lag
    8. Shortage recovery time

    What makes these KPIs credible

    The KPI set only reflects collaboration performance if definitions are strict and data sources are aligned. In brownfield aerospace environments, supplier performance data is often split across ERP, receiving, quality, email, portal tools, spreadsheets, and sometimes MES or PLM. If promise dates are overwritten, NCR coding is inconsistent, or cert review is manual and disconnected, the scorecard can look precise while being operationally weak.

    Common dependencies include:

    • consistent part criticality and supplier segmentation
    • clear event timestamps across PO, ASN, receipt, inspection, NCR, and closure workflows
    • stable master data and revision control
    • agreement on whether partials, split lots, and held receipts count as on time
    • documented ownership for corrective action and engineering response metrics

    Tradeoffs and failure modes

    There are real tradeoffs. A scorecard weighted too heavily toward delivery can drive expedites and paperwork shortcuts. A scorecard weighted too heavily toward defect counts can punish suppliers who report transparently while hiding low-visibility process drift elsewhere. Very detailed KPI stacks also create reporting burden and disputes over data rather than improvement.

    Failure modes to watch for include:

    • measuring last-promise delivery instead of original commitment reliability
    • ignoring first-pass document completeness
    • combining minor paperwork defects with major product escapes into one quality number
    • failing to separate supplier-caused delays from buyer-driven schedule churn
    • using one scorecard for all commodities despite very different risk profiles

    In regulated, long-lifecycle aerospace programs, this usually means you should improve data linkage and workflow discipline before attempting a full supplier system replacement. Full replacement often fails because qualification burden, integration complexity, validation effort, and downtime risk are high, while legacy ERP, QMS, PLM, and portal processes still carry records needed for traceability and change control. Coexistence with existing systems is usually the safer path.

    The best answer, then, is: use a balanced KPI set anchored in delivery, quality, responsiveness, change execution, and traceability, and make sure the underlying definitions and integrations are trustworthy. Otherwise you are measuring reporting behavior more than supplier collaboration.

  • Should non-conformance be hyphenated?

    In regulated manufacturing and quality management contexts, the safest approach is to treat this as a style and consistency question, not a compliance question.

    In common usage:

    • “Nonconformity” (one word, no hyphen) is the term used in many standards (for example, ISO 9001 uses “nonconformity”).
    • “Non-conformance” (hyphenated) is widely used in industry documents, QMS procedures, and NC/CAPA systems.
    • “Non conformance” (with a space and no hyphen) is rarely preferred and is usually treated as inconsistent or informal.

    For your QMS and operational documentation, the key point is consistency:

    • Pick a primary term (for example, “nonconformity” to align with ISO language, or “non-conformance” if that is already used in your NC forms and MES/MRP fields).
    • Document the choice in your controlled style guide or document control procedure.
    • Apply it consistently across SOPs, work instructions, forms, and electronic system fields to avoid confusion in audits, investigations, and data analysis.

    If your systems already mix terms (for example, legacy MES uses “Non-Conformance” and newer QMS uses “Nonconformity”), change control and validation requirements may make it impractical to force a full cleanup. In that case, define a clear mapping in your procedures so it is obvious to auditors and users that these labels refer to the same underlying concept.

    So, “non-conformance” may be hyphenated, but it does not have to be. Choose one convention, align it with the main standards you follow where practical, and keep it consistent across your documentation and systems.

  • What is the difference between OEEA and OEEB in ISO 22400?

    ISO 22400 distinguishes multiple standardized forms of Overall Equipment Effectiveness (OEE). “OEEA” and “OEEB” are two of these variants, designed to separate different time bases and loss categories. They are not different KPIs conceptually, but different calculation models and scopes for the same family of metrics.

    Core idea: why ISO 22400 has OEE variants

    In practice, plants calculate OEE in many inconsistent ways: shifts vs 24/7, including or excluding planned maintenance, treating changeovers differently, and so on. ISO 22400 introduces variants such as OEEA and OEEB to:

    • Make the underlying time base explicit.
    • Clarify which losses are in or out of scope.
    • Allow more apples-to-apples comparisons across lines or plants.

    Each variant is a specific, defined way to slice the same operating time and production data. Which one is appropriate depends on your operating model and the questions you are trying to answer.

    Typical difference between OEEA and OEEB

    The exact definitions and formulas are in the ISO 22400 standard itself and should be treated as the authoritative source. In broad terms used by many practitioners who follow ISO 22400 guidance:

    • OEEA is usually defined on a narrower, more “pure equipment” time base, often focusing on periods when the machine is expected to run and excluding certain planned non-production times.
    • OEEB is usually defined on a broader time base that includes more categories of loss (for example, some planned stops) so that the number reflects more of the “real-world” utilization picture.

    The intent is to separate a metric that primarily reflects equipment performance during scheduled running time (often closer to OEEA) from one that reflects overall effectiveness across a wider slice of calendar or shift time (often closer to OEEB). The precise categorization of losses (availability, performance, quality and their sub-losses) and the associated formulas are defined in detail in ISO 22400 and can vary by part of the series (e.g. 22400-2, 22400-5).

    Because individual companies and software vendors use the labels “OEEA” and “OEEB” inconsistently, you should:

    • Refer directly to the current ISO 22400 text used in your organization.
    • Document your chosen interpretation unambiguously in your data model, work instructions, and system configuration.
    • Ensure the naming in dashboards and reports matches that documented interpretation.

    Implications for regulated and brownfield environments

    In aerospace, defense, and other regulated manufacturing, the distinction between OEEA and OEEB matters because:

    • Traceability and auditability: If you use OEE for management decisions, capacity planning, or continuous improvement justifications, auditors and customers may expect you to show how it is calculated and which time and loss categories are included.
    • Mixed system reality: Legacy MES, SCADA, historians, and spreadsheets may already be computing a homegrown “OEE” that does not map cleanly to OEEA or OEEB. Forcing a hard switch to a single ISO variant without a mapping plan often breaks historical trend analysis and confuses stakeholders.
    • Validation burden: If OEE feeds any validated planning, scheduling, or cost models, changing from an OEE-like metric to strict OEEA or OEEB is a change that must be impact-assessed, tested, and documented under your change control process.

    Full replacement of all existing OEE calculations with a single ISO 22400 variant across a brownfield landscape frequently fails, not because the standard is wrong, but because:

    • Different lines or value streams genuinely need different time bases (e.g., batch vs continuous, 5×8 vs 24/7).
    • Re-implementing every dashboard, report, and integration to align with a single variant can be disruptive and costly, especially when systems are validated.
    • Historical benchmarks, targets, and contractual KPIs are often tied to legacy definitions that cannot be abandoned quickly.

    A pragmatic pattern is to map existing metrics to the closest ISO 22400 variants, label them clearly, and gradually converge where the cost and risk are justified.

    Practical steps if you want to use OEEA and OEEB

    To apply OEEA and OEEB meaningfully in your plant:

    1. Obtain and freeze the reference: Make the specific ISO 22400 edition(s) you follow part of your controlled documents. Do not rely on secondary summaries.
    2. Define loss categories precisely: Create a plant-level loss model that maps your actual events (planned maintenance, changeover, setups, standby, micro-stops, speed loss, scrap, rework) to the availability, performance, and quality buckets as defined for OEEA and OEEB.
    3. Map existing data sources: For each line, identify which systems provide run/stop signals, counts, scrap data, and planned stops. Verify that your MES/SCADA tags and event codes can be unambiguously mapped to the ISO categories; if not, plan a staggered clean-up and re-coding.
    4. Implement side-by-side calculations: Before retiring any legacy OEE definition, run OEEA and/or OEEB in parallel for a period. Document differences and agree with stakeholders on how targets will be revised.
    5. Validate and document: In regulated environments, treat the OEE calculation logic as configuration that must be version-controlled, change-controlled, and testable. Keep calculation examples and test cases as evidence.

    Ultimately, the difference between OEEA and OEEB in ISO 22400 comes down to which time you count, which losses you include, and how you want to use the metric. The standard provides the structure, but it is your responsibility to implement and document a consistent interpretation that fits your systems, products, and regulatory context.

  • Who should own KPI governance in an ISO 22400 project?

    In an ISO 22400 project, KPI governance should not sit with a single department. The most robust pattern in regulated, brownfield environments is a cross-functional KPI governance group, usually led by operations but with explicit, shared ownership across operations, quality, IT/OT, and finance.

    Primary ownership: cross-functional KPI governance group

    In practice, KPI governance is best owned by a formal KPI governance group or steering committee that reports into existing operational governance (for example, an operations excellence board or site leadership team). This group should be explicitly chartered for ISO 22400 metrics and aligned with existing management review structures.

    Typical chair and members:

    • Chair: Operations or manufacturing leadership (e.g., Plant Manager, Director of Operations, or VP Manufacturing), because ISO 22400 KPIs primarily describe manufacturing performance and are used to run the plant.
    • Core members:
      • Quality (e.g., Site Quality Head or Quality Systems lead) to ensure KPI definitions, data usage, and change control align with QMS, validation expectations, and regulatory commitments.
      • IT/OT (e.g., MES architect, OT lead, or IT manufacturing systems lead) to own data lineage, integration design, system performance impact, and cybersecurity constraints.
      • Finance / Controlling to align KPI formulas and time-basis with financial reporting and avoid conflicting “truths” for utilization, OEE, or cost-related metrics.
      • Continuous Improvement / Industrial Engineering to ensure KPIs support realistic improvement programs and standardized work measurement.

    This group owns the KPI framework and decisions, not the day-to-day measurement. Daily data collection and review typically remains within operations, line leadership, and existing MES/reporting teams.

    What the KPI governance group should own

    Regardless of organizational chart, someone must explicitly own these responsibilities. In a mature ISO 22400 initiative, the governance group should control:

    • KPI catalog and scope
      • Selection of which ISO 22400 KPIs are in scope by plant/asset/area.
      • Standard naming, units, and aggregation levels across sites where feasible.
      • Clear mapping from ISO 22400 concepts to local terminology to avoid ambiguity.
    • Definitions and calculation rules
      • Formal, versioned definitions of each KPI, including inclusions, exclusions, and timing.
      • Resolution of contentious edge cases (e.g., what counts as “planned downtime,” “rework,” or “microstop” in your context).
      • Alignment of formulas across MES, data lake/BI, and any local spreadsheets to avoid multiple versions of the same KPI.
    • Data sources and lineage
      • Approved source systems and signals for each KPI: MES, historians, ERP, LIMS, QMS, PLC tags, etc.
      • Data lineage and transformation rules from raw signals to KPI-ready data.
      • Expectations for data quality checks, reconciliation, and exception handling.
    • Change control and validation
      • Change process for KPI formulas, thresholds, and visualizations, integrated with existing IT and QMS change control.
      • Impact assessment for regulated contexts (e.g., whether a change affects validated reports, batch record content, or management review inputs).
      • Approval workflows and documentation for audits and internal traceability.
    • Usage and behavior
      • Guidance on how KPIs should and should not be used (e.g., for tier meetings, incentive schemes, supplier reviews).
      • Alignment of KPI targets with realistic process capability and qualification constraints.
      • Training expectations so that supervisors and engineers interpret metrics consistently.

    Why a single-owner model usually fails in regulated plants

    It is tempting to assign KPI governance to a single function (e.g., IT, quality, or a central analytics team). In most ISO 22400 implementations in regulated, long-lifecycle environments, this creates problems:

    • IT-only ownership often leads to technically correct dashboards that misrepresent actual operations because key edge cases, rework flows, and shop-floor realities are not captured. It can also conflict with quality and validation expectations.
    • Quality-only ownership may bias toward audit-friendly metrics and document-heavy processes that slow operational updates and discourage iterative improvement.
    • Operations-only ownership can optimize local decision-making but neglect data lineage, integration constraints, and alignment with corporate financial and regulatory reporting.
    • Corporate analytics-only ownership risks creating a parallel “metrics universe” that diverges from what MES, ERP, and local plants actually use, undermining trust.

    In brownfield environments with multiple MES, ERP, SCADA, and data lake solutions, a single function rarely has authority and context across all systems. Cross-functional governance is usually the only practical way to manage the tradeoffs among accuracy, usability, and compliance.

    Fitting ISO 22400 KPI governance into brownfield reality

    ISO 22400 projects almost always coexist with legacy metrics, site-specific dashboards, and long-qualified systems. Effective ownership should acknowledge that:

    • Full replacement of existing KPIs is rarely feasible in the short term. Replacing long-standing metrics or reports can trigger revalidation, retraining, and re-baselining of improvement programs. The governance group should plan for coexistence and phased convergence.
    • Site autonomy and corporate standards must be balanced. The governance group may define a core, standardized ISO 22400 KPI set, while allowing controlled local extensions with clear labeling and documentation.
    • Integration debt is a constraint, not an afterthought. OT and IT representatives must be able to say “no” or “not yet” when a desired ISO 22400 metric would require unsafe changes to PLCs, impactful MES outages, or brittle data pipelines.
    • Audit and regulatory expectations limit rapid changes. For plants where KPIs feed into management review, quality indicators, or batch release decisions, even “purely operational” metric changes can have regulated implications. Quality and regulatory affairs must be part of ownership.

    Practical ownership pattern

    A pragmatic approach many plants use for ISO 22400 KPI governance is:

    1. Charter a KPI governance group under existing operational governance, with a written mandate covering scope: ISO 22400 mapping, KPI definitions, and system-of-record decisions.
    2. Assign a single accountable leader (often a senior operations or manufacturing systems leader) who is responsible for convening the group and ensuring decisions are implemented, without owning all details personally.
    3. Define RACI for KPI lifecycle steps (design, implementation, validation where applicable, deployment, change management), spanning operations, quality, IT/OT, and finance.
    4. Embed KPI changes into standard change control so that KPI formula or source changes are treated like any other system change with risk assessment, testing or validation, and documented approvals.
    5. Review ownership annually as plants, systems, and regulatory expectations evolve, updating responsibilities and membership.

    In summary, KPI governance in an ISO 22400 project should be owned by a cross-functional governance group led by operations, with mandatory participation from quality, IT/OT, finance, and continuous improvement. Concentrating ownership in a single siloed function tends to fail in regulated, brownfield manufacturing environments.

  • Do MRO organizations always need AS9100, or is AS9110 more suitable?

    MRO organizations do not always need AS9100. AS9110 is usually more suitable when your core business is aircraft or component maintenance, repair, and overhaul rather than design and new production. However, what you actually need is driven by customer contracts, regulatory expectations, and how your organization is scoped.

    How AS9100 and AS9110 differ for MRO

    At a high level:

    • AS9100 extends ISO 9001 for aerospace design and manufacturing organizations.
    • AS9110 extends ISO 9001 for aerospace maintenance organizations (MRO), including line, base, and component maintenance.

    AS9110 emphasizes topics that are critical in MRO environments, such as maintenance process control, configuration control of in-service assets, verification after maintenance, and release to service. AS9100 emphasizes design control and new production processes, which may be less central to a pure MRO facility.

    When AS9110 is usually more suitable

    AS9110 is often a better fit if:

    • Your organization does not design or manufacture new aerospace products, and instead focuses on inspection, overhaul, modification, and repair.
    • You operate primarily as a maintenance organization under aviation authorities (for example, EASA Part-145, FAA repair station), and your customers expect an MRO-focused aerospace quality standard.
    • Your processes center on workscoping, disassembly, inspection, repair/overhaul, reassembly, test, and release to service of aircraft and components.
    • You need a standard that directly addresses used parts, maintenance records, configuration control of in-service assets, and control of outsourced repairs.

    In those cases, AS9110 typically reflects reality in an MRO shop more directly than AS9100. It can make your quality system, documentation, and audits better aligned with day-to-day maintenance workflows instead of design and new build flows.

    When AS9100 may still be required or beneficial

    There are scenarios where AS9100 is required, or where organizations choose to maintain AS9100 in addition to, or instead of, AS9110:

    • Mixed operations: If your site both manufactures new components and performs MRO activities, some OEMs and primes may prefer AS9100 for the whole site to keep supplier qualifications simpler.
    • Design activity present: If you hold design authority (for example, repairs, modifications, STCs, DER/DOA/ODA work) or perform significant design and development, customers may insist on AS9100 or a combination of AS9100 and AS9110.
    • Customer mandates: Some OEMs and defense customers specify AS9100 in supplier qualification requirements and may not yet fully recognize AS9110 as equivalent for their risk model. In those cases, your choice is constrained by contract.
    • Corporate standardization: Large multi-site organizations sometimes adopt a single corporate standard (often AS9100) for consistency even if parts of the operation are primarily MRO.

    If you are in any of these categories, you should expect to map your actual processes carefully against the required standard and be explicit about scope in your quality manual. You may also need to justify to customers and auditors how MRO-specific risks are addressed if you rely only on AS9100.

    Scope definition and brownfield reality

    The decision is rarely a clean switch between standards, especially in brownfield environments that already have a certified system, legacy documentation, and integrated MES/ERP/QMS stacks.

    • Scope matters more than the label: Certification bodies certify a scope and site, not just an industry code. You can scope one site or unit as AS9110 and another as AS9100, as long as interfaces, hand-offs, and responsibilities are clearly defined and documented.
    • Mixed systems and lifecycles: If you are running older ERP/MES/QMS tools configured around AS9100, moving to AS9110 is not just changing the certificate. It impacts procedures, routing logic, work instructions, records, and approval flows. In regulated environments with long equipment and data lifecycles, this can be a multi-year change under strict change control.
    • Validation and qualification burden: Any significant QMS restructuring in a safety-critical or defense context affects training, validation, and often customer approvals. Full replacement of systems or standards at once is high risk and often fails due to downtime constraints, integration debt, and the cost of requalification.

    Many organizations therefore evolve incrementally: maintaining AS9100 where required, while introducing AS9110-aligned practices in MRO units and harmonizing procedures gradually.

    What actually drives the decision

    From a practical standpoint, your choice should be driven by a set of concrete factors rather than a generic preference:

    • Contractual requirements: What do your current and target customers specify: AS9100, AS9110, or both? Are there flow-down requirements from OEMs or defense agencies?
    • Regulatory environment: How does your QMS intersect with aviation authority approvals (for example, Part-145, Part-21, military equivalents)? Some authorities are familiar with both standards; others may have a de facto expectation.
    • Operational profile: What percentage of your work is new build vs. MRO vs. modification/design? Where is the higher risk and scrutiny?
    • Existing QMS and IT systems: Is your current QMS structure, electronic records, and system validation more aligned to production or maintenance? What is the realistic cost and risk of re-alignment?
    • Supplier and site structure: Do you have multiple sites with different functions, and can you scope certifications differently without breaking traceability or overcomplicating audits?

    In many cases, a pure MRO business without design or manufacturing responsibilities is well served, and often better served, by AS9110 if customers accept it. A hybrid organization may need AS9100, or a combination, to cover the full lifecycle from design and production through sustainment.

    Implications for digital systems and traceability

    Whether you align to AS9100 or AS9110, regulators and customers will expect robust traceability, controlled documentation, and auditable records across maintenance and modification activities.

    • Traceability and configuration control: MRO environments must show which parts were removed, replaced, or repaired, with full lineage, especially for life-limited and serialized items. Your systems (ERP, MES/MRO, QMS) need to support this regardless of the chosen standard.
    • Change control and long lifecycles: Procedures, digital travelers, and work instructions evolve slowly in heavily regulated MRO contexts because each change impacts training, approvals, and often external audits. Any shift between AS9100 and AS9110 needs a phased, controlled plan.
    • System coexistence: It is common to have separate but integrated solutions for production, engineering, and MRO. The standard you certify to does not replace the need to map interfaces carefully: how nonconformances, concessions, and maintenance data cross between systems.

    The standard should be one part of a coherent architecture for quality and traceability, not a stand-alone decision.

    Bottom line

    MRO organizations do not always need AS9100. AS9110 is often more appropriate for pure maintenance organizations, but customer and regulatory requirements, mixed operations, and existing systems often constrain the choice. The safest approach is to analyze your actual operations and contracts, define a clear scope, and then select or combine standards accordingly, recognizing the change-control and integration implications of any shift.

  • What are typical OEM expectations for supplier AS9100 certification?

    Typical OEM expectations around AS9100 fall into a few patterns, but there is no universal rule. What is “required” depends on the OEM, the specific program or prime contractor, the part criticality, and whether you are a direct supplier or a sub-tier.

    1. Common OEM patterns for AS9100 expectations

    Across large aerospace OEMs and primes, you will usually see one or more of these patterns in supplier requirements:

    • AS9100 required for production & special processes: For hardware, assemblies, and special processes (heat treat, coatings, NDT, etc.), AS9100 certification from an accredited CB is often a baseline requirement for approved supplier status.
    • AS9100 strongly preferred, ISO 9001 sometimes accepted: Some OEMs will accept ISO 9001 with additional controls (more incoming inspection, higher audit frequency, limited scope of work) for lower-risk commodities or early-stage suppliers.
    • Design-responsible work usually requires AS9100: If you hold design authority, do significant engineering changes, or are a build-to-spec supplier, AS9100 (or equivalent aerospace QMS standard) is typically non-negotiable.
    • Service and MRO suppliers: For repair and overhaul, AS9110 or OEM-specific repair station approvals may be required in addition to (or instead of) AS9100.
    • Distributor and stockist expectations: Distributors may be expected to hold AS9120, but some OEMs accept AS9100 or ISO 9001 with additional traceability and counterfeit-part controls.

    These expectations are normally written into the OEM’s supplier quality manual, purchase order quality clauses, and supplier approval criteria. They are often flowed down from customer or regulatory requirements on specific programs.

    2. Where AS9100 is typically non-negotiable

    AS9100 certification (or an equivalent aerospace QMS standard) is most commonly treated as mandatory in these situations:

    • Flight-critical or safety-critical components, including structures, control surfaces, critical fasteners, and engine/hot section hardware.
    • Special process providers where OEMs must demonstrate control of process quality, traceability, and personnel qualification.
    • Design-responsible or build-to-spec suppliers contributing to type design or major design changes.
    • Key or single-source suppliers on certified or defense programs where risk and oversight expectations are higher.

    Even here, OEMs sometimes grant temporary or limited approvals to non-certified suppliers when there is no immediate alternative, but these are normally tied to:

    • Formal corrective actions and QMS upgrades.
    • Defined timelines for achieving AS9100 certification.
    • Increased OEM surveillance and more restrictive scopes of work.

    3. Where OEMs may allow alternatives

    In some cases, OEMs will accept alternatives to full AS9100 certification, with additional controls:

    • ISO 9001 with enhanced controls: Often used for non-critical hardware, build-to-print machining, or indirect materials. This usually comes with more incoming inspection, tighter lot acceptance criteria, and higher audit frequency.
    • OEM audits in lieu of certification: Small or niche suppliers may be allowed to operate without a formal AS9100 certificate if they pass an OEM QMS audit and accept limited approval or probationary status.
    • Program- or customer-specific carve-outs: Some defense or space programs allow specific supplier sets with their own approval rules; in those cases, program control plans and data requirements can matter as much as core certification.

    None of these alternatives remove the requirement to actually implement effective processes. OEMs still expect documented procedures, risk-based thinking, configuration control, and robust nonconformance management, regardless of the certificate on the wall.

    4. How OEMs actually evaluate suppliers beyond the certificate

    Even when AS9100 is listed as a requirement, most OEMs treat it as necessary but not sufficient. They typically look at:

    • Audit results and objective evidence: Internal audits, OEM/prime audits, and how well your processes are implemented versus just documented.
    • Nonconformance, escapes, and RCCA depth: The strength of your 8D/RCCA, containment speed, and evidence of systematic fixes.
    • Traceability and configuration control: Ability to show complete build history, revision control, and change management tied to engineering and planning systems.
    • Integration with existing systems: How your QMS and production systems coexist with legacy ERP, MES, PLM, and customer-facing portals and whether that causes data gaps.
    • Responsiveness and stability: Capacity, lead-time adherence, supplier OTD, and how you manage changes and disruptions.

    For brownfield plants with mixed systems, OEMs are very aware that AS9100-certified suppliers can still have fragmented processes, manual travelers, and weak data integrity. Certification is one input into risk classification, not a guarantee.

    5. Tradeoffs and risks for both OEMs and suppliers

    From the OEM’s perspective:

    • Requiring AS9100 across the board simplifies policy but can shrink the supplier pool, limit innovation, and create capacity constraints.
    • Allowing non-certified suppliers can increase supply options but adds audit load, qualification burden, and escape risk.

    From the supplier’s perspective:

    • Achieving AS9100 opens access to more OEMs and higher-value work but requires investment, ongoing internal audits, and disciplined change control.
    • Staying non-certified may be viable in niche or low-risk areas but constrains growth and can keep you in “high-surveillance” status with customers.

    In long-lifecycle aerospace programs, OEMs are cautious about swapping suppliers simply for certification reasons because re-qualification, FAI/AS9102 updates, and potential configuration changes carry cost, downtime risk, and documentation overhead. That is why you often see conditional approvals and phased AS9100 adoption expectations rather than abrupt cutoffs.

    6. Practical guidance if you are a supplier

    If you are trying to understand what a specific OEM expects, you should:

    • Review the OEM’s supplier quality manual and purchase order quality clauses for explicit AS9100/AS9110/AS9120 language.
    • Clarify with the OEM supplier quality engineer (SQE) how expectations vary by commodity, part criticality, and program.
    • Ask whether ISO 9001 plus OEM audit is acceptable short term while you pursue AS9100.
    • Plan QMS upgrades with realistic timelines, accounting for validation, system integration, and documentation updates across ERP, MES, and PLM, not just the certification audit.

    AS9100 certification is widely expected for serious participation in aerospace supply chains, especially on critical work, but it is only one component of how OEMs assess risk, approve suppliers, and maintain ongoing oversight.

  • What information should suppliers see about our work orders, and what should we see about theirs?

    This question refers to how much work order detail should be shared between a manufacturer and its suppliers in order to coordinate production, while still protecting sensitive commercial, technical and compliance information.

    Information suppliers typically see about your work orders

    Suppliers usually need enough information to plan, execute and confirm their part of the work, but not full visibility into your internal operations. Commonly shared elements include:

    • Identifiers and context: your purchase order number, an external-facing work-order or job number, part or material numbers, revision levels and item descriptions.
    • Quantity and timing: ordered quantities, due dates, required ship dates, and any key milestones that affect their processing or delivery.
    • Technical requirements: controlled drawings, specifications, bills of material for the portion they supply, process instructions relevant to their work, and required equipment or material characteristics.
    • Quality and compliance requirements: acceptance criteria, sampling plans relevant to the supplied part or service, required inspections or certifications, and key regulatory or customer requirements they must meet.
    • Logistics information: ship-to locations, labeling and packaging requirements, and any routing instructions.
    • Change notifications: updates to requirements, revisions or dates that affect their work, along with clear version control and effective dates.

    Suppliers are typically not given full visibility into internal labor routing, detailed cost breakdowns, unrelated operations on the same work order, or sensitive customer information unless there is a specific need.

    Information you typically see about supplier work orders

    Manufacturers usually need enough detail about supplier work orders to manage risk, schedule alignment and quality. Commonly requested elements include:

    • Order and part identifiers: the supplier’s work-order or job number, their part numbers, and cross-references to your purchase orders and item numbers.
    • Status and progress: current order status, completion percentages or operation-level status when available, and projected ship or completion dates.
    • Capacity and lead times: planned lead times, acknowledgments of requested dates, and early warning when capacity or material constraints will affect delivery.
    • Quality and nonconformance data: inspection results, certificates of conformity or analysis as applicable, and notifications of nonconformances or rework that affect delivery or product quality.
    • Traceability data: lot or batch numbers, serial numbers when relevant, material heat numbers, and genealogy links needed for regulated or safety-critical products.
    • Change and deviation records: agreed changes to specifications or dates, approved deviations or concessions, and associated references.

    Manufacturers normally do not need full access to the supplier’s internal cost structure, unrelated customer orders, or proprietary process details, unless formally agreed for technical or regulatory reasons.

    Manufacturing and MES context

    In integrated OT/IT and MES/ERP environments, this question often drives how external work orders are represented and synchronized between systems. Common approaches include:

    • Exposing a limited, supplier-safe view of internal work orders through supplier portals or EDI, omitting internal routing and cost data.
    • Mapping your purchase order and work-order identifiers to the supplier’s work-order numbers to support status tracking, traceability and genealogy.
    • Defining standard data fields for shared order status, dates and quality results so both sides can automate updates and avoid manual re-entry.

    The exact boundaries of what each party can see are usually defined in contracts, quality agreements and data-sharing policies, and may be influenced by regulatory, export-control or confidentiality requirements.

  • How long does it take to implement a manufacturing KPI framework across several plants?

    In most multi-plant environments, it takes months, not weeks.

    A practical range is 3 to 6 months for a limited pilot across a small number of lines or plants with a narrow KPI set, and 9 to 18 months or more for a broader cross-plant framework that people actually trust and use. In regulated, brownfield operations, the timeline is usually driven less by dashboard development and more by data alignment, governance, validation, and rollout discipline.

    What drives the timeline

    • KPI definition and semantic alignment: If plants use different definitions for scrap, rework, downtime, first pass yield, OEE, or schedule adherence, standardization can take significant time. This is often the hardest part.
    • Data readiness: If ERP, MES, historians, CMMS, QMS, spreadsheets, and manual logs all contribute data, the implementation depends on how complete, timely, and reconcilable those sources are.
    • Master data quality: Common equipment, routing, product, reason code, and work center structures matter. Without that, cross-plant comparisons are often misleading.
    • Brownfield integration complexity: Mixed vendors, legacy interfaces, and site-specific customizations typically slow implementation more than expected.
    • Governance and change control: In regulated environments, changes to calculations, source mappings, workflows, or evidence trails may require formal review, testing, and approval.
    • Plant variation: A framework is faster when plants run similar processes. It takes longer when each site has different product mix, automation level, shift model, and data capture discipline.
    • Adoption model: If leaders want KPIs used for daily management, escalation, and corrective action, operator, supervisor, engineering, quality, and IT workflows all need to be aligned. That takes longer than publishing a dashboard.

    Typical implementation pattern

    • 0 to 8 weeks: Scope, KPI selection, source-system assessment, data profiling, stakeholder alignment, and governance decisions.
    • 2 to 4 months: Canonical metric definitions, source mapping, prototype calculations, exception handling, and pilot dashboards or reports.
    • 4 to 9 months: Pilot stabilization, site feedback, reconciliation against existing reports, role-based views, and rollout preparation.
    • 9 to 18+ months: Cross-plant deployment, ongoing change control, data quality improvement, and integration of KPI review into management routines.

    Those ranges assume the goal is a reliable operational framework, not just a visual layer over inconsistent data.

    Why timelines slip

    The most common failure mode is assuming this is mainly a BI project. It usually is not. A manufacturing KPI framework becomes slow when the organization discovers that plants are measuring different things, entering data differently, or relying on unofficial spreadsheet logic that no one wants to retire.

    Another common issue is trying to replace existing systems to force standardization. In regulated, long-lifecycle environments, full replacement strategies often fail or stall because of qualification burden, validation cost, downtime risk, integration complexity, and the need to preserve traceability and controlled change. Coexistence is usually the realistic path: harmonize KPI logic across MES, ERP, QMS, historians, and local plant systems first, then retire redundant reporting pieces selectively.

    How to shorten the timeline without creating bad metrics

    • Start with a small KPI set tied to specific decisions, not a long executive wish list.
    • Define calculation logic, exclusions, and data ownership before building dashboards.
    • Separate global KPI standards from plant-specific drill-down metrics.
    • Use one pilot plant or value stream to expose data and governance issues early.
    • Plan for reconciliation against current reports, even if those reports are flawed.
    • Treat master data cleanup and reason-code governance as part of the implementation, not a later phase.

    If the question is whether several plants can have a useful KPI framework quickly, the answer is yes, but only in a limited scope. If the question is whether several plants can have a fully standardized, trusted, audit-defensible KPI framework quickly, usually no.