Work Order Integration Playbook for Aerospace Traceability

Work orders in aerospace manufacturing live at the seam between planning and execution: the ERP (enterprise resource planning) system releases the order, but the shop floor and suppliers determine what actually happens. When ERP, MES (manufacturing execution system), quality tools, and spreadsheets tell different stories, you do not just lose visibility—you lose traceability, and you start rebuilding audit evidence after the fact.

The fix is rarely “replace the ERP.” In regulated plants, ERP is the contractual and financial system of record. The practical problem is boundary control: which system owns work-order state at each stage, which events must cross that boundary, and what minimum record set must be retained so an auditor can reconstruct intent, execution, and disposition.

This playbook shows a disciplined way to integrate work orders across ERP and execution (MES/MOM) using ISA-95 / IEC 62264 thinking, with an evidence model aligned to AS9100-style expectations for documented information and traceability.

When you need this playbook

• Status looks on track in ERP but work is blocked on the floor (inspection disposition, MRB, missing material/tooling, missing certs).
• Execution proof is fragmented across paper travelers, spreadsheets, and point tools that do not share identifiers or revision context.
• Quality events are “after the fact”—nonconformances and holds exist, but they do not reliably stop downstream execution.
• Closeout requires manual reconciliation to assemble a ship-ready package (inspections, dispositions, certs, and revision-correct records).

Key Takeaways

• Keep ERP stable for order release, part masters, and financial commitments; treat execution as a separate system-of-action layer.
• Use ISA-95 / IEC 62264 boundaries to decide what belongs in Level 4 (enterprise) vs Level 3 (manufacturing operations).
• Integrate milestones, not micro-events: ERP needs planning-relevant states; the execution layer owns detailed steps, checks, and signatures.
• Make quality change execution by linking holds and dispositions to the exact operation, routing, and revision context.
• Define a minimum evidence pack per work order so audits are reviewable, not reconstructive.

Scope and system boundary: ERP vs MES/MOM

ISA-95 (also published as IEC 62264) separates enterprise planning from manufacturing operations management and describes the interface between Level 4 (enterprise) and Level 3 (manufacturing operations). Treat that interface as a contract: only information that changes enterprise decisions should flow back to ERP.

• ERP owns order release/close, part masters, top-level routing references, commitments, costing, and shipment/billing triggers.
• Execution (MES/MOM) owns dispatch, operator guidance, confirmations, in-process inspections, quality events, and revision enforcement.
• Both must share stable identifiers and revision context (WO, operation IDs, routing revision, instruction revision, lot/serial anchors).

A common anti-pattern is trying to make ERP “know everything” that happens during execution. You create noisy integrations and still cannot answer the only questions that matter: what is blocked, what revision was built, and what evidence proves ship readiness.

Evidence model: the minimum work-order record set that survives an audit

“Complete” must mean routing complete + inspections complete + dispositions resolved + required documents present. The evidence model below is intentionally minimal: it is the smallest record set that lets you answer an auditor in one sitting.

Identifiers and revision context:

• Work order ID, part number, quantity, and program/sales reference (when applicable).
• Routing ID + routing revision; operation IDs; planned work center/cell.
• Work instruction/document ID + instruction revision (the version actually presented at the station).
• Traceability anchors: issued material lot/batch IDs and produced serial numbers with parent/child links.

Execution and quality records:

• Operation confirmations (start/complete) with operator ID and timestamp (or equivalent approval evidence).
• Inspection results tied to operation ID and revision context (including re-inspection after rework).
• Nonconformance record ID, disposition, and approval evidence; hold applied/released with reason and owner.
• Ship-ready documents tracked as requirements (e.g., test report, CofC/CoC, special process certs where applicable).

Minimum “audit navigation” expectation: someone should be able to start at the WO and reach, in two to three clicks, the effective revision context, the inspection results, and the disposition trail for any open/closed defect. If the only way to do that is a shared drive and tribal knowledge, you will keep paying the reconciliation tax.

ERP should receive the subset that drives enterprise action: milestone state, material consumption with traceability anchors, and completion readiness. The execution layer retains the detailed “how.”

Step-by-step workflow for integrating work orders

1. Standardize identifiers. WO and operation IDs must be identical across systems; do not translate identifiers in interfaces.
2. Declare system roles. ERP is system of record for release/close; execution is system of action for in-process state and evidence.
3. Define milestone events. Limit ERP updates to planning-relevant transitions (released, in-process, blocked, rework, complete, doc-complete, closed).
4. Make routings executable. Convert ERP routing references into station-level steps with checks and required attachments, without silently changing the baseline.
5. Enforce revision effectiveness. The execution layer must present the correct instruction/routing revision for that WO and log what was used.
6. Capture genealogy at source. Record lot/serial relationships during issue, assembly, test—not at closeout.
7. Wire quality into state. Holds and dispositions must immediately change executable state so work cannot “flow around” quality.
8. Close on ship readiness. Require routing completion and document completeness before sending the ERP close/ship-ready signal.

Integration points to implement first (these cover most aerospace pain without boiling the ocean):

• Order release: ERP → execution (WO identity, part, quantity, due date, routing reference).
• Work-in-process status: execution → ERP (milestone state + blocker reason/owner when blocked).
• Material and genealogy anchors: execution → ERP (issues/consumption plus lot/serial identifiers needed for inventory and traceability).
• Quality holds: execution ↔ ERP (hold applied/released so enterprise planning stops assuming flow).
• Completion readiness: execution → ERP (physically complete and documentation complete as separate milestones).

If you implement only identity standardization and milestone events, you will already reduce “different truths” because every system will be talking about the same work order using the same states.

Failure mode vs good practice

Failure mode: Integrations move fields, not meaning. ERP receives many updates, but none reliably indicate blockers, effective revision, or ship-ready evidence. Teams still run the business in meetings and spreadsheets.

Good practice: Integrate state transitions with evidence. “Complete” and “ship-ready” are gated by recorded inspections, dispositions, and required documents tied to the WO’s effective revision context.

Failure mode: Quality is parallel. NCRs exist, but dispatching continues because holds are not execution states.

Good practice: Holds stop the next operation by workflow design, and ERP receives the planning-relevant signal (blocked/unblocked plus reason and owner).

Generalized example and controls that survive margin pressure

Example: one work order from release to closeout

Scenario: WO-104882 builds 6 assemblies (PN-55210). ERP releases the WO with a routing reference and due date. The execution layer expands it into operation IDs, presents the effective instruction revision, and captures confirmations and inspections at the station.

• Material lots are issued and linked to the WO; serials S55210-001 through S55210-006 are created and tied back to those lots.
• An NCR is opened for one serial; the unit is placed on hold, preventing downstream operations until a disposition is approved.
• After rework and re-inspection, the execution layer verifies that routing steps and required documents are complete, then sends ERP two milestones: physically complete and documentation complete.
• ERP closes the WO only when both milestones are true, avoiding the common “built but not shippable” failure mode.

Controls that survive margin pressure

• Scan-based identity capture for WO, operation, lot, and serial to prevent transcription drift.
• Revision gating at the station: the operator can only execute the effective revision, or must log an approved deviation.
• Hold stops flow by workflow, not by memory.
• Ship-ready requirements are structured (machine-checkable), not “attachments someone hopes are there.”
• Exception queues are owned: every missing cert, open hold, or late serial capture has an owner and an escalation path.

Talk to an engineer at Connect981 if you want to map your current integrations to an ISA-95 boundary, define milestone events, and design an evidence pack that eliminates spreadsheet reconciliation at closeout.

Sources

• ISA-95](https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard%22>ISA-95) Standard: Enterprise-Control System Integration (ISA)
• IEC](https://webstore.iec.ch/en/publication/6675%22>IEC) 62264-1:2013 Enterprise-control system integration (IEC Webstore)
• ISA95](https://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa95%22>ISA95) Standards Committee scope (ISA)
• MESA](https://mesa.org/topics-resources/mesa-model/%22>MESA) Model (Manufacturing Enterprise Solutions Association)
• IAQG](https://iaqg.org/standard/9100-qms-requirements-for-aviation-space-and-defense-organizations/%22>IAQG) 9100 standard overview (IAQG)
• AS9100D](https://www.sae.org/standards/as9100d-quality-management-systems-requirements-aviation-space-defense-organizations%22>AS9100D) standard listing (SAE)