Connect981 – Content Dev

FAQ Tag: brownfield integration

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

  • Is ISO 22400 applicable to aerospace manufacturing and MRO operations?

    Yes, with limits.

    ISO 22400 is applicable to aerospace manufacturing and many MRO operations as a framework for defining and calculating operational KPIs. It can be useful where teams need more consistent performance measurement across lines, cells, work centers, or sites. However, it is not aerospace-specific, and it is not a substitute for the quality, traceability, configuration, maintenance, or regulatory controls that aerospace environments require.

    In practice, ISO 22400 is most helpful when you want a common language for measures such as availability, utilization, throughput, delay, or quality-related production performance. It is less helpful if the underlying process data is fragmented, manually captured, inconsistently timestamped, or modeled differently across systems and sites.

    Where it fits in aerospace

    In aerospace manufacturing, ISO 22400 can support KPI standardization for production execution, constraint analysis, downtime classification, and cross-site reporting. In MRO, it can also support selected operational metrics such as turnaround flow, resource utilization, queue time, and maintenance execution performance.

    That said, aerospace and MRO environments often have characteristics that make direct KPI standardization harder than it looks:

    • high-mix, low-volume work with routing variability
    • rework, concessions, inspections, and engineering holds that distort simple cycle metrics
    • serialized traceability and genealogy requirements
    • mixed planned and unplanned maintenance activity in MRO
    • long asset lifecycles and legacy systems with inconsistent event models
    • manual or semi-digital data capture for key steps

    So the answer is not that ISO 22400 is inapplicable. The answer is that it is applicable only if you adapt it carefully to aerospace operating reality.

    What ISO 22400 does not do

    ISO 22400 does not tell you how to satisfy aerospace quality requirements, maintenance record requirements, or audit expectations. It does not define your digital thread, your device qualification approach, or your evidence model. It also does not resolve differences between ERP, MES, EAM, QMS, and MRO system semantics.

    It should be treated as a measurement standard, not as an execution or compliance framework.

    Key dependencies before it works well

    • Data readiness: KPI formulas are only as reliable as the event data behind them. If downtime, inspection waits, rework loops, or maintenance states are not captured consistently, KPI output will be misleading.

    • Semantic governance: Terms such as runtime, planned stop, unplanned stop, good unit, completion, release, and turnaround may be defined differently across plants or vendors. Those differences have to be reconciled.

    • System integration: In aerospace brownfield environments, data usually lives across MES, ERP, QMS, historian, CMMS or EAM, and sometimes spreadsheets. KPI harmonization often depends more on integration quality than on the standard itself.

    • Validation and change control: If KPI logic feeds management decisions, quality workflows, or regulated reporting, formula changes, mappings, and source system updates need controlled governance.

    • Operational fit: Some ISO 22400-style measures fit repetitive production better than complex teardown, inspection, repair, and return-to-service workflows. MRO often needs adaptation rather than direct adoption.

    Brownfield reality

    Most aerospace manufacturers and MRO organizations do not implement ISO 22400 by replacing their current stack. They layer KPI standardization on top of existing systems. That usually means mapping events and master data across MES, ERP, PLM, QMS, and maintenance platforms, then governing the calculation logic centrally.

    Full replacement strategies often fail in these environments because qualification burden, validation cost, downtime risk, integration complexity, and long equipment lifecycles are high. A phased coexistence model is usually more realistic, but it also means KPI consistency may remain partial for some time.

    Practical conclusion

    Yes, ISO 22400 can be applicable to aerospace manufacturing and MRO operations, but only as a structured KPI framework. It is most valuable when used to improve metric consistency across mixed systems and sites. It is less valuable if organizations expect it to solve traceability, compliance, or execution control problems by itself.

    If you use it, expect to spend significant effort on data mapping, event definitions, exception handling, and governance. The main risk is not that the standard is wrong. The main risk is that the plant data model and system landscape are too inconsistent for the KPI outputs to be trusted.

  • How do we handle late-arriving quality data that changes KPI values?

    You do not prevent KPI changes just because the quality data arrived late. You handle them by designing the KPI process to support restatement, traceability, and period close rules.

    In regulated manufacturing, late-arriving data is normal. Inspection results, nonconformance decisions, supplier quality events, rework completion, and MRB outcomes often land after the production event they belong to. If your KPI logic assumes all source data is complete in real time, the KPI will drift or become misleading.

    What to do in practice

    • Version KPI results. Store the value as initially published and any later restated value. Keep timestamps, calculation version, source systems used, and who or what triggered the recalculation.

    • Define a close window. Set operational rules such as provisional during shift, preliminary during the reporting period, and closed after a defined cutoff. The right window depends on inspection lead times, supplier latency, and review workflow maturity.

    • Track effective date and posted date separately. The event may belong to last week operationally but only be posted today. You need both dates to allocate the impact correctly and to explain why the number changed.

    • Require reason codes for restatements. Separate causes such as delayed inspection entry, NCR disposition, supplier rejection, rework failure, master data correction, or integration retry. Without this, users will not trust the changes.

    • Publish provisional and finalized views. Executives may need a current operational signal, while quality and finance may need a controlled period-close number. Those are often different views of the same metric, not a single universal truth.

    • Preserve lineage to source records. A changed KPI should be explainable back to the lot, serial, work order, inspection result, NCR, or supplier event that caused the change.

    • Control metric logic changes. If the formula, inclusion rules, or defect coding changes, that is a separate issue from late data. Treat it under change control so users can distinguish data latency from metric redefinition.

    Tradeoffs and failure modes

    There is no perfect approach. Fast reporting improves responsiveness but increases later restatements. Long close windows improve stability but reduce timeliness. Some plants prefer daily operational KPIs that are expected to move, plus locked monthly KPIs for management review. Others accept restatements indefinitely for traceability-heavy measures. The right choice depends on how the KPI is used.

    Common failure modes include:

    • Overwriting old values so no one can explain what changed

    • Mixing event time and transaction-posting time inconsistently across systems

    • Recomputing historical KPIs after master data changes without flagging the impact

    • Using dashboards that show one number with no provisional or final status

    • Closing periods manually in one system while late transactions continue flowing from another

    Brownfield system reality

    In mixed MES, ERP, QMS, LIMS, and supplier portal environments, late data is usually an integration and governance issue as much as a quality issue. One system may record the production event, another the inspection result, and another the disposition. If keys, timestamps, status mappings, and defect codes do not align, KPI restatement becomes inconsistent or impossible.

    This is why full replacement is often the wrong answer. Replacing MES, ERP, QMS, and related integrations just to stabilize KPI behavior usually creates more risk than it removes, especially where validation, qualification, downtime limits, and long asset lifecycles apply. In most plants, the workable path is coexistence: define a canonical event model, map source states carefully, add audit trails, and make KPI status explicit rather than pretending the source landscape is cleaner than it is.

    Governance expectations

    If a KPI can change after publication, document that behavior. Define who can approve corrections, when a reporting period is frozen, which metrics allow restatement, and how stakeholders are notified. For regulated operations, the goal is not to guarantee a static number. The goal is to make changes controlled, explainable, and traceable.

    If you cannot show why a KPI changed, when it changed, and which source record caused it, the problem is not just analytics quality. It is data governance and evidence quality.