How should aerospace organizations decide what data lives in ERP versus an execution system?

For aerospace operations, the ERP and execution layer (MES, digital travelers, NCR/FAI tools, shopfloor data collection) should be separated by purpose, not just by where data happens to originate. In practice, you decide placement based on who uses the data, how fast it changes, and what level of detail the system can reliably manage over long lifecycles.

Core principle: ERP is the system of record for commercial flow; execution is the system of record for physical flow

A useful rule is:

• ERP: System of record for the commercial and planning view of work (orders, commitments, value, inventory balances).
• Execution system (MES and related tools): System of record for the physical and compliance view of work (how the part was built, tested, reworked, and released).

Both need overlapping identifiers and summary data, but only one system should be the primary authority for any given data element to avoid reconciliation churn and audit gaps.

What typically belongs in ERP

In most aerospace environments, ERP should own:

• Commercial and planning data
  • Customer contracts, sales orders, and delivery schedules.
  • Purchase orders, supplier contracts, and receipts.
  • Demand, MRP runs, planned orders, and capacity planning summaries.
• Item master and high-level BOM
  • Item numbers, basic descriptions, costing categories, revision markers (sourced from PLM, but mirrored in ERP).
  • Manufacturing BOMs at a planning level, often a simplified version of the engineering BOM.
• Work order headers and status
  • Work order numbers, quantities, due dates, and high-level status (released, in process, complete, closed).
  • Routing headers or “operations” at a coarse level (e.g., mill, treat, assemble, test), enough for planning and costing.
• Inventory and financials
  • Inventory balances by location and valuation.
  • Labor and overhead costing, standard cost/actual cost calculations.
  • Accounting, invoicing, and financial reporting.
• Compliance-related summaries, not details
  • Key traceability identifiers (batch/lot/serial numbers) needed to tie back to the execution system.
  • Links or references to as-built records, certificates, and quality records, not the raw evidence itself.

ERP can store more operational detail, but beyond a certain point this creates performance, usability, and change control issues, especially for high-mix, long-lifecycle aerospace programs.

What typically belongs in an execution system

The execution layer (MES, digital travelers, point solutions for FAI, calibration, NCR, etc.) should own:

• Detailed routing and work instructions
  • Operation-level steps, sign-offs, tools, and parameters.
  • Dynamic routings, alternates, rework flows, and conditional paths.
  • Digital travelers with exact step-by-step execution logic and embedded work instructions.
• As-built, as-tested, and genealogy detail
  • Serial, lot, and batch genealogy: which components went into which assemblies, when, and by whom.
  • Process parameters, machine states, torque values, test results, and measurement data.
  • Tooling usage records, calibration references, and fixturing lineage when required.
• Quality and nonconformance execution data
  • In-process inspections, checklists, and sampling results.
  • Nonconformance records, MRB decisions, concessions/deviations, and rework instructions.
  • AS9102 FAI data capture, ballooned characteristics, and measurement evidence (even if summary status is reported elsewhere).
• Execution events and operator context
  • Who did what, when, and under which revision of the plan or instruction.
  • Machine utilization, downtime reasons, changeover times, and shift-related execution data.
  • Operator qualifications at the time of execution, where tracked for compliance.
• Real-time and near-real-time controls
  • Hold / release states, in-station checks, interlock logic, and in-process routing decisions.
  • Short-interval control and performance monitoring (NPT, scrap, rework).

This is the data that typically changes rapidly, is used locally on the shopfloor, and often needs detailed audit trails and evidence for AS9100, AS9102, and customer requirements.

Data that must exist in both, but with a clear source of truth

Some data must be visible in both ERP and execution for the systems to cooperate. The decision is which system is authoritative and which is a consumer:

• Part numbers and revisions
  • Source of truth: Usually PLM for engineering data, with ERP holding the commercial item master and the execution system holding the operationalized build definition.
  • Execution systems often need more granular, versioned build logic than either PLM or ERP natively support.
• Work orders / jobs
  • Source of truth: Typically ERP for the existence and quantity of the order.
  • Execution system is authoritative for detailed progress, operation-level statuses, and as-built records.
• Inventory and WIP
  • Source of truth: ERP for on-hand balances and valuation.
  • Execution system for physical location and status at a finer resolution (e.g., exactly which workstation, which pallet, which state in a routing).
• Quality status
  • Execution system owns detailed defect data, inspection measurements, NCR workflow, and MRB decisions.
  • ERP may hold summarized quality status at the lot/serial/WO level (e.g., blocked, released, under review) and references back to detailed evidence.

Trying to make both systems authoritative for the same data element usually results in manual reconciliations, custom scripts, and risk during audits when the two systems disagree.

Criteria to decide data placement

Beyond generic patterns, you should evaluate data element by data element using criteria like:

• Primary consumer
  • If finance, contracts, or supply chain are the main users, ERP is usually the right home.
  • If operators, quality, engineering, or industrialization are the main users, the execution layer is usually more appropriate.
• Update frequency and latency requirements
  • High-frequency or sub-shift data (machine events, step-level signoffs, in-station checks) generally should not live in ERP.
  • ERP can consume rolled-up or summarized versions on an hourly/daily cadence if needed.
• Level of detail
  • High-volume, high-detail evidence (test traces, dimensional data, torque events) belongs in an execution system or specialized repository.
  • ERP should retain links and summary results, not full measurement sets, to avoid bloating and performance impacts.
• Retention horizon
  • If data must be kept for decades with proof of integrity (aircraft life plus several years), consider whether ERP is the right place for high-detail records.
  • Execution or archival systems can handle long-term storage and retrieval of detailed evidence, provided integrity and traceability are validated.
• Change control and governance
  • If the data is tightly tied to engineering change, configuration management, or regulated process changes, PLM plus execution is usually where detailed logic lives.
  • ERP should reference the correct revision and configuration, not duplicate the full logic when that would create multiple change control points.
• Integration cost and risk
  • Placing complex, highly volatile data in ERP can increase the cost of every integration and upgrade, especially in validated or tightly controlled environments.
  • Sometimes it is safer to keep complexity in execution systems and expose just what ERP needs for planning, cost, and commitments.

Brownfield reality: coexisting with legacy ERP, MES, and point solutions

Most aerospace plants already have:

• A mature ERP that finance and supply chain rely on, often with limited flexibility to change data models.
• Multiple partial execution systems: legacy MES, homegrown traveler tools, spreadsheets, and point solutions for FAI, NCR, and calibration.
• Long-qualified processes where any system change triggers revalidation and customer notifications.

In this context, full “rip-and-replace” strategies for ERP or execution are rarely feasible without unacceptable downtime, validation effort, and integration risk. Data placement decisions should prioritize:

• Stability of ERP data structures: Avoid designs that require frequent ERP schema changes or custom objects to carry detailed execution data.
• Incremental integration: Start by integrating identifiers (part, lot, serial, WO), then add limited status and summary data before attempting deep bidirectional syncs.
• Traceability linkage: Ensure there is a consistent way to navigate from a part or work order in ERP to the detailed execution and quality evidence, even if it resides in a different system.
• Validation strategy: Treat interfaces and data transformations as configuration that may need qualification and change control, not just IT plumbing.

Common failure modes in data allocation

Typical problems arise when the boundary between ERP and execution is not intentional:

• Overstuffed ERP
  • Trying to store every inspection reading, work instruction, and routing variant directly in ERP leads to performance issues, user frustration, and difficult upgrades.
  • Quality and engineering teams bypass ERP anyway, creating shadow systems and spreadsheets.
• Execution siloed from planning and finance
  • MES and shopfloor tools have rich data, but ERP remains blind to true status, causing launch, delivery, and cost surprises.
  • Manual rekeying between systems creates transcription errors and weakens audit trails.
• Dual system-of-record situations
  • Both ERP and execution claim to be the source of truth for routing, WIP status, or quality dispositions.
  • During audits or investigations, data conflicts cannot be reconciled quickly, damaging credibility.
• Underestimating configuration and validation burden
  • Moving high-change, detailed logic (e.g., routing variants, inspection plans) into ERP can slow improvements because every change now touches a validated, widely used system.
  • This often results in frozen designs that do not match actual practice, undermining both compliance and performance improvement.

Practical approach to designing the split

A pragmatic way to decide what lives where is to run a small but rigorous data-mapping exercise:

1. Identify critical end-to-end scenarios
   • Examples: New program launch, AS9102 FAI, AOG response, major configuration change, field-return investigation.
   • Map which roles and systems need to see which data, at what latency, and at what level of detail.
2. List key data objects and attributes
   • Items, routings, work orders, serial numbers, inspection plans, NCRs, concessions, test records, certificates, etc.
   • For each, decide: source of truth, consumers, and retention needs.
3. Define integration contracts
   • Specify what ERP publishes (e.g., work order headers) and what execution publishes back (e.g., operation completion, scrap quantities, hold status).
   • Align message frequency and content with system capabilities and validation requirements.
4. Pilot on a limited scope
   • Implement the chosen split for a single cell, program, or plant before scaling.
   • Review audit trails, reconciliation workloads, and user behavior to validate whether the split works in practice.
5. Codify rules and governance
   • Document which system is authoritative for each data category and how changes are managed.
   • Ensure IT, quality, engineering, and operations sign off, given their shared responsibility in regulated environments.

The exact ERP vs execution data split will vary by organization, vendor stack, and program requirements, but using these principles and criteria reduces the risk of duplicative records, audit issues, and unmaintainable integrations over the long life of aerospace programs.