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.

For teams putting this topic into daily operation, execution systems for aerospace manufacturing, shop floor execution control, ERP, MES, and PLM integration paths help connect the concept to traceability, work-order reality, and audit-ready evidence.

The same operating model also depends on a connected execution platform, Connect 981’s aerospace execution solutions, real aerospace execution examples, Connect 981’s aerospace operations guidance, especially when decisions have to move across quality, production, suppliers, and program leadership without losing context.

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.

Implementing ISO 22400: Practical Steps to Standardize Manufacturing KPIs

ISO 22400 gives aerospace and defense manufacturers a common language for manufacturing KPIs, but the standard does not tell you how to roll it out across MES, ERP, historians, and supplier portals. Turning its concepts into repeatable practice requires a structured implementation approach that respects existing systems, AS9100 processes, and the realities of multi-site aerospace production. This guide focuses on practical, non-vendor-specific steps to adopt the ISO 22400 manufacturing KPI framework inside a regulated aerospace manufacturing environment.

The goal is not formal certification. Instead, the emphasis is on making KPI definitions consistent across plants, programs, and partners so that “availability,” “utilization,” and order-related indicators mean the same thing in every system and report. Done correctly, ISO 22400 becomes part of your digital thread, not a competing structure.

For teams putting this topic into daily operation, industrial security evidence, security and compliance requirements, a connected execution platform help connect the concept to traceability, work-order reality, and audit-ready evidence.

The same operating model also depends on Connect 981’s aerospace execution solutions, real aerospace execution examples, Connect 981’s aerospace operations guidance, practical aerospace operations FAQs, especially when decisions have to move across quality, production, suppliers, and program leadership without losing context.

Assessing Your Current KPI Landscape

Inventorying existing KPIs and definitions

The starting point for ISO 22400 implementation is a realistic picture of the KPIs you already use. In a typical aerospace or space hardware program, KPIs are scattered across:

• MES dashboards monitoring work centers, takt performance, and rework rates
• ERP and MRP reports on schedule adherence, order lead time, and WIP age
• QMS and nonconformance systems tracking defect rates, escapes, and MRB cycle times
• Maintenance systems tracking equipment downtime and mean time between failures
• Excel-based “shadow systems” created by program teams and industrial engineers

Create a structured KPI inventory that captures at least:

• KPI name as used today (for example, “machine uptime,” “line utilization,” “on-time to promise”)
• Formal or informal definition, including what is in or out of scope
• Calculation description or formula (even if only documented in a spreadsheet)
• Data sources and systems (MES, historian, ERP, QMS, manual entry)
• Organizational owner (operations, quality, program office, finance)
• Where it is visible (reports, dashboards, SLAs, customer scorecards)

For aerospace organizations running multiple sites or supporting multiple OEM programs, capture which sites or programs use each KPI. Many inconsistencies only appear when comparing KPI catalogs across factories or business units.

Identifying inconsistent terms across plants and systems

With the inventory assembled, the next step is to surface inconsistent terminology. In aerospace production, this often appears in three patterns:

• Same name, different meaning – for example, one plant labels a KPI “availability” but includes scheduled maintenance in the denominator, while another excludes it.
• Different name, same meaning – for example, “uptime” in one system and “run time” in another both correspond to the same operating state.
• Different aggregation logic – for example, OEE calculated at the equipment level in one plant and at the line level in another, but reported as a single corporate metric.

Document these conflicts explicitly. ISO 22400 implementation is largely the process of resolving them and aligning to the standard’s definitions for time categories, states, and indicator semantics. Pay particular attention to KPIs that appear in:

• Customer-facing reports or contract deliverables
• Regulatory or airworthiness-related metrics (for example, defect escape rates)
• Executive dashboards and board-level reporting

These are the KPIs where ambiguity is most costly and where alignment with ISO 22400 will have the greatest impact on clarity and comparability.

Mapping Existing KPIs to ISO 22400 Concepts

Renaming vs. re-defining KPIs

Once you understand your current KPI landscape, the next step is to map those KPIs onto ISO 22400 concepts. The standard provides structured definitions for performance indicators and KPIs based on equipment states, time categories, and quantity-based measures. For each existing KPI, ask:

• Does ISO 22400 define a directly comparable KPI (for example, an availability or utilization concept)?
• If so, is our current definition materially aligned, or are there meaningful differences in scope or time basis?
• If not, is our KPI a useful extension (for example, a specific aerospace traceability or certification metric)?

In practice, you will end up with three categories of KPIs:

1. Aligned KPIs – Current definition closely matches an ISO 22400 KPI. Here, you can retain the definition and, if needed, adopt ISO 22400’s naming and attribute conventions.
2. Adjustable KPIs – KPIs that can be brought into alignment with limited changes, such as slightly adjusting time categorizations or clarifying which equipment states are included.
3. Non-standard KPIs – Aerospace- or program-specific KPIs that serve important purposes but are outside ISO 22400’s scope (for example, certification batch release lead time, or first article inspection queue time).

For the first two categories, decide whether you will:

• Rename the KPI to match ISO 22400 terminology while keeping the underlying logic essentially the same, or
• Re-define the KPI to fully conform with the ISO 22400 concept, updating the calculation logic and documentation.

Renaming is less disruptive but can leave subtle inconsistencies if the underlying logic still diverges from the standard. Re-defining offers better interoperability but requires more careful change management and stakeholder communication.

Dealing with near-duplicates (availability vs. uptime)

Near-duplicate KPIs are common in aerospace factories that have grown through acquisitions or that support different OEM programs with separate reporting expectations. A classic example is “availability” versus “uptime,” both attempting to describe how much of the planned time equipment spends in productive states.

ISO 22400 helps by providing precise definitions for equipment states (e.g., RUN, STOP, IDLE, SLOW) and the time categories derived from them. To reconcile near-duplicates:

1. Express each existing KPI in terms of ISO 22400 states and times (for example, “uptime” = RUN time only; “availability” = RUN + IDLE over planned time).
2. Identify which KPI best aligns with the ISO 22400 availability or utilization concept.
3. Standardize on that definition and make the alternative an alias or a retired KPI.

In aerospace, be especially rigorous with KPIs used in customer contracts or offset agreements. If an OEM contract references “equipment availability” for a nacelle line or composite layup cell, you should ensure the governing definition is explicitly mapped to the ISO 22400 concept and unambiguous across all reporting tools.

Adapting Data Models and Interfaces

Aligning equipment states and time categories

Conceptual alignment is only effective if your data models support it. ISO 22400 relies heavily on equipment states and their associated times. In practice, this means standardizing how signals from machines, test stands, and assembly cells are translated into high-level states across all plants.

For an aerospace environment with diverse equipment (CNC machining centers, autoclaves, bonding ovens, engine test cells, structural assembly lines), the implementation steps typically include:

• Defining a canonical set of equipment states aligned with ISO 22400 (for example, RUN, STOP-planned, STOP-unplanned, IDLE, SETUP, SLOW).
• Mapping PLC or control system signals into those states in a consistent way, even if different OEMs use different tags.
• Ensuring that historians and MES capture time in each state at an appropriate granularity.
• Deriving standardized time categories (planned time, busy time, operating time, downtime) from those states.

Because aerospace production frequently includes long-cycle, high-mix operations, state definitions must also consider:

• Setup and changeover for configuration changes and engineering effectivity
• Waiting states due to missing certifications, FAI completion, or quality hold
• Planned pauses due to coordination with external test facilities or customer inspections

Your implementation should make these distinctions explicit so that KPIs derived from state times remain interpretable by both operations and compliance teams.

Updating MES, ERP, and historian data schemas

After aligning states, you need to ensure that the underlying data models can express ISO 22400 KPIs cleanly. This does not require replacing existing systems, but it does typically involve schema extensions and interface adjustments. Common changes include:

• Adding standardized KPI identifiers and attributes to MES and reporting databases.
• Introducing explicit fields for ISO 22400 time categories instead of inferring them in every report.
• Tagging KPIs as ISO 22400-aligned versus organization-specific extensions.
• Harmonizing units of measure and timestamp conventions across systems (especially important in multi-site, multi-time-zone aerospace networks).

For ERP systems that manage orders and work breakdown structures, you may need to:

• Align production order and operation identifiers with the objects of measurement defined in ISO 22400.
• Ensure that order-level and equipment-level KPIs can be linked, enabling analysis of how equipment performance affects program schedule adherence.

A digital manufacturing platform such as Connect 981 can sit above existing MES, QMS, and ERP systems, mapping their native data structures into an ISO 22400-aligned KPI model. This approach allows you to standardize KPI semantics without forcing a single vendor stack across the entire enterprise or supply chain.

Governance: Owning and Maintaining KPI Definitions

Creating a KPI data dictionary and ownership model

ISO 22400 implementation fails quickly if KPI definitions drift over time. To prevent this, establish a formal KPI data dictionary and governance model that treat KPI definitions as controlled data assets, similar to engineering configurations or process specs.

Your KPI data dictionary should include, at minimum:

• The KPI name and unique identifier
• A clear, ISO 22400-based conceptual definition
• Mathematical expression or calculation logic
• Object of measurement (equipment, line, work center, area, site, order)
• Applicable time behavior, units of measure, and expected range
• Data sources and system-of-record
• Primary user groups (operators, manufacturing engineering, program management, executives)

Treat the dictionary as a controlled document or database under configuration control. Assign explicit ownership, typically through a cross-functional KPI governance board that includes operations, quality, IT/OT, and program representation. In AS9100 environments, the KPI dictionary often integrates with existing document control and change management processes.

Change management for KPI definitions and dashboards

Because KPIs influence decisions, incentives, and sometimes customer penalties, changing a KPI definition is a significant event. Your governance model should define:

• How KPI changes are proposed, reviewed, and approved
• How version history is maintained, including effective dates for each definition
• How changes propagate into reports, dashboards, and interfaces
• How historical data is handled (recalculated, re-labeled, or left unchanged with clear cutover markers)

In practice, this often means adopting a release cadence for KPI changes (for example, quarterly) and treating KPI updates like software or process changes. For aerospace programs with strict contractual reporting, align KPI definition changes with contract cycles or explicit customer agreement to avoid disputes over performance metrics mid-program.

Training Stakeholders on ISO 22400 Concepts

Educating operators, engineers, and managers

Standardized KPIs only deliver value if stakeholders understand what they mean and trust them. ISO 22400 concepts must therefore be embedded into everyday language on the shop floor and in program reviews.

Training should be tailored by role:

• Operators and cell leads need to understand equipment states, why accurate state entry matters, and how their actions affect KPIs such as availability and utilization.
• Manufacturing and industrial engineers need deeper knowledge of time categories, data models, and how their process changes might impact KPI definitions.
• Program managers and executives need clarity on how site-level and equipment-level ISO 22400 KPIs roll up to program performance views and what is and is not comparable across plants.

Use real examples from your own aerospace lines—such as a composite layup cell, an engine test bay, or a structures assembly station—to illustrate how states, times, and KPIs interact. This grounding avoids the perception that ISO 22400 is an academic overlay disconnected from day-to-day operations.

Communicating changes to suppliers and customers

Aerospace and defense production depends on a complex, regulated supply chain. When you change KPI definitions, your suppliers and customers can be affected, especially if KPIs appear in contracts, supplier scorecards, or performance-based logistics agreements.

For key partners, consider providing:

• A summarized ISO 22400-aligned KPI catalog you intend to use
• Clear mapping from any previously used KPIs to the new definitions
• Transition timelines and how historical performance will be treated

Some organizations use a digital manufacturing platform as a shared lens where both internal teams and suppliers can see KPI definitions and values aligned to the same ISO 22400 semantics. This approach minimizes misunderstandings when comparing performance across different factories or supplier tiers.

Example Implementation Timeline and Pitfalls to Avoid

Phased rollout across sites and systems

ISO 22400 implementation is best approached as a phased program rather than a single “big bang,” especially in multi-site aerospace networks with legacy systems. A typical pattern might look like:

1. Pilot scope definition – Select one value stream or product family (for example, a specific engine model, satellite program, or structural assembly line) and a constrained set of KPIs (for example, availability, utilization, order execution reliability).
2. Discovery and mapping – Complete the KPI inventory, mapping, and data model alignment for the pilot scope, including necessary MES/historian tweaks.
3. Governance and training – Stand up the KPI data dictionary, governance structure, and targeted training for the pilot stakeholders.
4. Pilot operation – Run with ISO 22400-aligned KPIs in parallel with existing reporting for a defined period to build trust and validate behavior.
5. Scale-out – Extend to additional lines, plants, or supplier tiers, reusing the data models and governance patterns built in the pilot.

Timelines will vary by organization size, system complexity, and regulatory constraints. The key is to preserve consistency of definitions while allowing local implementations to adapt to specific equipment, processes, and certification requirements.

Common mistakes in ISO 22400 adoption

Several common pitfalls tend to derail ISO 22400 initiatives in aerospace and defense manufacturing:

• Treating ISO 22400 as a reporting project only – Focusing solely on dashboards and ignoring the underlying state models and data quality leads to attractive visuals with inconsistent semantics.
• Over-customizing the standard – Adding many local variants of KPIs with subtle definition differences defeats the purpose of standardization and complicates multi-site comparisons.
• Underestimating change impact – Changing KPI definitions without careful communication can undermine trust from program teams and external partners who rely on year-over-year comparability.
• Ignoring non-standard but critical KPIs – For aerospace-specific indicators (for example, part genealogy completeness metrics or airworthiness sign-off cycle time), the goal is coexistence with ISO 22400, not forced alignment where it does not fit.

A disciplined approach that distinguishes between ISO 22400-aligned KPIs and intentional, well-documented extensions gives you the benefits of standardization without constraining necessary aerospace-specific measures.

Bringing ISO 22400 into the Aerospace Digital Thread

ISO 22400 does not replace your AS9100 processes, digital thread initiatives, or engineering change control. Instead, it supplies a shared vocabulary for performance measurement that can be woven through existing systems and workflows. When equipment states, time categories, and KPI definitions are standardized, it becomes easier to connect events in design, planning, execution, and quality into a coherent performance narrative.

Platforms like Connect 981 can implement ISO 22400-aligned KPI structures as part of a broader aerospace digital operations layer, tying together MES, ERP, QMS, and supplier data without forcing a single monolithic solution. The standard defines what KPIs mean; your organization decides which ones matter, how aggressively to target them, and how they support safe, compliant, and efficient aerospace production.

Most FAI debates do not start with bad intent. They start with a drawing revision, a supplier move, a long production gap, or a customer note buried in a purchase order. This guide answers when is full fai required, when a partial fai is enough, and how aerospace teams can make that decision without turning every change into a program delay.

Fast Answer: When Is a Full First Article Inspection Mandatory?

A full first article inspection is required when the prior baseline no longer proves that the article meets all engineering, manufacturing, and customer requirements. AS9102C, released on 2023-06-28, is the current aerospace reference, and customer flowdowns can be stricter than the standard.

A full FAI is required during new product introduction, production gaps, significant changes, major process overhauls, or customer demand for a re-baseline of quality data. If minor modifications are made, a partial or Delta FAI, focusing only on affected characteristics, is used instead of repeating the full FAI process.

Core triggers include:

• New part number, new first article, or first build to a customer design.
• Design change affecting fit, form, function, safety, or performance.
• Production lapse of 24 months or more, unless customer requirements define another interval.
• New site, new primary equipment, or new production process route.
• Change of material, source, or key special process, such as heat treat, plating, bonding, or welding.
• Customer-directed full FAI on the contract, purchase order, corrective actions plan, or approval process.

A full FAI covers the entire drawing and full characteristic accountability. A partial FAI covers only affected characteristics and links back to the baseline first article inspection report.

Full vs Partial FAI: Clear Definitions and Boundaries

A First Article Inspection (FAI) is a comprehensive review of the engineering documentation and the manufacturing process from raw materials through conversion and functional testing for one part. The AS9102 standard, developed by the International Aerospace Quality Group (IAQG), outlines the requirements for First Article Inspection in the aerospace industry, ensuring that all aspects of design, manufacturing, and inspection are verified and documented.

A complete fai includes:

• Ballooned engineering drawings or 3D models with every design characteristic, material note, surface finish, and specification requirement identified.
• A complete article inspection report FAIR using the three forms: Form 1, part number accountability form; Form 2, product accountability; Form 3, characteristic accountability with measured values.
• Compatibility evaluation against the latest design records, specification requirements, documentation requirements, and purchase order.

A partial FAI includes:

• Only new or revised dimensions, notes, materials, inspection methods, or production process changes.
• A FAIR that references the original baseline article inspection report by number and date.
• Evidence that unchanged tooling, calibrated tools, coordinate measuring machines, and inspection plan remain controlled.

Boundary example: a design note clarification with no functional effect usually supports partial FAI. A new machining center and fixture for the same part may require full FAI because the manufacturing environment changed.

Trigger Matrix: When a Full FAI Is Required vs When Partial Is Enough

Use a trigger matrix during supplier review, quality control, and formal approval. It gives responsible parties a consistent way to decide the required article inspection level.

Event

Impact

Typical decision

Notes

New Airbus A320neo bracket

No baseline

Full FAI

New first article inspection requirement

Hole location or tolerance change

Fit or function

Full FAI

Assembly risk

Drawing typo correction

Documentation only

Partial FAI

No change to specified requirements

New forging supplier for landing gear

Material and safety

Full FAI

Supply chain risk

Deburr clarification or cosmetic surface finish

Cosmetic only

Partial FAI

Unless CTQ

Flight control link restarted after 30 months

Lapse

Full FAI

Revalidate process and fai report

Standard inspection only

No change

No FAI

Normal inspection results still recorded

Default to full FAI if risk is unclear. That rule reduces non conformances, audit debate, and late customer rejection.

First Article Inspection is crucial in industries such as aerospace, defense, and automotive, where precision and quality are paramount, helping to prevent defects and ensure products meet design and performance criteria from the outset of production. The same risk logic appears in other regulated industries, including a medical device production run where a component fails and the team must prove the production process remains valid.

Design Change Triggers: Do All Design Changes Require a Full FAI?

No. AS9102C and most OEM specifications distinguish between changes that affect fit, form, function, safety, or performance and changes that are editorial.

Full FAI is normally required when a design revision:

• Adds or relocates mating interfaces, mounting holes, or datum schemes.
• Changes CTQ tolerances, GD&T, or key components.
• Adds functional requirements for pressure, load, vibration, leakage, electrical paths, or functional testing.

Partial FAI is commonly used when the change is limited to:

• Clarified inspection methods without changing the requirement.
• Spelling, unit symbols, or reference document numbers.
• Removal of unused reference dimensions while retaining the functional scheme.

Before deciding, confirm all routings, digital work instructions, CNC programs, CMM programs, and engineering documentation match the new revision. Some OEMs, including Boeing through D6-51991 practices and primes using advanced product quality planning or AS9145, may require full FAI for any revision on high criticality parts.

Process, Tooling, and Location Changes: When Production Lapses and Restarts Matter

AS9102C treats significant process and context changes as renewed article inspection triggers even when the drawing did not change. The question is whether the prior first article inspection fai still represents the actual production process.

Full FAI is typical for:

• Moving production to a different facility.
• Switching manual machining to five axis CNC, a new molding press, or a new welding cell.
• Replacing key fixtures that locate CTQ features.
• Introducing automation that changes process capability.

A common aerospace rule is that if manufactured parts have not been produced for 24 months or more, full FAI is usually required unless the customer specifies a shorter or longer interval. An actuator housing last built in 2021 and reordered in 2024 should receive full FAI to revalidate the article inspection process and article inspection report fair.

Partial FAI may be reasonable for documented minor tool wear replacement or non-critical cleaning changes. Connect981 can track last-production dates, routing changes, tooling IDs, and production process changes so teams can quickly see whether a full or partial FAI is required.

Material, Special Process, and Supplier Changes: Article Inspection Requirement Impacts

Material and special process changes are frequent sources of escapes. Full FAI is usually required for:

• Alloy or material specification changes, such as 7075-T6 to 7050-T7451.
• Material form changes, such as bar to forging or casting.
• New material supplier for structural or safety-critical parts.

Special process changes also matter. Heat treat, NDT, anodizing, plating, bonding, welding, curing cycle, temperature, or atmosphere changes should trigger re-validation and updated article inspections. If the change may affect performance, fatigue, corrosion, sealing, or safety, default to full FAI. If only a localized coating changes with no CTQ impact, partial FAI may be acceptable with customer approval.

Form 2 must be updated with new certifications, source approvals, test results, and product accountability evidence.

Customer, Regulatory, and Corrective-Action Driven Triggers

First Article Inspection (FAI) is mandated by various industry standards, including AS9100 for aerospace, which requires compliance with specific quality management practices to ensure that products meet design specifications before full production. FAI enhances regulatory compliance, as it is a mandatory requirement for many manufacturing sectors, including aerospace and automotive, ensuring that manufacturers meet critical regulations and standards.

Customer-driven triggers include:

• PO or quality clause requiring “AS9102 full FAI with Forms 1–3.”
• OEM-specific checks, such as BFAI, Boeing First Article Inspection.
• APQP, PPAP, or production part approval process gates.

Corrective-action triggers include:

• Escape or major nonconformance showing the original FAI is no longer valid.
• Repeat defects on CTQ features requiring containment, root cause, and full revalidation.

Audits, DER or UMAR approvals, NADCAP findings, AS9100 gaps, and safety-of-flight issues may also force retroactive full FAIs. Transparent article inspection reports help preserve customer confidence.

Supplier Decision Logic: How to Choose Full vs Partial FAI in Practice

Suppliers need repeatable fai procedures, not ad hoc judgment. A practical path is:

1. Check AS9102C, contract, customer requirements, quality requirements, and purchase order.
2. Classify the trigger: new part, design revision, process change, material change, location change, lapse, or corrective action.
3. Assess fit, form, function, safety, regulatory impact, and whether the article meets all specified requirements.
4. Use an internal matrix to choose full FAI, partial FAI, or no FAI, then document the rationale.
5. Get customer concurrence when selecting partial FAI for borderline cases.

High criticality parts such as flight controls, landing gear, pressure vessels, and structural sub component assemblies should lean toward full FAI. Low-risk covers or brackets may justify partial FAI for minor changes. The decision record should ensure traceability and support future audits.

What a Full FAI Actually Includes: Article Inspection Process and FAIR Content

Once triggered, the first article inspection process must follow a structured inspection process. Utilizing a full FAI can help detect errors, tooling misalignments, or misunderstood specifications before mass production begins, mitigating expensive scrap, rework, and recalls.

The article inspection process includes:

• Validate latest drawings, models, specifications, design specifications, and purchase order requirements.
• Balloon every dimension, material requirement, note, and surface finish.
• Execute dimensional, visual, material, and functional tests using calibrated tools, gages, NDT, and coordinate measuring machines.
• Record measured values, inspection results, pass or fail status, and approval signatures.

The First Article Inspection Report (FAIR) serves as a formal record of the inspection and provides crucial information to both the manufacturing entity and the customer, including inspection details, results, and approval signatures. The First Article Inspection Report (FAIR) is a critical document that summarizes the findings of the FAI process, including inspection results, non-conformance issues, and approval signatures, and is essential for compliance with industry standards.

Good FAIRs improve the approval process, ensure accuracy, support compatibility evaluation, and help both the manufacturer and the customer avoid disputes.

Avoiding Over-Inspection and Under-Inspection: Practical Risk Balancing

Full FAIs consume time. Under-inspection creates escapes. First Article Inspection (FAI) is crucial in various industrial quality management systems and standards, such as ISO 9001 and AS9100, as it acts as a form of risk mitigation by helping to catch potential issues before production begins.

Do not repeat full FAI for pure editorial corrections when no requirement changed. Use partial FAI for tightly scoped changes backed by stable capability data.

Do not rely on partial FAI when the manufacturing method, site, key material, or long lapse has changed. Implementing a structured FAI process can prevent costly defects, which dramatically reduces costs associated with scrap, rework, and product recalls, thereby enhancing overall manufacturing efficiency.

A robust Quality Management System (QMS) provides a structured framework and systematic approach to quality control, which is instrumental in ensuring the accuracy, reliability, and compliance of First Article Inspection processes in the manufacturing industry. Quality Management Systems are essential for ensuring compliance with industry standards such as AS9100, which governs quality assurance in aerospace manufacturing. The implementation of a Quality Management System helps organizations monitor and control all aspects of part production, ensuring that inspection plans are based on the technical data package tied to customer contracts.

One note on terminology: outside manufacturing, a full Fair Admission Index is needed when broad demographic changes invalidate prior admissions results or when transitioning between admissions criteria. In educational contexts, a full Fair Admission Index (FAI) is required when transitioning to a lottery-based system to ensure equitable access for all students. That is not the aerospace first article inspection fai discussed here.

Digitizing FAI and Trigger Logic with Connect981

Connect981 is built for aerospace manufacturing and MRO teams that need reliable digital article inspection fai workflows, not more spreadsheet control points. It connects ERP, MES, QMS, supplier data, documentation, and shopfloor execution in one operations layer.

The Connect981 platform helps teams:

• Centralize engineering documentation, revision history, routings, inspection plan data, and quality management records.
• Embed a configurable FAI trigger matrix into workflows so article inspection requirement decisions are consistent.
• Generate and manage article inspection reports, including characteristic accountability tables from ballooned drawings or models.
• Track production lapses from ERP and MES data and flag when AS9102C logic suggests a new full FAI.
• Link non conformances and corrective actions directly to FAI records.
• Give cross-factory and supplier visibility into current full and partial FAI status.

This ensures consistency, supports continuous improvement, and helps teams exceed customer expectations without adding manual reporting burden.

Request a demo to see a working FAI trigger matrix, digital first article inspection process, and automated FAIR workflow inside Connect981.

In aerospace and defense manufacturing, equipment-related KPIs sit at the core of production visibility, certification readiness, and multi-site reporting. ISO 22400 gives a shared vocabulary for these KPIs, including overall equipment effectiveness (OEE), availability, and utilization, without forcing plants into a single calculation method. For aerospace organizations building a digital thread across MES, ERP, PLM, and quality systems, aligning with the ISO 22400 manufacturing KPI standard helps ensure that equipment performance numbers mean the same thing at every site and supplier.

This article explains how ISO 22400 treats equipment-focused KPIs conceptually, how its OEE-related models (OEEA, OEEB) differ from traditional TPM-style OEE, and how aerospace manufacturers can adopt the terminology without rewriting every KPI formula. The focus is on definitions and structure, not on prescribing a specific way to improve performance.

For teams putting this topic into daily operation, ISO 22400 KPI governance, shop floor execution control, a connected execution platform help connect the concept to traceability, work-order reality, and audit-ready evidence.

The same operating model also depends on Connect 981’s aerospace execution solutions, real aerospace execution examples, Connect 981’s aerospace operations guidance, practical aerospace operations FAQs, especially when decisions have to move across quality, production, suppliers, and program leadership without losing context.

Why Equipment KPIs Are Central in ISO 22400

The role of equipment behavior in manufacturing performance

ISO 22400 pays particular attention to equipment because, in most aerospace production environments, complex assets drive both throughput and certification risk. A five-axis machining center, composite layup cell, or engine test stand may be the bottleneck for an entire aircraft program or propulsion line. If those assets are not running when planned—or if they run but produce nonconforming hardware—schedule and cost performance quickly degrade.

The standard therefore structures many KPIs around how equipment spends time and what it produces in that time. Time spent in specific states (RUN, STOP, IDLE, SLOW) is aggregated into concepts such as operating time, busy time, and downtime. Quantities produced in those time windows are tracked as good parts, rejections, and rework quantities. From these foundational elements, ISO 22400 defines equipment-oriented KPIs that can be compared across different plants, systems, and products.

For aerospace, this provides a disciplined way to separate questions like “Was the machining center available?” from “When it was busy, did it produce conforming hardware?” That distinction is important when determining whether issues belong to maintenance, production planning, or quality engineering.

Linking equipment KPIs to MOM and enterprise decisions

ISO 22400 places equipment KPIs within the broader context of manufacturing operations management (MOM). KPIs such as availability, utilization, and conceptual OEE are positioned at the level where work orders, routings, and resource assignments are executed—typically managed by MES or similar systems. These indicators feed upstream decisions in enterprise systems without forcing those systems to adopt a particular database or UI technology.

In an aerospace plant, this linkage might look like:

• MES level: Tracks equipment state changes, order execution, and scrap events; calculates ISO 22400-aligned indicators.
• ERP level: Consumes summarized equipment KPIs to refine capacity planning, program cost forecasts, and promise dates.
• PLM / configuration management: Uses production execution and quality-related KPIs to assess manufacturability of new designs and the impact of engineering changes.

By using a common ISO 22400 vocabulary across these systems, aerospace organizations can reason about equipment constraints, schedule risk, and capacity investments without debating what “availability” or “utilization” actually mean.

Conceptual View of OEE in ISO 22400

OEE as a composition of time and quantity indicators

ISO 22400 treats overall equipment effectiveness as a conceptual construct rather than as a single mandated formula. In the standard, OEE is assembled from well-defined time-based and quantity-based indicators. Time indicators describe how much of the calendar period is actually used for productive operation, while quantity indicators describe how much of the resulting output meets quality criteria.

This leads to a layered structure:

• Time-based elements: planned time, operating time, busy time, downtime categories, and related state-derived durations.
• Quantity-based elements: produced quantity, accepted quantity, rejected quantity, and reworked quantity.
• Derived indicators: equipment availability, utilization, and conceptual effectiveness ratios built from combinations of the above.

For aerospace plants, this abstraction allows different product families (e.g., composite structures vs. precision machined parts) to maintain their own cycle-time assumptions and yield profiles, while still reporting high-level OEE-related KPIs in a comparable way across programs.

How OEEA and OEEB models are structured conceptually

Within this conceptual framework, ISO 22400 introduces multiple OEE-related models, often referenced in literature as OEEA and OEEB. Each model describes a different way to compose time and quantity elements into an effectiveness measure while staying within the same terminology set.

Conceptually, OEEA tends to emphasize the relationship between busy time and produced volume, while OEEB more explicitly separates availability-related time losses from speed and quality-related losses. Both models rely on the same building blocks:

• Time structure: definitions of when equipment is considered operating, busy, or down.
• State mapping: rules for assigning RUN, STOP, IDLE, and other states into those time buckets.
• Output structure: distinctions between good pieces, scrap, rework, and test output.

ISO 22400 does not require any aerospace manufacturer to select one model over the other. Instead, it provides a common language so that, for example, a machining center in a European airframe plant and a test stand in a North American propulsion facility can both declare which conceptual OEE model they use and how it maps to their local KPI definitions.

Availability, Performance, and Quality Concepts

Time categories used to express availability

Availability in ISO 22400 is based on carefully defined time categories, rather than on informal labels such as “uptime.” Typical categories include:

• Planned time: the portion of the calendar where equipment is scheduled to be available for production or test.
• Operating time: the subset of planned time when the equipment is in a state that can produce, even if it is not actually busy.
• Busy time: the subset of operating time during which equipment is actively executing work (for example, producing a part or running a test sequence).
• Downtime: periods within planned time where the equipment is not available for production due to failures, setups, or other reasons.

For aerospace, this distinction between operating and busy time is important. A radar test bench that is powered on and ready (operating) but waiting for engineering sign-off or configuration data is not busy, yet it still consumes facility resources and may block other work. ISO 22400’s definitions support KPIs that highlight this difference.

Quantity concepts behind performance and quality factors

ISO 22400 also standardizes how quantities are treated within KPIs. Rather than mixing concepts like throughput and yield, it separates them into well-defined indicators:

• Produced quantity: total units processed by the equipment in a period, regardless of quality.
• Accepted quantity: units that meet defined quality criteria and are released for downstream use (assembly, test, shipment).
• Rejected quantity: units that are scrapped or quarantined as nonconforming.
• Reworked quantity: units that initially failed criteria but are successfully recovered through rework.

From these quantities, performance and quality-related factors are derived. In aerospace and space hardware production, where part genealogy and serial-level traceability are mandatory, tying these quantity concepts back to specific work orders, serial numbers, and configurations is essential. ISO 22400 does not define the traceability system itself, but it ensures that KPIs built on top of that system have consistent meaning.

Equipment States and Time Categories

RUN, STOP, IDLE, SLOW and their meaning

Equipment state models in ISO 22400 act as the bridge from control-system signals to conceptual KPIs. Common states include:

• RUN: equipment is executing productive work, such as machining, drilling, or test execution.
• STOP: equipment is not running, often due to a fault, changeover, or scheduled maintenance.
• IDLE: equipment is ready and capable of running but is waiting for material, instructions, or authorization.
• SLOW: equipment is running below its nominal performance, for example due to conservative feed rates on a new material or risk mitigation on a first article.

In an aerospace environment, these states can be further enriched with domain-specific reasons—such as waiting for nonconformance disposition, engineering change approval, or special process certification. ISO 22400 does not prescribe reason codes, but it ensures that however they are defined, they roll up consistently into state-based KPIs.

Mapping states to operating, busy, and downtime categories

Once state definitions are clear, ISO 22400 describes how to group them into time categories that underlie availability and utilization indicators. A typical mapping might be:

• Operating time: RUN, IDLE, SLOW, and possibly certain test or warm-up states.
• Busy time: RUN and SLOW, where equipment is actively processing a work order or test program.
• Downtime: STOP states that occur within planned time, subdivided into planned and unplanned downtime.

For aerospace manufacturers with highly engineered products, this mapping clarifies discussions where engineering or quality events appear as “downtime” from a scheduling perspective. If a composite cure oven is STOP because of an engineering hold on a material batch, the corresponding downtime can be categorized consistently across sites. That, in turn, supports comparisons across programs and facilities when analyzing bottlenecks in a regulated production network.

Comparing ISO 22400 OEE with Traditional TPM OEE

Where definitions align and where they differ

Traditional TPM-style OEE is often implemented as a product of three factors—availability, performance, and quality—each computed according to locally agreed formulas. ISO 22400 aligns with this general structure but is more explicit about the time and quantity elements that underlie each factor. Instead of declaring a single canonical OEE equation, it formalizes the building blocks and offers alternative composition models.

Alignment occurs at the conceptual level: unplanned downtime reduces availability; reduced speed and micro-stops affect performance; nonconforming output reduces quality. Differences arise in the degree of standardization. TPM implementations sometimes blur distinctions between operating vs busy time or between scrap vs rework, whereas ISO 22400 requires these concepts to be clearly separated and named. For aerospace programs seeking audit-ready KPI definitions, this additional clarity is an advantage.

Avoiding confusion in multi-site OEE reporting

One of the main risks in global aerospace production is believing that OEE numbers are comparable when they are not. Two plants might both report “OEE = 78%,” yet one includes test re-runs in performance losses while another does not. ISO 22400 helps avoid this by encouraging organizations to document which conceptual model they use (e.g., OEEA or OEEB), how states are mapped to time categories, and which quantity indicators are included in each factor.

For a multi-site aerospace or space hardware manufacturer, this documentation should be part of the digital manufacturing infrastructure: MES configuration, KPI catalogs, and integration contracts between systems. When a central team aggregates OEE data from different facilities, they can verify that the underlying ISO 22400 concepts match before drawing conclusions about best-performing plants or suppliers.

Using ISO 22400 Equipment KPIs Without Over-Prescription

Selecting which equipment KPIs to track

ISO 22400 defines a structured catalog of KPIs, but it does not tell an aerospace organization which ones it must use. In practice, plants choose a subset aligned with their operational priorities and regulatory context. A few examples:

• Engine test facilities may emphasize utilization and test-cycle adherence KPIs, since test cell access is a scarce resource.
• Precision machining centers may focus on availability and first-pass yield to manage capacity against long-cycle aerospace parts.
• Composite curing operations may track oven utilization and batch conformance indicators, as cure cycles often drive schedule risk.

All of these KPIs can be named and structured according to ISO 22400, even if not every KPI from the standard is implemented. That approach gives aerospace manufacturers a consistent conceptual basis while retaining flexibility.

Communicating definitions across plants and suppliers

The greatest value of ISO 22400 in aerospace manufacturing often appears at the boundaries between organizations: between a prime contractor and its tiered suppliers, or between an OEM and its MRO network. When contracts or performance reviews reference KPIs like equipment availability or utilization, tying those terms to ISO 22400 definitions reduces ambiguity.

Practically, this may involve maintaining an ISO 22400-aligned KPI dictionary within a digital manufacturing platform. Each KPI entry describes which states, time categories, and quantity indicators are used; which OEE-related model (if any) is assumed; and how the KPI is reported. When onboarding a new supplier or bringing a new plant into the network, that dictionary becomes the reference for configuring local MES and reporting systems, and it complements broader discussions of standardized KPIs as described in the ISO 22400 manufacturing KPI standard hub content.

Practical Considerations for Aerospace and Space Hardware Production

Integrating ISO 22400 concepts into MES and digital thread

To make ISO 22400 actionable, aerospace organizations embed its concepts in their MES and digital thread architecture. At the MES layer, equipment states, order events, and quality decisions are captured with sufficient granularity to derive ISO 22400-aligned time and quantity indicators. At higher layers, these indicators are associated with specific configurations, serial numbers, and engineering baselines, tying equipment performance back to the product definition.

In practice, this could mean:

• Standardizing state models and time-category mappings across all test stands or machine types in a program.
• Ensuring that part genealogy records link nonconforming quantities to the exact equipment and time window where they were produced.
• Configuring dashboards so that availability and utilization KPIs are derived from the same ISO 22400 building blocks across different plants.

This creates a consistent KPI layer in the digital thread, improving both operational decision-making and audit readiness.

Working within AS9100 and regulated environments

AS9100 and related aerospace quality requirements emphasize documented processes, traceability, and evidence-based decision-making. ISO 22400 contributes by providing standardized, auditable definitions of what key equipment-related KPIs mean. While AS9100 does not mandate specific OEE values or formulas, it does expect organizations to monitor and control processes that affect product quality and delivery.

By adopting ISO 22400 terminology, an aerospace manufacturer can demonstrate that KPIs used in management review and continuous improvement activities are consistently defined across programs and facilities. This reduces the risk that different sites interpret the same KPI differently during customer or regulatory audits and supports clear linkage between process performance and quality outcomes.

Balancing standardization with local optimization

Finally, ISO 22400 is explicit about its own limits: it standardizes definitions, not business strategy or improvement methods. Aerospace plants remain free to set their own OEE targets, to prioritize certain KPIs over others, and to implement local optimization practices aligned with their mix of programs and technologies.

The practical balance is to keep KPI definitions standardized (names, time and quantity concepts, state mappings) while allowing each plant to decide how aggressively to improve them. A propulsion test center and a structures assembly plant may share the same availability definition but choose different thresholds for what counts as acceptable performance. ISO 22400 supports that diversity by providing a common measurement language rather than enforcing a uniform scorecard.