Connect981 – Content Dev

FAQ Tag: master data

  • What KPIs should be on a COO’s manufacturing dashboard?

    A COO’s manufacturing dashboard should not be a long list of plant metrics. It should show a disciplined set of KPIs that answer seven questions: Are we shipping on time, are we building the right mix, where is capacity constrained, what quality losses are growing, what supply risks are now affecting output, how stable is execution, and how much confidence should leadership have in the data.

    For most regulated manufacturing environments, the core dashboard usually includes:

    • On-time delivery and schedule attainment: customer OTD, promise-date adherence, and daily or weekly schedule attainment by value stream or site.
    • Throughput and flow: completed units or orders versus plan, cycle time, lead time, queue time, and bottleneck utilization.
    • Quality loss: first-pass yield, defect or NCR rate, rework rate, scrap, and cost of poor quality.
    • Capacity and labor effectiveness: constraint-center loading, labor hours versus standard, overtime dependency, and backlog aging.
    • Inventory and material readiness: shortage-driven stops, WIP age, inventory accuracy where it affects execution, and kit or material availability at release.
    • Supplier performance: supplier OTD, incoming quality issues, and late or incomplete outside processing returns where relevant.
    • Execution discipline and traceability health: work orders released without complete prerequisites, overdue deviations or concessions, open CAPA aging, and missing or late production records where those issues create business risk.

    If the dashboard stops there, it is incomplete. A COO also needs a few leading indicators, not just outcomes that are already visible in the P&L. Useful leading indicators often include:

    • Schedule volatility or replan frequency
    • Constraint queue growth at critical work centers
    • Shortage exposure for the next one to four weeks
    • Rework hours as a share of total direct labor
    • Aging of open nonconformances, MRB actions, or engineering dispositions
    • Training or certification gaps blocking planned work
    • Unplanned downtime or NPT on assets that control plant output

    What should be on the first screen

    For an enterprise COO view, keep the first screen to roughly 8 to 12 metrics. A practical structure is:

    • Delivery: OTD, schedule attainment
    • Flow: throughput versus plan, lead time or WIP age
    • Quality: first-pass yield, COPQ or rework and scrap trend
    • Capacity: bottleneck loading, overtime, NPT or unplanned downtime
    • Supply: shortage impact, supplier OTD
    • Risk and control: backlog aging, open CAPA or NCR aging, data-confidence indicator

    Below that, the dashboard should support drill-down by plant, program, product family, work center, and shift. Without that hierarchy, executive KPIs become scoreboard numbers with weak diagnostic value.

    What to avoid

    Do not center the dashboard on OEE alone. OEE can be useful in repetitive environments, but in high-mix, low-volume or heavily regulated operations it often obscures the actual reasons output is unstable. A COO needs to see schedule adherence, bottleneck behavior, quality loss, and material readiness alongside equipment performance.

    Also avoid KPI sets that mix incompatible definitions across plants. If one site measures yield at operation close, another at final inspection, and another excludes rework loops, the enterprise dashboard will look precise while being operationally misleading. Standard definitions, version control, and change control matter more than visual polish.

    Dependencies and constraints

    The right KPI set depends on product complexity, production mode, regulatory burden, and system maturity. A discrete aerospace plant, a process manufacturing site, and an MRO operation should not use identical dashboards.

    Data limitations should be stated plainly. In brownfield environments, KPI reliability is often constrained by:

    • Inconsistent master data across ERP, MES, QMS, and maintenance systems
    • Manual workarounds and spreadsheet-side scheduling
    • Weak event timestamps or missing production context
    • Unclear ownership of metric definitions
    • Latency between execution systems and executive reporting

    If those issues exist, the dashboard should show data confidence or freshness, not imply a level of control that the plant does not actually have.

    Brownfield coexistence is usually the practical path. Most manufacturers do not replace ERP, MES, PLM, QMS, and plant historians just to create a COO dashboard, and in regulated environments full replacement often fails because of qualification burden, validation cost, downtime risk, integration complexity, and long asset lifecycles. In practice, the dashboard usually sits over existing systems and depends on careful mapping of definitions, event logic, and traceability across them.

    How to choose the final KPI set

    A useful test is whether each KPI changes a decision at COO level. If it does not affect staffing, sequencing, escalation, capital allocation, supplier intervention, or corrective action, it probably does not belong on the main dashboard.

    A balanced manufacturing dashboard usually includes:

    1. 2 to 3 delivery and flow KPIs
    2. 2 to 3 quality loss KPIs
    3. 2 to 3 capacity and supply risk KPIs
    4. 1 to 2 control or traceability health KPIs

    That is usually enough. More metrics can exist in supporting views, but the executive dashboard should surface the few signals that reveal whether performance is improving, drifting, or being propped up by overtime, expediting, or hidden rework.

  • How do we align supplier quality systems with our AS9100 expectations?

    Start by treating supplier alignment as a controlled operating model, not a one-time audit or a blanket requirement that every supplier mirror your internal system. AS9100 expectations can be flowed down, but how well that works depends on supplier criticality, process capability, documentation discipline, data quality, and how much variation exists across your supply base.

    In practice, alignment usually means defining what suppliers must do, what evidence they must provide, how changes are controlled, and how exceptions are handled. It does not mean every supplier must run the same software, forms, or workflows that you use internally.

    What usually needs to be aligned

    • Supplier qualification and approval criteria, including risk-based segmentation by part criticality, special processes, and performance history.

    • Contract review and requirement flow-down so purchase orders, drawings, specifications, revision levels, key characteristics, and quality clauses are unambiguous.

    • Document control and revision governance, especially for drawings, work instructions, specifications, and customer-specific requirements.

    • Traceability expectations for materials, lots, serialized items, and processing history where required.

    • Inspection and acceptance evidence, including certificates, FAI-related records where applicable, test results, and nonconformance documentation.

    • Change control for product, process, source, tooling, software, inspection method, and sub-tier supplier changes.

    • Nonconformance, containment, corrective action, and escalation rules, including who can disposition what and when buyer approval is required.

    • Performance monitoring using meaningful measures such as quality, delivery, escape history, responsiveness, and repeat findings.

    How to do it without creating avoidable friction

    1. Segment suppliers by risk. Apply tighter controls to suppliers affecting airworthiness, special processes, critical characteristics, or chronic quality issues. A low-risk indirect supplier should not be managed like a critical machining or processing source.

    2. Define a supplier quality requirements matrix. Map supplier type to required controls, records, approvals, and review frequency. This reduces inconsistency across buyers, quality engineers, and programs.

    3. Flow down requirements in operational terms. Do not rely on a general statement that the supplier must comply with your quality expectations. State the exact records, approvals, traceability, revision control, notification timing, and packaging or labeling requirements expected for each category of work.

    4. Standardize evidence, not necessarily systems. Many suppliers will not be on your ERP, MES, PLM, or QMS stack. Requiring identical systems often fails. It is usually more practical to standardize submission formats, metadata, approval gates, and record retention expectations.

    5. Verify before digitizing aggressively. If supplier master data, part revisions, approved source lists, and quality clauses are inconsistent across ERP, PLM, QMS, and purchasing documents, a portal or integration layer will expose those problems, not solve them.

    6. Audit and monitor based on risk and performance. Use audits, scorecards, incoming quality trends, escape analysis, and corrective action closure quality to verify that the supplier system is functioning as expected.

    7. Control changes formally. Alignment breaks down quickly when engineering changes, supplier process changes, or sub-tier substitutions are communicated late or informally.

    What not to assume

    Do not assume that a supplier certificate by itself means your requirements are understood, implemented consistently, or evidenced in the way your customers or internal auditors expect. Certification status can inform risk, but it does not replace requirement flow-down, process verification, or record review.

    Do not assume a supplier portal will fix governance problems. If your approved supplier list, part master, revision release process, and NCR workflow are not well controlled, digital collaboration can increase confusion by moving bad data faster.

    Do not assume full replacement of supplier-facing systems is realistic. In regulated, long-lifecycle aerospace environments, replacing ERP, QMS, PLM, or supplier workflows across a multi-tier supply base often fails because of qualification burden, validation cost, downtime risk, integration complexity, and the simple reality that many suppliers operate on heterogeneous legacy systems.

    Brownfield reality

    Most organizations end up with a coexistence model. Internal quality, purchasing, ERP, PLM, and supplier management tools continue to operate alongside email, portals, EDI, shared templates, and manual review steps. That is normal. The goal is not perfect uniformity. The goal is controlled traceability, clear ownership, and enough interoperability that requirements, records, and approvals can be trusted.

    If you are integrating systems, focus first on the minimum data that must stay synchronized:

    • supplier identity and status

    • approved capabilities and process scope

    • part numbers and revision levels

    • quality clauses and flowed-down requirements

    • nonconformance and corrective action references

    • certificate and record linkage

    Anything beyond that can be useful, but only if the upstream data is governed and change-controlled.

    How to tell if alignment is actually working

    Look for operational evidence, not just completed forms. Useful indicators include fewer requirement escapes at receiving, better revision accuracy, faster and better-contained supplier NCR response, fewer repeat findings, stronger traceability completeness, and fewer manual clarifications between buyer, supplier quality, and receiving inspection.

    If those outcomes do not improve, you may have created administrative burden rather than real alignment.

    Bottom line

    Aligning supplier quality systems with your AS9100 expectations is possible, but it is mostly a governance and execution problem. The practical path is to define risk-based requirements, flow them down clearly, standardize evidence, verify performance, and build interoperability around existing systems rather than assuming every supplier can or should adopt your stack. The result depends heavily on supplier maturity, internal master data quality, change control discipline, and the quality of integration between purchasing, engineering, and quality processes.

  • Does ISO 22400 define target values or performance thresholds for KPIs?

    No. ISO 22400 does not define universal target values, pass-fail thresholds, or mandated benchmark levels for KPIs.

    Its role is to standardize how manufacturing KPIs are defined and calculated so results are more comparable and less ambiguous across systems, lines, and sites. That helps with semantic consistency, but it does not answer what a “good” value should be for your operation.

    Target values and thresholds usually have to be set by the manufacturer based on factors such as:

    • process capability and stability
    • product mix and routing complexity
    • batch size, changeover frequency, and scheduling reality
    • asset age, maintenance condition, and automation level
    • quality requirements and inspection intensity
    • data collection method, latency, and accuracy
    • site-specific business priorities such as throughput, yield, service level, or cost

    In regulated and long-lifecycle environments, this matters because a threshold is often not just an analytics choice. It may affect escalation workflows, exception handling, review cadence, and evidence expectations. If thresholds are used operationally, they should be controlled, traceable, and reviewed through normal change control rather than treated as fixed industry facts.

    There is also a practical brownfield issue: two plants can claim to track the same KPI while using different event models, downtime coding, start-stop rules, rework treatment, or master data structures. In that situation, adopting the ISO 22400 definition can improve alignment, but any target comparison is still only as reliable as the underlying data model and integration quality.

    So the short answer is:

    • ISO 22400 can help standardize KPI meaning and calculation.
    • It does not prescribe the target you should hit.
    • Any threshold still needs local governance, validation, and operational context.

    If you need target values, they typically come from internal baselining, customer or program requirements, process qualification history, benchmarking done with care, or management policy. None of those are supplied by ISO 22400 itself.

  • How can AI help with root cause analysis in quality and downtime issues?

    AI can help, but mostly as an accelerator and prioritization layer, not as an autonomous root cause engine.

    For quality issues and downtime, AI is most useful when it helps teams narrow the search space across large volumes of data such as machine states, alarms, process parameters, maintenance history, operator actions, lot history, inspection results, environmental conditions, and supplier or material changes. In practice, that means it can surface likely contributing factors, detect recurring failure signatures, cluster similar incidents, and highlight leading indicators that humans may miss in manual review.

    What it usually cannot do on its own is prove a true root cause. Correlation is not the same as causation, especially in complex production environments with recipe changes, overlapping process shifts, rework loops, incomplete downtime coding, and inconsistent master data. Any AI output still needs engineering review, traceability to source records, and controlled follow-through in the existing corrective action process.

    Where AI is actually useful

    • Finding patterns across multiple systems that are not easy to compare manually, such as MES events, historian data, CMMS records, QMS nonconformances, and ERP lot or supplier data.

    • Ranking likely drivers of scrap, yield loss, or repeat downtime based on historical incident patterns.

    • Detecting anomaly sequences before a failure or drift becomes obvious to operators or supervisors.

    • Grouping similar events so teams can see that several isolated problems may share a common mechanism.

    • Extracting usable signals from unstructured data such as technician notes, maintenance logs, shift handoff comments, or inspection narratives.

    • Suggesting investigation paths, checks, or evidence sources for engineers running RCCA or CAPA workflows.

    What has to be in place first

    AI performance depends on data readiness more than model sophistication. If event timestamps do not align, downtime reasons are vague, alarm floods are unmanaged, genealogy is incomplete, maintenance records are inconsistent, or quality dispositions are poorly coded, the output will be weak or misleading.

    At minimum, useful RCA support usually requires:

    • Reliable timestamps and event sequencing across systems

    • Consistent asset, material, and process identifiers

    • Usable downtime, defect, and nonconformance coding

    • Sufficient historical volume for the failure modes in question

    • Known context for process changes, maintenance actions, and engineering changes

    • A review process that can validate or reject model suggestions

    If those basics are missing, AI may still help with triage, but not with high-confidence root cause determination.

    Quality and downtime use cases differ

    For quality issues, AI often works best when linked to traceability, inspection results, genealogy, recipe or routing data, and nonconformance history. It can help identify whether defects are associated with specific material lots, machine conditions, tool wear patterns, work instructions, or process windows.

    For downtime issues, AI often performs best when it can analyze alarm sequences, state transitions, sensor trends, maintenance interventions, spare part changes, and shift or crew patterns. Here the limitation is often poor downtime coding or weak linkage between control-system events and maintenance records.

    In both cases, the model is only as credible as the evidence chain behind it.

    Brownfield reality

    In most regulated plants, AI for RCA has to coexist with existing MES, ERP, PLM, QMS, historians, CMMS, and SCADA or PLC environments. That is normal. The practical approach is usually to add an analytics layer, data pipeline, or targeted application on top of current systems rather than replace them.

    Full replacement strategies often fail because the qualification burden, validation effort, downtime risk, integration complexity, and traceability requirements are too high relative to the expected benefit. Long equipment lifecycles and mixed-vendor stacks make this more difficult, not less. In many cases, the highest-value work is not the model itself but the integration and data conditioning needed to make incident evidence comparable across systems.

    Tradeoffs and failure modes

    • Better detection speed can come at the cost of explainability if model outputs are opaque.

    • Highly accurate models on one line, product family, or asset class may not generalize well to another.

    • Unstructured-text analysis can extract useful clues, but technician notes and shift language are often inconsistent.

    • Models can reinforce bad coding habits if they are trained on noisy or biased incident data.

    • Rare but severe events are hard to model because there may be little historical data.

    • If engineering changes, tooling updates, or process revisions are not linked cleanly to events, AI may point to the wrong factor.

    • Without change control, versioning, and documented review criteria, trust in the system degrades quickly.

    What success looks like

    A realistic goal is not automated root cause closure. A realistic goal is faster, more consistent investigation with better evidence. For example, AI may reduce the time needed to identify likely contributing factors, improve repeat-issue detection, or help standardize how incidents are compared across shifts or sites.

    That still requires human ownership. Engineering, quality, maintenance, and operations should review recommendations, confirm whether they are plausible, and document the basis for any corrective or preventive action. In regulated environments, that review trail matters as much as the analytical result.

    So the short answer is yes: AI can materially help with root cause analysis in quality and downtime issues. But it works best as a decision-support layer attached to disciplined data, traceability, and existing RCA or CAPA processes, not as a substitute for them.

  • How do we prevent RCA from becoming a paperwork exercise?

    By making RCA accountable for results, not document completion.

    If the process rewards closing forms instead of reducing recurrence, RCA will become administrative theater. That is common in regulated operations where documentation is necessary, but documentation alone does not prove the cause was found or that the fix worked.

    A practical way to prevent that is to require every RCA to answer four questions with evidence:

    • What failed, where, and under what conditions?
    • What evidence supports the suspected cause rather than a symptom?
    • What corrective action changes the system, method, control, training, design, or supplier condition that allowed the failure?
    • How will effectiveness be verified over time?

    What usually turns RCA into paperwork

    • Using a template as the goal instead of a decision tool.
    • Stopping at operator error, missed step, or retrain the team.
    • Running RCA without reliable defect, process, maintenance, or traceability data.
    • Separating RCA from NCR, CAPA, deviation, supplier quality, and production follow-up.
    • Closing actions based on completion, not effectiveness.
    • Launching full investigations for every event, including low-risk issues that need correction but not deep analysis.

    In other words, RCA degrades when the organization cannot distinguish between symptom, cause, contributing factor, and control failure, or when it lacks the discipline to verify whether the problem actually stopped recurring.

    What works better

    • Trigger RCA selectively. Not every issue needs a full investigation. Define escalation criteria based on risk, recurrence, severity, customer impact, escape point, and cost of poor quality.
    • Use evidence thresholds. Require data, records, samples, trend history, process conditions, equipment state, revision history, or supplier evidence before accepting a root cause.
    • Ban weak closure language. Actions like retrain, remind, be more careful, or update awareness may be supporting steps, but they are rarely sufficient as primary corrective action.
    • Separate containment, correction, corrective action, and preventive action. Teams often collapse these into one task, which hides whether the system changed.
    • Assign cross-functional ownership. Quality alone should not carry RCA. Operations, engineering, maintenance, manufacturing engineering, supplier quality, and IT may all own part of the evidence or the fix.
    • Measure recurrence. Track repeat defects, repeat escapes, repeat downtime modes, and action effectiveness by category. If the same issue returns, the prior RCA was incomplete, incorrect, or not sustained.
    • Time-box the analysis. Long investigations drift into narrative writing. Set deadlines for containment, hypothesis testing, corrective action approval, and effectiveness review.
    • Link RCA to change control. If the fix changes process parameters, work instructions, routing, software logic, inspection plans, training records, supplier controls, or maintenance tasks, those changes need controlled implementation and traceable approval.

    How digital systems help, and where they do not

    Digital workflows can reduce paperwork, but they do not automatically improve RCA quality. A QMS or NCR system can enforce fields, approvals, timestamps, and evidence attachment. That helps with traceability and consistency. It does not guarantee that the team identified the true cause.

    The strongest setups usually connect RCA to the systems where the evidence already lives, such as:

    • NCR and CAPA records in QMS
    • Defect, routing, and as-built history in MES
    • Part, revision, and change data in ERP or PLM
    • Calibration, maintenance, and asset condition records in CMMS or EAM
    • Supplier lots, certificates, and outside processing records in supplier quality workflows

    In brownfield plants, that connection is often partial. Data may be split across legacy applications, spreadsheets, email, and paper travelers. That means RCA speed and quality will depend heavily on integration quality, master data consistency, record discipline, and how much manual evidence gathering is still required.

    For that reason, full replacement is usually not the best answer. Replacing MES, ERP, PLM, or QMS just to improve RCA often fails because the qualification burden, validation effort, downtime risk, integration complexity, and long equipment and process lifecycles are substantial. In most regulated environments, improving the evidence flow between existing systems is more realistic than trying to rip and replace the stack.

    What to measure if you want RCA to stay real

    • Repeat issue rate within a defined time window
    • Escape rate after corrective action
    • Percentage of RCAs closed with effectiveness verification completed
    • Share of actions that are systemic versus training-only
    • Cycle time from detection to containment and from action to verification
    • Top recurring cause categories by product family, process step, machine, supplier, or shift

    If these metrics are not reviewed, teams will optimize for closure speed and audit appearance rather than actual learning.

    Bottom line

    RCA stops being paperwork when the organization treats it as an operational control loop: detect, contain, prove cause, change the system, verify effectiveness, and monitor recurrence. Templates matter, but only as support. The real differentiators are evidence quality, disciplined change control, cross-functional ownership, and the ability to connect the investigation to the production and quality records that reflect what actually happened.

  • How can we ensure AI recommendations are explainable for audits?

    You ensure auditability of AI recommendations by designing for evidence, traceability, and controlled use from the start. In practice, that means every recommendation needs a reviewable record of what data was used, which model and version produced it, what rules or thresholds were applied, what confidence or uncertainty indicators were available, who accepted or overrode the output, and what happened afterward.

    No single technique makes AI explainable enough for audits in every environment. The right approach depends on the use case, the risk of the decision, the model type, the quality of source data, and how tightly the AI is connected to MES, ERP, PLM, QMS, or shop floor systems.

    What auditors and internal reviewers usually need to see

    • Clear system boundaries: what the AI does, what it does not do, and whether it is advisory or automated.

    • Input traceability: the source records, timestamps, transformations, and data quality checks behind each recommendation.

    • Model governance: model version, training window, feature set, assumptions, approval status, and change history.

    • Decision evidence: the recommendation shown to the user, supporting factors, confidence indicators where appropriate, and the final human or system action taken.

    • Exception handling: what happens when inputs are missing, out of range, contradictory, stale, or outside the model’s intended scope.

    • Retention and retrieval: the ability to reproduce or at least reconstruct why a recommendation was produced at a given time.

    Practical ways to improve explainability

    • Prefer interpretable approaches where risk is high. If a simpler rules-based, scoring, or constrained model can meet the need, it is often easier to validate and defend than a more complex model. More accuracy on paper is not always worth lower explainability and higher validation burden.

    • Show reason codes, not just scores. Users and reviewers need to see the main drivers behind a recommendation, such as threshold breaches, trend shifts, process deviations, or missing prerequisites.

    • Keep a full recommendation ledger. Store inputs, outputs, model identifiers, prompt versions if generative AI is involved, user actions, overrides, and downstream results in an immutable or controlled audit trail.

    • Separate approved production logic from experimental logic. Do not let pilot models, ad hoc notebooks, or analyst-created scripts influence regulated execution without change control and documented approval.

    • Define when human review is mandatory. High-impact recommendations should have explicit review, signoff, and escalation rules. Explainability is weaker if the organization cannot show who evaluated the output and under what criteria.

    • Document failure modes. Explainability is not only about why the system made a recommendation. It is also about knowing when the recommendation should not be trusted.

    What usually fails in audit situations

    • Black-box recommendations with no preserved input context

    • Model updates that are not versioned or approved through change control

    • Recommendations based on poorly governed master data or inconsistent terminology across plants

    • AI outputs copied into records manually with no system linkage back to the source evidence

    • Generative AI responses treated as authoritative without prompt logging, retrieval source tracking, or review workflow

    • Dashboards that summarize outcomes but cannot reconstruct a specific decision instance

    Brownfield reality

    In most plants, explainability depends less on the model alone than on coexistence with existing systems. If your AI sits on top of fragmented MES, ERP, PLM, historian, LIMS, or QMS data, then recommendation quality and auditability will be limited by integration quality and data lineage. That is common.

    Trying to replace core systems just to make AI cleaner usually fails in regulated, long-lifecycle environments. The qualification burden, validation cost, downtime risk, integration complexity, and traceability impact are too high. A more realistic path is to add controlled evidence capture, model governance, and recommendation logging around the systems already in place, then tighten interfaces over time.

    Minimum control set to aim for

    • Approved intended use and risk classification for each AI use case

    • Version-controlled model, prompt, and business-rule artifacts

    • Traceable data lineage from source system to recommendation

    • Electronic audit trail for recommendations, reviews, overrides, and outcomes

    • Periodic performance monitoring for drift, false positives, false negatives, and out-of-scope use

    • Formal change control before retraining, threshold changes, or integration changes

    • Record retention aligned with the governed business process

    If you cannot produce those records reliably, then the honest answer is no: you cannot credibly claim the AI recommendations are explainable for audit purposes yet. You may still use the system as limited decision support, but its role should be bounded until the evidence chain is in place.

  • How does ISO 22400 influence our MES and historian data schemas in aerospace manufacturing?

    ISO 22400 influences your MES and historian schemas mainly by shaping how you define, classify, and relate production events, states, time losses, and KPI inputs. It is best treated as a semantic reference model for manufacturing KPIs, not as a mandatory physical database design.

    In practice, that means your schema should be able to support consistent definitions for things like equipment status, planned versus unplanned time, job or order context, material context, quality outcomes, and the timestamps needed to calculate performance metrics reproducibly. If your current MES or historian cannot represent those concepts cleanly, ISO 22400 will expose the gap.

    What it usually changes

    • State and event modeling: You typically need clearer machine and line state codes, with governed mappings from PLC, SCADA, MES, or manual inputs into normalized status categories.

    • Time model structure: KPI calculations depend on consistent treatment of planned production time, downtime, idle time, interruptions, and changeovers. Many legacy historians capture raw tags but not the business meaning needed for comparable KPI rollups.

    • Context keys: Historian records become more useful when linked to work order, operation, part, serial or lot, resource, and revision context from MES or ERP. Without that linkage, ISO 22400 style KPIs may be mathematically possible but operationally weak.

    • Calculation provenance: You need traceable formulas, versioned mappings, and auditable assumptions for KPI derivation. In regulated aerospace environments, undocumented KPI logic is usually a governance problem even if the math is simple.

    • Master data alignment: Resource hierarchies, operation definitions, unit conventions, and reason codes often need cleanup before KPI standardization works across cells or plants.

    What it usually does not mean

    It usually does not mean redesigning your MES schema from scratch or forcing your historian into a fully ISO-shaped schema. That is often unnecessary and risky in brownfield aerospace environments.

    Most plants already have mixed vendor systems, qualified interfaces, legacy tag structures, custom reason codes, and long-lived assets. Replacing or heavily restructuring those systems can trigger validation effort, reporting disruption, interface breakage, and change control overhead that outweigh the benefit.

    A more realistic pattern is to keep existing schemas where they are stable, then add a governed semantic layer, mapping layer, or canonical KPI model above them. That allows you to normalize definitions without forcing wholesale replacement of MES, historian, ERP, PLM, or QMS structures.

    MES versus historian impact

    MES is usually where operational context, workflow state, genealogy links, labor transactions, and quality dispositions are managed. ISO 22400 pressure on MES tends to show up as better event capture, more disciplined status models, and more consistent production transaction semantics.

    Historians usually store high-frequency time series and equipment signals. ISO 22400 pressure on historian design is more about ensuring the data can be mapped to governed states and time buckets, not about turning the historian into a full manufacturing context system. If your historian lacks reliable event boundaries or asset hierarchy discipline, KPI quality will be limited.

    In short, the MES often owns business context, while the historian provides machine-time evidence. KPI standardization depends on both, and poor alignment between them is a common failure mode.

    Key tradeoffs in aerospace manufacturing

    • Standardization versus local reality: A single enterprise KPI model improves comparability, but local cells and programs often have real process differences. Over-normalizing can hide important operational distinctions.

    • Granularity versus maintainability: Rich event models improve analysis, but they increase integration, data stewardship, and validation burden.

    • Historian purity versus MES enrichment: Calculating everything from raw historian tags may look objective, but without MES context the metrics may be incomplete or misleading.

    • Consistency versus retrofit cost: Mapping old reason codes and state models into a standard framework is usually cheaper than schema replacement, but it introduces translation logic that must be governed carefully.

    Common failure modes

    • Assuming ISO 22400 provides a plug-and-play schema. It does not.

    • Trying to compute standardized KPIs from historian tags alone, without trusted order, operation, and quality context.

    • Leaving state mappings uncontrolled, so different lines report the same KPI with different underlying logic.

    • Ignoring revisioning of formulas, mappings, and reason-code taxonomies.

    • Launching enterprise dashboards before data readiness, time synchronization, and source reconciliation are mature enough.

    Practical approach

    1. Define the KPI semantics and calculation rules you actually need.

    2. Map required inputs to current MES, historian, SCADA, and ERP sources.

    3. Identify schema gaps in event capture, context keys, and status normalization.

    4. Introduce a governed canonical model or semantic layer before considering major schema replacement.

    5. Version-control mappings, formulas, and code lists under change control.

    6. Validate KPI outputs against known production scenarios before broad rollout.

    So the answer is yes: ISO 22400 should influence your MES and historian data schemas. But in aerospace manufacturing, it should usually influence them through governed semantics, mappings, and traceable calculation structures rather than through wholesale redesign. Whether that works depends heavily on your current data quality, asset model consistency, integration maturity, and ability to manage controlled change across legacy systems.

  • Why is it so hard to get a single view of scrap and nonconformance across multiple sites?

    Because the problem is usually not just reporting. It is semantic, procedural, and architectural.

    Across multiple sites, scrap and nonconformance data are often recorded in different systems, at different points in the process, with different meanings. One plant may classify a failed part as scrap at the machine. Another may hold it in a nonconforming inventory status until MRB disposition. A third may record the event in a QMS but post the financial impact later in ERP. Those are not the same event, even if leadership wants to see them in one dashboard.

    So yes, a single view is hard, and in many organizations the first version is misleading unless the underlying definitions and integrations are cleaned up.

    What makes it difficult

    • Different definitions by site. Sites often use the same words for different things, or different words for the same thing. Scrap, rework, use-as-is, deviation, concession, and nonconformance are not always coded consistently.

    • Different process timing. The point at which an event is created, updated, or financially recognized varies. One site may log nonconformance at operation completion, another after inspection, another only after review.

    • Fragmented system landscape. Data may be split across MES, ERP, QMS, PLM, spreadsheets, homegrown apps, and supplier portals. In brownfield environments, each system often reflects a different stage of the truth.

    • Inconsistent master data. Part numbers, routings, work centers, defect codes, reason codes, units of measure, and site identifiers are frequently not harmonized.

    • Local workarounds. Operators and quality teams often use spreadsheets or offline logs when enterprise tools are slow, rigid, or poorly matched to actual workflows.

    • Different levels of data quality. Missing fields, free-text defect descriptions, duplicate records, delayed closures, and inconsistent genealogy all reduce comparability.

    • Financial and operational views do not align automatically. A scrap event in production data does not always match the cost posted in ERP, especially when material, labor, overhead, and disposition timing differ.

    • Validation and change-control constraints. In regulated environments, changing forms, codes, workflows, interfaces, or data models is slower than leaders expect because traceability and validation matter.

    Why dashboards alone do not fix it

    A BI layer can aggregate records, but it cannot resolve conflicting definitions on its own. If Site A counts reworkable defects as nonconformance but Site B only counts dispositions that reach formal review, a combined metric may look precise while hiding major inconsistency.

    This is why many enterprise scrap and NCR dashboards become executive scoreboards with weak operational value. They show totals, but not a trustworthy cross-site comparison.

    What is usually required to get a usable single view

    • A canonical data model. You need a common structure for event type, status, disposition, quantity, cost basis, defect category, source system, timestamps, and site context.

    • A controlled business glossary. The organization has to decide what counts as scrap, when a nonconformance starts, when it closes, and how rework, concession, and supplier-related issues are represented.

    • Cross-site code mapping. Local reason codes and defect codes usually need mapping to enterprise categories. This is ongoing governance work, not a one-time cleanup.

    • System-by-system lineage. Leadership should be able to trace each metric back to its source systems and transformation rules. Without that, disputes over numbers will persist.

    • Pragmatic integration. In many cases, the right approach is federated reporting over existing MES, ERP, and QMS platforms, with selective normalization, rather than forcing an immediate full replacement.

    • Data quality controls. Required fields, status rules, duplicate checks, and closure discipline matter as much as integration technology.

    Why full replacement often fails

    In regulated, long-lifecycle manufacturing, replacing every local system to force one process is often more risky than it sounds. Qualification burden, validation cost, downtime risk, local process variation, and integration complexity are real constraints. Sites may also depend on legacy equipment and custom interfaces that cannot be retired on the timeline of an enterprise transformation program.

    That does not mean standardization is impossible. It means coexistence is usually the practical path: standardize definitions and governance first, then normalize data across systems, and only replace platforms selectively where the operational and validation case is strong.

    What a realistic answer looks like

    A true single view is possible, but only if the organization accepts that this is a governance and operating-model problem before it is a reporting problem. If definitions, workflows, and data ownership stay inconsistent, the dashboard will remain contested.

    In practice, the best outcome is often a tiered view:

    • Enterprise-level normalized metrics for trend and risk visibility

    • Site-level operational detail that preserves local traceability and workflow reality

    • Drill-back to source records for auditability, investigation, and change control

    That is less elegant than a perfectly unified system, but in brownfield multi-site operations it is often more accurate, more maintainable, and lower risk.