How should aerospace manufacturers identify which WIP is affected by an engineering change?

Identifying which work-in-progress (WIP) is affected by an engineering change is fundamentally a traceability and definition-of-effectivity problem. In aerospace, you cannot rely on tribal knowledge or a quick spreadsheet; you need a repeatable, auditable method that ties engineering data to actual shopfloor state.

Start with a disciplined definition of effectivity

The first step is to make the engineering change itself unambiguous. Every change should include, at minimum:

• Configuration scope: specific part numbers, assemblies, options, and revisions affected.
• Effectivity rules: how the change applies, for example:
  • By serial number range (S/N 2100–2199).
  • By lot/batch (lots shipped after date X).
  • By date/time (work started after a defined timestamp).
  • By work-order or production block (WOs 12345–12410).
• Process boundary: whether the change affects parts not yet started, in particular operations, or completed WIP awaiting shipment.
• Mandatory vs optional: whether in-process units must be reworked or may be left as-is with deviation/waiver.

Without clear effectivity rules, any downstream WIP impact analysis becomes guesswork and difficult to defend in audits or customer reviews.

Use the digital thread: PLM, ERP, and MES together

In most aerospace environments, no single system has the complete picture. Identifying affected WIP usually requires using several systems in combination:

• PLM / PDM: source of the engineering change, revised BOM, drawings, and configuration applicability.
• ERP / MRP: work-order list, planned vs released quantities, lot/batch numbers, and sometimes basic routing.
• MES / shopfloor system: operation-level status, as-built genealogy, serial/lot traceability, and operator history.

The practical sequence is typically:

1. Query ERP for all open work-orders for the affected part numbers and revisions.
2. Filter in MES for those work-orders and identify:
   • Current operation and completion status for each unit.
   • Associated serial and lot numbers.
   • Any deviations, concessions, or repairs already applied.
3. Apply effectivity rules from the change to this list (by WO, serial, lot, stage, or date).
4. Confirm configuration against PLM to ensure the correct baseline drawing/BOM and revision are used for each unit.

This only works reliably if routing steps, BOM revisions, and effectivity data are synchronized across PLM, ERP, and MES. In brownfield environments, misalignment here is a common failure mode.

Segment WIP by stage to decide actions

Once potentially affected WIP is identified, it needs to be segmented by process stage. Typical buckets include:

• Not started WIP: work-orders released but no operations begun. These are usually easiest: update routing/work instructions before work starts.
• In-process at or before the affected operation: units that have not yet passed the step impacted by the change. These are generally converted by updating instructions and training operators.
• In-process beyond the affected operation: units that have already passed the impacted step. These may require:
  • Mandatory rework to meet the new standard.
  • Formal deviation/waiver or concession if rework is impractical.
  • Customer notification, depending on contract and risk.
• Completed but not yet shipped: technically not WIP, but often in scope. Traceability should allow you to link completed units back to their build configuration and determine if rework or deviation is required.

This segmentation should be driven by the validated routing and operation list in your MES or, if absent, by tightly controlled digital travelers or paper travelers with clear versioning.

Leverage genealogy and traceability for complex assemblies

For multi-level assemblies and structures, the affected WIP is not just end items; it can include subassemblies and components already built and stored. Identifying these requires:

• Forward and backward genealogy: the ability to see which serial/lot-level components went into which higher-level assemblies, and vice versa.
• Location and status: whether those affected subassemblies are in WIP, in stock, at a supplier, or already installed on an aircraft.
• Configuration control: knowing which revision of each sub-component was installed at the time of assembly.

In many brownfield environments, genealogy is partial or split across systems and paper records. In those cases, you may need structured data clean-up and conservative assumptions, such as treating all items within a certain date window as potentially affected if traceability is incomplete.

Integrate engineering changes into standard change control workflows

To make WIP impact analysis repeatable instead of a heroic ad-hoc effort, manufacturers generally need:

• A formal ECN/ECO or ECR process that explicitly includes WIP impact assessment as a required step.
• Defined roles: engineering owns effectivity definition; operations and quality own WIP impact assessment and implementation planning.
• Standard queries and reports: pre-defined filters in ERP/MES to pull “all open WIP for part X, revision Y, with operation Z completed/not completed.”
• Version-controlled work instructions and travelers: operators can only run current, approved versions, and the system logs which version each unit followed.
• Change control in MES/ERP: WIP impact decisions (e.g., no action required, rework, deviation) are recorded and linked to the change record.

This is where full replacement strategies can be risky. Ripping out legacy MES or ERP and losing historical routing and traveler detail can make WIP impact analysis significantly harder, even if the new system is technically superior. Phased, coexistent integrations that preserve traceability are usually safer in regulated environments.

Common failure modes and how to mitigate them

Typical problems in identifying affected WIP include:

• Inconsistent revision usage: ERP, PLM, and MES show different effective revisions for the same part number. Mitigation: enforce a single source of truth for revision and effectivity, and automate synchronization where possible.
• Paper travelers with no reliable version records: makes it hard to know which version an operator used. Mitigation: controlled traveler issuance, stamping, and scanning, or gradual migration to digital travelers with enforced version control.
• Incomplete genealogy: you cannot fully trace sub-component usage. Mitigation: conservative scoping of affected WIP, with clear documentation of assumptions and potential exposure.
• Unclear effectivity definitions: engineering changes that say “effective immediately” without specifying serial/lot/WO boundaries. Mitigation: push back within the change control board until unambiguous effectivity is documented.

Evidence and auditability

In aerospace, it is not enough to identify affected WIP; you also need to prove how you did it. Practical steps include:

• Attaching system queries and reports (screenshots, exports, or report IDs) to the change record.
• Documenting assumptions where data is incomplete, along with the rationale for including or excluding certain WIP.
• Linking rework, deviation, and inspection records for affected WIP back to the original engineering change.
• Logging approvals and effective dates for updated routes and work instructions under formal change control.

This provides traceability for internal reviews, customer oversight, and third-party audits without implying guaranteed outcomes.