Connect981 – Content Dev

FAQ Tag: change control

  • What types of users should see which ISO 22400 KPIs in an aerospace plant?

    Different user groups should see different subsets of ISO 22400 KPIs, with different time horizons and levels of detail. The practical rule is simple: show each role the KPIs it can act on, not every KPI the plant can calculate.

    In an aerospace plant, that usually means operators and supervisors need near-real-time execution metrics, manufacturing and quality engineers need loss analysis and trend metrics, and leadership needs rolled-up indicators with drill-down to evidence. A single plant-wide dashboard for everyone usually creates noise, gaming, or decisions made without enough context.

    Recommended role-based KPI visibility

    • Operators and cell leads: show only the measures that help run the current job and shift. Typical examples include availability-related loss signals, schedule adherence at the work-center level, actual versus planned cycle or processing time, queue or wait conditions, first-pass outcomes where they are attributable, and bottleneck status. Avoid loading operator screens with finance-style aggregates or enterprise rollups they cannot influence directly.

    • Production supervisors and area managers: show shift and daily views of throughput, utilization, delay, nonproductive time, backlog against plan, constraint status, and reason-coded losses by line, cell, or area. These users need comparison across crews, shifts, and work centers, but still with fast access to underlying events.

    • Manufacturing engineers and industrial engineers: show trendable KPIs tied to process capability, flow, performance losses, changeover impact, asset utilization patterns, routing performance, and recurring bottlenecks. They usually need richer segmentation by part family, routing, machine, program, and revision. This is where ISO 22400 can be useful, but only if event definitions are stable and comparable across areas.

    • Quality leaders and quality engineers: show KPIs that connect production performance to yield, rework, scrap, inspection burden, and defect escape risk. They also need traceable links back to lot, serial, operation, nonconformance, and reinspection events. Quality should not rely on operational KPIs alone, because a good throughput number can hide rework loops or deferred quality cost.

    • Maintenance and reliability teams: show downtime composition, failure frequency, mean time patterns, planned versus unplanned stoppage, asset loading, and maintenance-related performance losses. In many plants, these values depend on how machine states and work-order events are mapped, so visibility should include reason-code confidence, not just the headline number.

    • Plant leadership: show rolled-up KPIs for throughput, schedule attainment, utilization, delay, quality loss, and major constraint areas, with drill-down into site, program, area, and shift. Executives need cross-functional visibility, but not at the cost of false precision. If one area is manually reported and another is machine-derived, the dashboard should make that difference visible.

    • Enterprise operations, program, and IT leadership: show normalized KPI families across plants only after semantic alignment is established. Cross-site comparison is useful for trend and capacity planning, but it often fails when plants use different routing models, reason codes, calendar rules, rework handling, or data collection discipline.

    How to decide who sees what

    A good assignment model uses four filters:

    1. Decision authority: can this user change the outcome within the relevant time window?

    2. Time horizon: is the user managing minutes, shifts, weeks, or quarters?

    3. Controllability: does the KPI reflect factors the user can reasonably influence?

    4. Data trust: is the underlying data complete and defined consistently enough for that audience?

    If a user cannot act on a KPI, or the KPI blends multiple systems with weak data lineage, it should usually be hidden from routine operational use or clearly labeled as directional.

    What usually goes wrong

    • Too many users see OEE-style rollups without context. In aerospace, high-mix, low-volume work, long inspections, engineering holds, outside processing, and qualification constraints can distort aggregated utilization or efficiency metrics.

    • Quality and execution are separated. A production dashboard may look healthy while the actual process is accumulating rework, deferred inspections, or concession risk.

    • Cross-plant standardization is assumed too early. ISO 22400 provides a framework, but not automatic semantic consistency across MES, ERP, historians, machine interfaces, and manual logs.

    • KPIs are assigned by hierarchy instead of workflow. A senior title does not always mean a broader dashboard is useful. Some leaders need exception-based views, not more indicators.

    • Manual and automated signals are mixed without disclosure. That creates false confidence and weakens root-cause analysis.

    Brownfield reality in aerospace plants

    Most aerospace plants should not try to rebuild KPI visibility by replacing all core systems at once. Full replacement often fails because of qualification burden, validation cost, downtime risk, integration complexity, and the need to preserve traceability across long-lived assets and legacy processes.

    A more realistic approach is to map KPI ownership by role, define canonical event meanings, and then expose role-specific views across the systems you already have. In practice, that often means MES provides execution context, ERP provides order and schedule context, QMS provides quality event context, and machine or historian data fills in state changes where reliable. The quality of the KPI depends less on the dashboard tool than on data governance, master data discipline, and change control.

    Practical rule of thumb

    Yes, different users should see different ISO 22400 KPIs, and often the same KPI should appear in different forms for different roles.

    • Operators: current job, current constraint, immediate loss.

    • Supervisors: shift execution, adherence, delays, bottlenecks.

    • Engineers: trends, causes, segmentation, repeatability.

    • Quality: yield, rework, defect-linked performance loss, traceable evidence.

    • Maintenance: downtime composition and failure patterns.

    • Leadership: rolled-up performance with drill-down and data-confidence context.

    If your plant cannot explain who owns each KPI, what action it drives, and which source systems feed it, the visibility model is probably not ready yet.

  • What is the difference between a work instruction revision and an ECO?

    A work instruction revision and an ECO are usually different change objects with different scope, authority, and downstream impact.

    In most manufacturing environments, a work instruction revision updates operator-facing execution content such as sequence, setup details, inspection steps, visual aids, cautions, or local process clarifications. An ECO is typically used to change controlled engineering definition such as drawings, specifications, BOM-related product definition, approved materials, dimensions, tolerances, or formal process requirements when those are owned under engineering change control.

    Put simply: a work instruction revision changes how work is executed or communicated at the shop floor level, while an ECO changes what the approved product or controlled technical definition is. In many companies, an ECO can require one or more work instruction updates, but a work instruction revision does not automatically mean an ECO is needed.

    When a work instruction revision is usually enough

    • Improving clarity, formatting, or visual guidance without changing approved product requirements

    • Reordering steps for efficiency where the validated or approved process intent is unchanged

    • Adding operator notes, photos, or training aids

    • Correcting document errors that do not alter engineering definition, inspection criteria, or approved process parameters

    • Updating references to equipment, screens, or local system transactions when the controlled requirement itself is unchanged

    When an ECO is usually required

    • Changing drawing-defined requirements, specifications, or acceptance criteria

    • Changing form, fit, function, material, configuration, or product structure

    • Changing controlled process parameters where engineering approval is required

    • Changing tooling, test methods, or manufacturing methods if those are part of the approved product or process definition

    • Making changes that affect qualification, validation, traceability, customer approval status, or downstream documentation obligations

    Why the distinction matters

    The distinction is not administrative only. It affects review authority, implementation timing, training, traceability, effectivity, and whether existing product, WIP, or inspection records remain valid.

    If a plant treats an engineering change like a simple work instruction edit, it can create audit trail gaps, configuration confusion, invalid routings, or execution against outdated product definition. If the plant routes every minor instruction cleanup through ECO workflow, change latency can become unmanageable and operators may continue using unclear documents longer than necessary.

    The correct boundary depends on your document hierarchy and governance model. Some organizations place detailed process requirements inside engineering-controlled manufacturing instructions. Others allow operations or quality to revise local work instructions within defined limits. That boundary needs to be explicit.

    In brownfield environments

    This gets harder when PLM, ERP, MES, QMS, and document control systems are split across vendors or generations. An ECO may originate in PLM, update item or BOM effectivity in ERP, require routing or traveler changes in MES, and trigger revised work instructions in a document system or digital work instruction platform.

    In that environment, the practical question is not just which label to use. It is whether your systems can keep revision alignment across engineering, execution, and quality records. Many plants cannot do this cleanly without manual controls, especially where integrations are partial, validation limits changes, and legacy assets cannot tolerate frequent system redesign.

    That is one reason full replacement programs often fail. Replacing PLM, MES, ERP, and document control at once sounds cleaner, but in regulated, long lifecycle operations it often creates high qualification burden, expensive revalidation, downtime risk, and major traceability problems during transition. Coexistence with clear system-of-record boundaries is usually more realistic than assuming one new platform will eliminate the distinction.

    Practical rule

    If the change alters approved engineering definition, required process limits, or anything that could affect configuration, qualification status, or formal acceptance criteria, treat it as potentially requiring an ECO. If it only improves execution guidance without changing controlled requirements, a work instruction revision may be enough.

    But do not assume. The deciding factor is your company’s change control model, document ownership, and validated workflow boundaries.

    When the line is unclear, a simple decision path helps:

    1. Does the change modify product definition or engineering-owned requirements?

    2. Does it affect validated process parameters, inspection criteria, tooling, or approved methods?

    3. Does it change effectivity, traceability expectations, or disposition of current WIP or inventory?

    4. Which system is the system of record for that requirement?

    If the answer to any of the first three is yes, an ECO or equivalent engineering change process is likely involved, even if the work instruction also needs revision.

  • How does MES ensure operators only see the latest approved work instructions?

    MES does not ensure this by itself. Operators only reliably see the latest approved work instructions when the MES is connected to a controlled document or content release process and is configured to block obsolete revisions at the point of use. In practice, that means approved versions are tied to the specific part, operation, work order, routing step, and effective date, and older versions are suppressed or made inaccessible for normal execution.

    What usually makes it work

    In most regulated manufacturing environments, the control depends on a few basic mechanisms working together:

    • Revision-controlled source content: The work instruction has a unique document ID, revision, approval status, and release record in MES, PLM, QMS, or a connected document control system.
    • Approved-only publication: Draft or in-review versions are not exposed to production users. The MES should present only released content for executable operations.
    • Context-based binding: The instruction shown is not just the latest file in a folder. It is the approved revision mapped to the exact product, process step, equipment, customer or program variant, and sometimes serial or lot conditions.
    • Effective date and disposition logic: New revisions often become effective only for specific work orders, lots, serial numbers, or after a cut-in point. Without that logic, “latest” can be wrong for in-process work.
    • Role-based access and UI control: Operators see the execution copy. Authors, engineers, and quality reviewers may see drafts or superseded versions, but that access should be restricted and traceable.
    • Execution blocking: If the required approved instruction is missing, expired, or not yet released for that operation, the MES should stop or hold the transaction rather than let the operator proceed on guesswork.

    What MES can and cannot guarantee

    MES can enforce what it knows. It can present the currently authorized instruction for a transaction, record which revision was acknowledged or used, and prevent normal use of superseded versions. It cannot guarantee that every operator always follows the displayed instruction, or that no uncontrolled copies exist outside the system.

    That last point matters. Plants often still have PDFs on shared drives, printed binders at the machine, screenshots in training decks, or local job aids created outside formal control. If those are not governed, the MES may be correct while the shop floor is still exposed to stale instructions.

    Common architectures

    The pattern varies by site maturity and existing systems:

    • MES-native work instructions: The instruction is authored, approved, versioned, and displayed directly inside the MES.
    • PLM or QMS controlled content with MES delivery: The source of truth sits outside MES, and MES calls or embeds the approved revision during execution.
    • Hybrid model: Core manufacturing steps are governed in MES, while drawings, specifications, or visual aids come from PLM or a document management system.

    No model is automatically better. The weak point is usually the handoff between systems: revision mapping, timing of release, and whether the MES caches or links to live content.

    Where this fails in brownfield environments

    Brownfield plants are where the claim usually breaks down. Mixed MES, ERP, PLM, and QMS stacks often have inconsistent identifiers, duplicate routings, manual document release steps, and old integrations that were never designed for strict point-of-use control.

    Typical failure modes include:

    • routing steps not correctly linked to the current instruction revision
    • PLM or QMS release completed, but MES not updated yet
    • cached local copies still displayed after supersession
    • rework, deviation, or concession instructions handled offline
    • operators printing a packet before a revision change and continuing to use it
    • training records lagging the released revision
    • multiple program-specific variants using similar but not identical instructions

    In regulated contexts, those are not minor admin issues. They directly affect traceability, evidence quality, and change control.

    Why “latest” is not always the right requirement

    The better requirement is usually “the correct approved revision for this exact job.” For example, a work order already in progress may need to finish on the previously approved revision, while new orders start on the new one. Engineering changes, deviations, customer-specific requirements, and cutover rules can make a blanket “always latest” rule incorrect.

    That is why mature MES deployments store or reference the exact revision used at execution time, not just whatever is currently active now.

    What evidence should exist

    If the control is working properly, you should be able to trace:

    • who approved the work instruction and when
    • which revision was effective for a given order, lot, or serial number
    • what the operator was shown at the time of execution
    • whether acknowledgment or training was required
    • what changed between revisions
    • whether any deviation, temporary instruction, or concession overrode standard content

    If that evidence is missing or split across disconnected systems, the process may still function operationally, but the control is weaker than people assume.

    Practical boundary

    If your MES is being positioned as the sole answer, be careful. The real control sits across document governance, change control, integration quality, and shop-floor discipline. Full replacement of legacy systems just to solve this is often unrealistic in regulated environments because of validation cost, downtime risk, qualification burden, and long-lived interfaces. More often, the workable path is to tighten revision governance and point-of-use blocking across the existing stack.

  • Can I mix ISO 22400 KPIs with custom aerospace metrics in one report?

    Yes. You can put ISO 22400 KPIs and custom aerospace metrics in one report.

    The important constraint is that they should not be treated as interchangeable just because they appear on the same dashboard. ISO 22400 gives you standardized manufacturing KPI definitions. Your aerospace-specific metrics often reflect contractual, quality, traceability, routing, inspection, or program-execution realities that the standard does not fully cover. Mixing them is usually practical. Mixing them without governance is where problems start.

    What has to be true for this to work

    • Each metric needs a clear definition, owner, calculation logic, unit of measure, time basis, and source system.

    • The report should distinguish standardized KPIs from site-defined or program-defined metrics.

    • Any rollups across plants, lines, suppliers, or programs need consistent mapping rules. If one site calculates downtime or quality loss differently, the combined report can mislead.

    • Version control matters. If a custom metric changes due to process updates, ERP or MES reconfiguration, or revised quality rules, the report should preserve traceability to the metric revision in effect.

    • If data comes from MES, ERP, PLM, QMS, historians, or spreadsheets, timestamp alignment and event granularity need to be checked. A common failure mode is comparing near-real-time machine metrics to delayed transactional quality data as if they were synchronized.

    Why teams do this

    In aerospace and other regulated environments, ISO 22400 KPIs can provide a useful baseline for performance visibility, while custom metrics cover what operations leadership actually needs to manage, such as rework burden by program, escaped defect exposure, traveler completion latency, concession volume, inspection queue age, or outside-processing delay risk.

    That combination can be valuable, especially in brownfield plants where no single system contains the full operational picture.

    What can go wrong

    • A standard KPI can look comparable across sites while the custom metric beside it is not comparable at all.

    • Custom aerospace metrics often depend on local routing practice, NCR workflows, disposition timing, or manual data entry quality.

    • Users may assume the entire report is standards-based when only part of it is.

    • If metric lineage is weak, validation and change control become difficult, especially when reports influence quality or production decisions.

    • Vendor dashboards may allow mixed widgets but not enforce semantic consistency. The tool capability does not solve the governance problem.

    Brownfield reality

    In most plants, this report will sit across multiple systems rather than come cleanly from one platform. That is normal. MES may provide equipment and execution events, ERP may provide order and cost context, QMS may hold nonconformance data, and PLM may govern product structure or revision state.

    Because of that, a full replacement approach is usually not the answer. In regulated, long-lifecycle environments, replacing core systems just to standardize reporting often fails due to qualification burden, validation cost, downtime risk, integration complexity, and the need to preserve traceability through change control. A governed integration layer or semantic model is usually more realistic than ripping out existing systems.

    Practical reporting approach

    A mixed report is usually safer if it follows three rules:

    1. Label ISO 22400 KPIs as standards-based and label aerospace metrics as enterprise-defined or program-defined.

    2. Publish metric definitions in a controlled glossary or KPI catalog tied to report logic.

    3. Do not aggregate or benchmark unlike metrics without an approved mapping rule.

    If those controls are in place, one report can be effective. If they are not, the report may still look polished but it will not be reliable enough for cross-site comparison or high-stakes operational decisions.

  • How can we quantify the impact of a design change on scrap and yield?

    You can quantify it, but only if you can separate the design change from everything else that changed around it.

    The practical method is to compare scrap and yield at the part, operation, and revision level before and after the design change, then adjust for confounders such as supplier lot, material condition, tooling state, routing changes, inspection changes, machine changes, operator mix, and production volume. If you do not control for those factors, the number may be directionally useful but not defensible.

    What to measure

    At minimum, measure the same product family across a defined baseline period and post-change period using consistent definitions.

    • First-pass yield by operation and by finished assembly

    • Scrap rate by count, unit, weight, or cost, depending on how your plant records loss

    • Rework and repair incidence, because some design changes reduce formal scrap but increase hidden recovery effort

    • Nonconformance rate and defect codes tied to the changed characteristics

    • Cost of poor quality, if finance and quality data can be linked reliably

    • Cycle time impact, because yield improvements can come with longer processing or inspection time

    Recommended approach

    1. Define the exact design change window using the approved revision, effectivity, and disposition dates.

    2. Identify the affected part numbers, configurations, routings, work centers, and suppliers.

    3. Build a pre-change baseline and a post-change observation window with enough volume to be meaningful.

    4. Segment results by operation, defect mode, machine family, supplier, and lot where possible.

    5. Exclude or flag units built during transition conditions such as mixed inventory, temporary deviations, pilot builds, training periods, or parallel routings.

    6. Compare the changed design against either its own historical baseline or a matched control population if other plant conditions were moving at the same time.

    7. Validate whether the observed shift is statistically credible, not just operationally interesting.

    How to calculate it

    A simple starting point is:

    • Scrap impact = post-change scrap rate minus pre-change scrap rate

    • Yield impact = post-change first-pass yield minus pre-change first-pass yield

    • Financial impact = change in scrap quantity or rework quantity multiplied by material, labor, outside processing, and delay cost where available

    That is only the first layer. In most brownfield plants, a better estimate comes from stratified analysis or regression that controls for major drivers such as supplier, lot, machine, shift, and inspection method. If the design change altered tolerances, materials, joining method, or inspection characteristics, those factors need explicit treatment.

    What usually makes the analysis fail

    • No reliable link between engineering revision and actual as-built unit genealogy

    • Scrap recorded only at the work order level, not by operation or defect mode

    • Mixed old and new revision inventory consumed in the same period

    • Simultaneous process changes, supplier changes, or tooling changes

    • Inspection sensitivity changed, making defects appear to rise when detection simply improved

    • Too little production volume after the change to distinguish signal from noise

    • Rework moved off the books into concession, deviation, or informal recovery activity

    In those cases, the honest answer is that you can estimate impact, but not attribute it cleanly.

    Brownfield system reality

    In many regulated environments, the needed data lives across PLM, ERP, MES, QMS, SPC, and sometimes spreadsheets. Quantification depends on whether those systems share consistent part, revision, lot, operation, and defect identifiers. If they do not, the work becomes a data reconciliation exercise before it becomes an engineering analysis.

    This is why full replacement is often the wrong first move. Replacing PLM, MES, ERP, or QMS just to answer this question usually creates more qualification, validation, integration, and downtime risk than value in the near term. A narrower approach is usually safer: improve revision effectivity tracking, strengthen genealogy, standardize defect coding, and create a governed cross-system view of scrap, yield, and design revision.

    What a credible answer looks like

    A credible result usually includes:

    • The exact design revision or effectivity studied

    • The units, lots, and time period included and excluded

    • The baseline and post-change sample sizes

    • The scrap and yield deltas by operation and overall

    • The main controlled variables and known uncontrolled variables

    • Any transition effects, temporary work instructions, or training effects

    • Confidence level or at least a clear statement of statistical and practical uncertainty

    That level of traceability matters. Without it, the analysis may still help internal decision-making, but it will not stand up well to skeptical review.

    So the short answer is: quantify the impact by linking approved design revision changes to as-built production records, then compare revision-level scrap and yield with controls for process and supply variation. If your data model, change control, or genealogy is weak, say so explicitly and treat the result as an estimate rather than a clean attribution.

  • How do we prevent local KPIs from conflicting with global definitions?

    Preventing conflicts requires governance, not just reporting standardization.

    The practical answer is to create one controlled definition for each enterprise KPI, then allow local measures only when they are explicitly labeled as local, mapped to the enterprise definition where possible, and governed through change control. If you do not separate global KPIs from site-specific operational measures, plants will optimize to different rules while appearing to report the same number.

    In most manufacturers, especially brownfield environments, KPI conflicts come from three predictable sources: different source systems, different calculation logic, and different business intent. A site may calculate throughput from MES completions, another from ERP confirmations, and another from manual shift logs. All three may call it the same KPI, but they are not equivalent.

    What usually works

    • Define a canonical KPI dictionary with approved names, formulas, units, inclusion and exclusion rules, time boundaries, ownership, and approved source hierarchies.

    • Assign business ownership for each KPI. Someone must be accountable for the definition, not just the dashboard.

    • Separate enterprise KPIs from local management metrics. Local metrics are often necessary, but they should not reuse global names unless the definition is truly identical.

    • Document source-system mappings and transformation rules. If one plant derives downtime from machine events and another from operator entry, that dependency should be visible.

    • Version KPI definitions and treat changes like controlled changes. Historical comparability often breaks when definitions shift silently.

    • Require exception handling for sites that cannot meet the global definition yet. Mark the KPI as provisional or non-comparable rather than pretending the number is aligned.

    • Validate data quality at the source. A globally defined KPI is still unreliable if timestamps, states, routings, or master data are inconsistent.

    What not to do

    • Do not force every plant into one metric definition if the underlying process states are not instrumented the same way.

    • Do not let BI teams invent KPI logic independently from operations and quality leadership.

    • Do not assume vendor standard reports solve semantic differences across MES, ERP, PLM, QMS, historians, and spreadsheets.

    • Do not replace local KPIs wholesale just to simplify reporting. That often removes useful operating signals and creates workarounds outside the governed system.

    No, there is usually no clean way to eliminate all local variation. Different products, routing structures, automation levels, and regulatory evidence requirements can justify local measures. The goal is not zero variation. The goal is to make variation explicit, controlled, and traceable so executives know which metrics are comparable across plants and which are not.

    Brownfield reality

    In mixed-vendor environments, conflicts often persist because each system represents events differently. ERP may record planned and confirmed quantities, MES may record execution states, QMS may hold disposition timing, and manual logs may fill gaps during downtime. A full rip-and-replace strategy is rarely the safest answer in regulated, long-lifecycle operations. It can trigger qualification effort, validation cost, integration rework, downtime risk, and loss of historical traceability. In practice, most organizations need a coexistence model with governed mappings, data lineage, and phased cleanup.

    That means your KPI program depends on:

    • master data quality

    • integration consistency

    • clear event models

    • controlled business glossary ownership

    • change management across plants and functions

    If those are weak, local KPI conflicts will keep returning even after a dashboard redesign.

    Minimum governance standard

    At a minimum, each global KPI should have a controlled record containing the business purpose, formal formula, source priority, refresh timing, known limitations, approval history, and comparability status by site. That is usually more effective than trying to settle disputes ad hoc during monthly reviews.

    If a plant needs a different metric to run the business, that is not necessarily a governance failure. It becomes a governance failure when the local metric is presented as the global one without definition control, traceability, and approval.