MES vs ERP vs Reality: Where Aerospace Execution Actually Lives

In many aerospace factories, people talk about ERP and MES as if they are interchangeable. On whiteboards, the stack looks clean: ERP plans, MES executes, the shop floor produces. But when programs come under pressure, the reality rarely matches the diagram.

Production managers still chase paper travelers. Quality teams rebuild traceability for audits. Engineering changes arrive mid-build and ricochet through email and spreadsheets. The scoreboard metrics—deliveries, backlog, revenue—look like progress, but they hide how fragile execution has become. This is the same visibility gap explored in the hub article The Aerospace Scoreboard Is Lying to You: the space between what systems say should be happening and what is actually happening now.

This article uses the ISA‑95 lens to separate ERP, MES, and a modern execution layer in regulated aerospace environments. The goal is not to declare winners, but to clarify where work really lives—especially the parts that matter most for AS9100, FAA, and EASA oversight.

Why System Boundaries Are Blurry in Aerospace Factories

How legacy deployments shaped current ERP/MES expectations

Most aerospace organizations did not design their digital architecture from scratch. They accumulated it. ERP arrived to unify finance, contracts, and basic production planning. Years later, MES or homegrown shop-floor systems were layered in to address specific pain—often in final assembly, special processes, or test.

Those early MES deployments were usually scoped narrowly: capture some production data, dispatch operations to machines, produce basic OEE. Over time, additional requirements piled on: electronic work instructions, shop floor non-conformances, basic genealogy, sometimes electronic signoffs. Each plant, and sometimes each program, evolved its own flavor of “MES.” The result is a patchwork where the same acronym describes very different realities.

Different interpretations of MES across plants and suppliers

Ask five aerospace suppliers to define MES and you will hear five different answers:

• A scheduling and dispatching tool for CNC machines
• A traveler and electronic work instruction system
• A data historian and OEE dashboard
• An electronic quality record and non-conformance log
• A catch-all layer between ERP and the line

All of these are partially true. None of them describe the full execution reality. For a complex assembly like an aircraft structure or propulsion system, critical information often lives outside MES entirely: email approvals, spreadsheet-based configuration matrices, PDF drawings in shared drives, supplier certifications in separate portals.

When MES is defined locally by what one site needed at the moment of purchase, it becomes difficult to reason about its role in the broader ISA‑95 architecture.

The impact of customizations on architectural clarity

To close gaps, aerospace organizations frequently customize MES and ERP. Over time, these customizations blur originally clear boundaries:

• ERP instances that hold detailed operation-level routing logic and shop-floor rules
• MES instances that reach up into demand management, scheduling, and even basic contract attributes
• Custom middleware or scripts that move partial data in ways nobody fully documents

Short term, these decisions feel pragmatic: meet a program milestone, satisfy a particular customer requirement, pass an audit. Long term, they erode architectural clarity. When no one can say with confidence which system is the “source of truth” for a given decision—configuration, revision, process spec, inspection requirement—execution relies on tribal knowledge.

That lack of clarity is precisely what ISA‑95 was meant to prevent. In aerospace, we need to revisit those boundaries with the realities of regulated, high-mix, manual-heavy production in mind.

ERP’s Role Through the Lens of ISA‑95

Level 4: planning, scheduling, and financial alignment

In ISA‑95 terms, ERP operates primarily at Level 4: business planning and logistics. In aerospace, this translates to:

• Long-horizon production planning for programs and platforms
• Master scheduling across lines, cells, and suppliers
• Material requirements planning (MRP) and procurement
• Costing, revenue recognition, and financial reporting
• Contract-level delivery dates and penalties

ERP is the system that holds the official promise to the market: how many units will be delivered, when, under which contract, and at what cost structure. It must integrate deeply with finance, contracts, and supply chain.

Master data, contracts, and high-level orders

ERP also carries critical master data:

• Part and assembly identifiers
• Customer contracts and line items
• Approved suppliers and lead times
• High-level routings and work centers

In aerospace, these data objects are tightly coupled to regulatory and customer requirements. For example, an ERP work order for a flight-critical assembly implicitly encodes configuration baselines, contractual acceptance criteria, and delivery milestones.

However, ERP only represents intended work. It does not know the exact sequence of actions technicians will perform, the specific tools and gauges they will use, or the real-time status of each operation on the floor.

Why ERP is not designed for second-by-second execution detail

ERP systems were never meant to operate at the granularity of real-time execution. They are optimized for transactional consistency and financial control, not for sub-minute event streams, sensor data, or technician interactions.

Trying to force ERP into a second-by-second execution role usually creates friction:

• Slow user interfaces and complex screens on the shop floor
• Limited support for offline or constrained environments
• Difficulty handling rapid configuration changes at the operation level
• Performance challenges with high-frequency data like test results or IIoT events

For regulated aerospace programs, the risk is more than inconvenience. If ERP becomes the de facto execution system, teams start to work around it with shadow spreadsheets and parallel workflows. That shadow layer is where traceability and configuration control begin to fracture.

What MES Traditionally Covers—and What It Doesn’t

Typical MES functions: dispatching, data collection, OEE

Traditional MES tools sit at ISA‑95 Levels 3 and 2, close to the line. In aerospace factories, common MES capabilities include:

• Dispatching work orders and operations to workstations or machines
• Tracking basic production status (started, in progress, completed)
• Collecting production counters, cycle times, and machine states for OEE
• Capturing operator logins and simple electronic signoffs
• Integrating with equipment for automatic data capture in highly automated cells

These functions are important, but they reflect a manufacturing world where operations are relatively repeatable, tact times are stable, and automation dominates. Many aerospace environments look very different.

Support for automated versus manual operations

In aerospace, a significant share of value-added work is manual or semi-manual:

• Complex composite layups
• Detail assembly and sub-assembly integration
• Wiring harness installation
• Structural drilling, fastening, and sealing
• Functional testing and troubleshooting

Traditional MES excels when there is a tight coupling to equipment states and well-defined cycles. It struggles when a single operation can take hours or days, with dozens of micro-decisions, engineering clarifications, and quality checks along the way.

As a result, many aerospace sites keep MES usage shallow for manual work: start/stop timestamps, a few data fields, and a signoff. The real context—engineering dispositions, process deviations, temporary repairs, test adjustments—lives elsewhere.

Gaps in supplier collaboration and end-to-end traceability

Another structural gap is that MES is often plant-centric. It tracks what happens inside a site boundary, not across the aerospace supply chain. Yet end-to-end traceability is precisely what auditors and regulators expect:

• Material and process genealogy from raw stock to final assembly
• Supplier certifications and special process qualifications
• Change histories across design, planning, and execution
• Linkage between non-conformances, corrective actions, and delivered units

MES rarely owns the full picture. Supplier data arrives through portals, emails, and PDFs. Engineering changes come from PLM or configuration management tools. Quality events may live in separate QMS platforms. Without an explicit execution layer designed to stitch these flows together, aerospace manufacturers rely on people to create the digital thread manually.

Reality Checks from Aerospace Programs

Where paper travelers still dominate critical processes

Despite significant investments in ERP and MES, paper travelers remain common in aerospace environments, including on critical assemblies. Reasons include:

• Legacy processes never fully migrated into digital systems
• Complex rework flows that are easier to annotate by hand
• Supplier work packages that arrive in paper or PDF-only formats
• Lack of confidence that the digital system reflects the latest engineering intent

Every time a process drops to paper, live traceability becomes reconstruction. After-the-fact data entry is error-prone and rarely captures the full context of what occurred at the point of work.

Workarounds for handling engineering changes on the line

Engineering changes are a normal part of aerospace programs, especially early in the lifecycle. The problem is how they are handled operationally. Common patterns include:

• Emailing revised drawings or work instructions to supervisors
• Printing temporary instructions and stapling them to travelers
• Maintaining local spreadsheets that map part numbers to special instructions
• Relying on toolbox talks and shift meetings to communicate changes

Rarely is there a single system that understands: this tail number, at this station, is being built under this exact configuration and deviation set. ERP knows the contract. MES knows the base routing. PLM knows the design change. The line knows the workaround. Nobody has the integrated view.

How quality and non-conformance workflows often sit outside MES

In many aerospace organizations, quality systems evolved independently from MES:

• Non-conformance and MRB processes run in a QMS or separate tool
• Inspection results are recorded in standalone databases or forms
• Corrective actions and audits are tracked in yet another system

When an NC is raised on the floor, the technician may log it in a QMS, then manually backfill MES status, then notify planning by email. Each handoff dilutes the connection between the physical part, the work performed, the digital record, and the final configuration delivered to the customer.

Under normal conditions, these gaps are survivable. Under stress—rate increases, design changes, regulatory scrutiny—they become the difference between stable throughput and systemic gridlock.

Defining a Modern Aerospace Execution Layer

Bridging ERP plans and MES/plant-floor signals

A modern aerospace execution layer is not a rebranded MES or ERP module. It is a dedicated layer that:

• Consumes plans and constraints from ERP (orders, routings, dates, capacity assumptions)
• Connects to MES, IIoT, test systems, and manual reporting channels for real-time status
• Maintains a high-fidelity view of work-in-progress (WIP) by unit, assembly, and configuration
• Surfaces deviations, delays, and risk in time for action, not post-mortem reporting

In the language of the hub narrative, it is the layer that makes the aerospace “scoreboard” honest. Instead of relying solely on deliveries and backlog, it exposes execution capability and constraint.

Embedding configuration control and digital thread awareness

For aerospace, configuration control is non-negotiable. An execution layer must treat configuration as a first-class concept, not metadata:

• Binding specific engineering baselines, deviations, and waivers to each unit
• Ensuring work instructions reflect the correct configuration at the moment of execution
• Recording which configuration was actually used when work occurred
• Maintaining a navigable digital thread from requirement to delivered hardware

This is more than attaching a drawing revision to a work order. It requires contextual awareness. When a technician opens a task, the system must understand which configuration applies, what changes are in effect, and which quality controls are mandatory for that specific unit and operation.

Experience design for technicians, engineers, and quality teams

A practical execution layer also pays attention to experience:

• Technicians need clear, current, and unambiguous instructions with minimal navigation overhead
• Engineers need to introduce changes in a controlled way, with visibility into who is affected and when
• Quality teams need to see context-rich data around each defect: configuration, process state, environmental factors, and upstream/downstream dependencies

When these needs are served in a single operational environment, adoption follows. People stop relying on parallel spreadsheets because the system of record is finally aligned with how work actually happens.

Data Flows Across ERP, MES, and Execution Platforms

Order, operation, and routing synchronization

The most fundamental data flow is between ERP and the execution layer:

• ERP sends order headers, line items, and planned routings
• The execution layer refines those into executable tasks, sequences, and work packages
• Changes in planning (reschedules, splits, cancellations) are propagated without losing traceability

MES may still perform detailed dispatching, especially for automated cells. The key is that the execution layer remains the reference for what work exists, how it is structured, and how it maps back to contracts, configurations, and units.

Event streams from IIoT, test stands, and inspections

Aerospace factories generate diverse data streams:

• Sensor data from environmental controls and curing processes
• Test stand results and functional verification logs
• Dimensions and measurements from inspections and metrology
• Manual confirmations from technicians and inspectors

Traditional MES may capture some of this, but often in siloed ways. An execution layer should focus on contextualizing events rather than simply storing them. Every data point should be tied to a specific unit, configuration, operation, and point in the process.

Feeding back status, non-conformance, and genealogy to upstream systems

Finally, the execution layer becomes the source for downstream and upstream visibility:

• ERP receives summarized status and milestone completions to keep plans realistic
• QMS receives structured, context-rich non-conformance and inspection data
• PLM and configuration management systems receive feedback on how designs behave in production
• Program teams gain access to unit-level genealogy and build history without interrogating multiple platforms

The objective is not to replace existing systems of record, but to coordinate them so that the picture of reality is coherent and timely.

Architecting for Regulated Supply Chains

Supporting AS9100, FAA, and EASA evidence requirements

Regulators and customers increasingly expect that aerospace organizations can produce evidence, not narratives. That evidence spans:

• Who performed each operation, under which qualification
• Which tools, materials, and processes were used
• How deviations and waivers were controlled
• How corrective actions were implemented and verified

An execution layer simplifies this by making compliance a natural byproduct of doing the work, not a separate documentation exercise. When data capture is embedded in execution, audit readiness becomes continuous rather than episodic.

Supplier visibility and collaboration across system boundaries

Aerospace supply chains are multi-tier and global. No single organization controls every system edge. To achieve real execution visibility across that network, the architecture must:

• Respect that each supplier will keep its own ERP, MES, and QMS stack
• Provide a common way to exchange execution-relevant data: status, certifications, genealogy
• Support secure, selective sharing of data to maintain confidentiality while enabling oversight

This is where a connectivity-focused execution platform becomes critical. It acts as a collaboration surface across organizations without demanding that everyone adopt the same monolithic system.

Why platforms like Connect 981 emphasize connectivity over monoliths

A monolithic approach—trying to force ERP to be MES, or MES to be the only execution layer—breaks down in complex aerospace ecosystems. The reality is heterogeneous: different plants, different suppliers, different legacy systems.

Platforms in the Connect 981 category emphasize connection and orchestration over replacement. They sit between planning and the shop floor, integrate with existing tools, and provide a coherent operational picture across programs and partners. They are less about owning every transaction and more about ensuring that, when the industry looks beyond the scoreboard, it can finally see how execution is truly performing.

For aerospace organizations facing rising expectations, tighter regulatory scrutiny, and more complex supply chains, the question is no longer “ERP or MES?” It is whether there is a deliberate execution layer that turns fragmented systems into a controllable, auditable whole.