Connect981 – Content Dev

RSC Sphere: Buyer Proof and Enablement

The Buyer Proof and Enablement Sphere converts operational authority into decision confidence. It provides ROI models, proof assets, implementation playbooks, and comparison frameworks that buyers can use internally. The content removes ambiguity around outcomes, effort, and risk. This sphere turns credibility into momentum by making decisions easier to justify.

overhead

Operational meaning

In industrial and manufacturing contexts, **overhead** commonly refers to ongoing indirect costs required to run operations that cannot be easily or economically traced to a specific product unit, batch, or job.

These are costs that support production and business activity but are not directly embedded as distinct line items in a unit’s material or direct labor cost.

Typical manufacturing-related overhead categories include:

– **Indirect labor**: supervisors, planners, maintenance, quality engineers, custodial staff
– **Indirect materials and supplies**: lubricants, cleaning agents, tooling wear, general consumables
– **Facilities and utilities**: plant rent or depreciation, lighting, HVAC, water, compressed air, general power
– **Equipment-related costs**: depreciation, calibration, non-project maintenance, insurance
– **Shared services**: production planning, scheduling, IT/OT support, health and safety, HR for the plant
– **General administrative allocation**: accounting, legal, corporate functions allocated to the manufacturing site

In cost accounting, these costs are typically accumulated in overhead cost pools and then allocated to products, processes, or contracts using defined allocation bases (for example, machine hours, labor hours, or cost drivers defined in activity-based costing).

Use in manufacturing workflows and systems

Overhead is used as a distinct cost category in:

– **Standard costing**: overhead rates are set and applied to planned production volumes to estimate unit cost.
– **Job and contract costing**: overhead is allocated to specific jobs, product families, or customers using a chosen allocation basis.
– **Variance analysis**: actual overhead is compared with allocated or absorbed overhead to identify over- or under-absorption.
– **Budgeting and forecasting**: fixed and variable overhead components are planned, then monitored during execution.

In OT/IT environments (MES, ERP, and related systems), overhead:

– Is usually modeled at work center, cost center, or plant level rather than at individual operation records.
– May be allocated automatically during order confirmation or period-end closing based on production quantities or time.
– Can be analyzed alongside direct costs to understand true product or line-level economics.

Boundaries and exclusions

Within this site context, **overhead**:

– **Includes**: indirect, supporting costs necessary for operations but not directly tied to a single unit (for example, supervision, planning, utilities, plant depreciation).
– **Excludes**:
– **Direct materials** (raw and component materials directly incorporated in the product).
– **Direct labor** that can be clearly tracked to a unit, batch, or job.
– **Capital investments themselves** (though the depreciation of capital assets is usually treated as overhead).

Overhead also differs from **waste** in lean manufacturing. Overhead may contain wasteful elements but, as a category, it is not synonymous with waste. Some overhead is necessary to operate safely, compliantly, and reliably.

Common distinctions and confusion

The term **overhead** is sometimes used imprecisely, so several distinctions are useful:

– **Fixed vs. variable overhead**
– *Fixed overhead*: costs that do not change significantly with short-term production volume (for example, base facility rent, some salaried staff).
– *Variable overhead*: costs that change with production activity (for example, some utilities, indirect materials consumption, certain support labor).

– **Manufacturing overhead vs. administrative overhead**
– *Manufacturing overhead*: indirect costs tied to running the plant and production processes.
– *Administrative or general overhead*: corporate-level or non-plant functions (for example, corporate finance, executive management) that may be partially allocated to plants or products.

– **Overhead vs. margin erosion**
– Overhead is a cost category; margin erosion is an outcome where total costs (including overhead) reduce profitability. Overhead may contribute to margin erosion if it is high relative to revenue or poorly allocated.

Site-context application: overhead in fixed-price and MES discussions

In discussions of **fixed-price contracts** and **MES-driven improvements**:

– Overhead is part of the **total delivered cost** for a contract or product line.
– MES or other OT/IT systems may reduce apparent unit costs (for example, via less scrap or rework) but can also unintentionally **add overhead** (for example, additional coordination, reporting, or support burden).
– An improvement is often evaluated by whether it reduces or stabilizes total cost, including any **incremental overhead** created by new processes, systems, or compliance activities.

This makes overhead a key consideration when assessing whether changes in a regulated manufacturing environment truly improve margins rather than shifting costs between direct and indirect categories.

March 25, 2026
How do we identify all relevant processes in our organization?
In regulated industrial environments, you will not get a complete list of relevant processes from any single source. You need a structured, cross-functional approach that triangulates between systems, people, and actual shop-floor behavior.

1. Start from obligations and outcomes, not just org charts

Identify which processes matter by asking two questions:

In practice, this connects to implementation and adoption playbooks when teams need to turn the answer into repeatable execution habits.
- What are we obligated to do? Review contracts, quality manuals, customer requirements, and regulatory standards (e.g. AS9100, AS9102, internal QMS procedures). Each requirement implies processes that must exist, be controlled, and be auditable.
- What outcomes must we reliably achieve? On-time delivery, conformance to spec, traceability, configuration control, data integrity, cybersecurity, and safe operation. Any repeatable set of activities that materially affects these outcomes should be treated as a process, even if it is informal today.
This top-down lens helps you identify which parts of the organization you cannot afford to leave as “tribal” or undocumented.

2. Build a high-level process architecture

Create a simple, end-to-end view before diving into details. Typical categories for an aerospace or similar regulated manufacturer include:
- Core value stream processes: order capture, design/engineering, planning, procurement, manufacturing, inspection, test, packaging, shipping, maintenance/overhaul, and returns/repair.
- Supporting operational processes: document control, training and qualification, tooling and gaging management, calibration, production scheduling, inventory management, IT/OT support.
- Quality and compliance processes: FAI/AS9102, in-process inspection, final inspection, nonconformance management, MRB, CAPA, internal audits, supplier quality management.
- Management and improvement processes: management review, risk assessment, KPI review, continuous improvement, change control.
This architecture will be imperfect, but it gives you a framework to slot in detailed processes later and to see where you may be missing entire classes of activity.

3. Use existing systems as partial process maps

In brownfield environments, some processes are embedded in legacy systems, while others live on paper or in people’s heads. Use each major system as a clue, not a source of truth:
- ERP: order-to-cash, purchasing, inventory movements, MRP, cost tracking. Each major transaction type usually corresponds to a process (e.g. PO creation, receiving, WIP completion, shipping).
- MES / travelers: routing, operation sequences, data collection points, rework flows, holds. Operations that appear repeatedly across routings are processes to document and standardize.
- PLM / PDM: engineering release, BOM management, ECN/ECO workflows, configuration management.
- QMS: nonconformance, CAPA, audit, training, document control workflows. Each template or form often represents a missing or incomplete process description.
- Other tools: maintenance systems, calibration databases, supplier portals, MRO/field-service tools.
Expect gaps: many critical activities, especially handoffs and checks, occur outside these systems via email, spreadsheets, and informal approvals.

4. Walk the floor and follow a real job end to end

System maps are not enough. To uncover actual processes, select a representative work order or repair and:
- Follow it from order entry through shipment (or tear-down through re-delivery in MRO).
- Observe where work pauses, waits for decisions, uses manual logs, or depends on a specific person’s knowledge.
- Note any deviations from documented procedures: alternate paths, workarounds, and side agreements with customers or suppliers.
Every repeatable activity you see that affects quality, cost, delivery, safety, or compliance is a candidate process. Many of these steps will never appear explicitly in ERP/MES but still need to be identified and controlled.

5. Run cross-functional process discovery sessions

Bring together people from operations, quality, engineering, supply chain, IT, and maintenance to review your draft process list:
- Validate the architecture: Ask, “What do we actually do that is not on this list, but if it stopped tomorrow, we would fail an audit, delay shipments, or ship nonconforming product?”
- Surface shadow processes: Excel trackers, shared drive checklists, informal sign-offs, ad-hoc inspection steps, manual label creation, tribal troubleshooting sequences.
- Clarify ownership: Identify a process owner for each major process, even if today it is fragmented.
Be explicit that the goal is not blame or standardization yet, but visibility. Otherwise people will conceal workarounds that are critical to meeting today’s commitments.

6. Prioritize what “relevant” means for your context

In a regulated environment you cannot fully ignore low-impact processes, but you can phase your effort. A practical definition of “relevant” usually includes processes that:
- Directly affect product conformity or airworthiness,
- Impact traceability, genealogy, or configuration control,
- Are required or referenced in your QMS, contracts, or customer supplements,
- Introduce significant risk if they fail (safety, regulatory exposure, major delivery impact), or
- Control core data flows between ERP, MES, PLM, QMS, or external partners.
Start by classifying processes into tiers (e.g. critical, important, supporting). Focus documentation and improvement first on the critical and important tiers, while still logging the rest for future work.

7. Explicitly map brownfield integration and handoffs

Many of the most consequential “processes” are actually handoffs across systems or organizations, for example:
- Engineering releasing revisions in PLM that must be reflected correctly in ERP routings and MES travelers.
- Supplier inspection data or AS9102 packages feeding into receiving and source inspection.
- Nonconformance raised in MES being resolved through QMS and then reflected in updated standard work or part programs.
These cross-system flows are often undocumented and depend on people remembering which files to update or which emails to send. Treat them as processes in their own right, with clear triggers, inputs, outputs, and owners.

8. Expect iteration and incomplete coverage at first

It is unrealistic to “identify all processes” in one pass, especially in multi-plant or multi-program organizations with long equipment lifecycles. Common constraints and failure modes include:
- Legacy equipment and software that cannot easily be instrumented, so parts of the process remain opaque.
- Inconsistent documentation maturity across sites or programs, leaving some processes implicit.
- Integration debt where data is manually re-entered, masking hidden subprocesses and rework loops.
- Change fatigue that makes teams reluctant to surface unofficial but essential steps.
Plan for a living process inventory that is refined as you implement changes, digitize steps, or prepare for audits, rather than assuming a one-time exhaustive mapping.

9. Link process identification to validation and change control

In regulated and aerospace-grade environments, each identified process has implications for validation and change control:
- If a process is critical to quality or compliance, future changes may require formal validation, documented risk assessment, and controlled rollout.
- Processes tightly coupled to equipment or software with long lifecycles will be harder to change, increasing the importance of accurately identifying them upfront.
- Recognizing the full process (including manual and workaround steps) avoids surprise validation scope when you later upgrade ERP/MES/PLM or introduce new tooling.
This is also why full “rip-and-replace” of systems often fails: unrecognized processes and hidden dependencies surface late, making downtime, requalification, and retraining more disruptive than planned. Having a robust process inventory reduces that risk.

10. Minimal practical approach you can start this quarter

If you need a concrete starting plan:
1. Define scope: Pick one value stream (e.g. a product family or MRO line) instead of the entire enterprise.
2. Draft an end-to-end map of that value stream using existing procedures, travelers, and system flows.
3. Walk two or three real jobs through that value stream and document every distinct, repeatable activity.
4. Run a cross-functional review to validate and add missing activities, especially at handoffs and exception paths.
5. Classify and prioritize processes into critical / important / supporting, and assign clear owners for the critical set.
6. Create and maintain a process inventory (even a spreadsheet) listing name, owner, systems used, and criticality. Use this as a baseline for audits, improvement, and future digital projects.
Over time, extend this approach to adjacent value streams and shared support processes. The goal is not perfection but a traceable, defensible understanding of how work actually gets done in your environment.
March 23, 2026
Implementing ISO 22400: Practical Steps to Standardize Manufacturing KPIs
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.
March 23, 2026
Site comparison
Site comparison refers to the structured evaluation of two or more manufacturing or operational sites, or two or more software solutions serving those sites, using a shared set of criteria so that differences can be understood in a consistent and evidence-based way.

Core meaning

In industrial and regulated manufacturing contexts, site comparison commonly refers to:
- Operational site comparison: Comparing multiple plants, lines, or facilities on performance, quality, compliance, labor, and system usage metrics.
- Software or solution comparison across sites: Comparing how different MES, ERP, QMS, or related systems perform or are deployed at various sites, often to support standardization or replacement decisions.
Site comparison typically includes defining consistent criteria, collecting data from each site or system, and presenting results in a way that highlights similarities, gaps, and risks.

What it includes

Depending on the objective, a site comparison may consider:
- Performance and throughput: OEE, bottlenecks, capacity utilization, changeover times.
- Quality and compliance: Defect rates, nonconformance trends, audit findings, traceability practices, documentation control.
- Systems and integration: MES/ERP usage, integration depth, data availability, version control for work instructions and records.
- Workforce and processes: Standard work adherence, training coverage, reliance on tribal knowledge, use of digital work instructions.
- Risk and resilience: Single points of failure, cybersecurity posture (for OT and IT), supply chain exposure, and business continuity considerations.
When focused on software, a site comparison often looks at:
- Feature coverage aligned to manufacturing and compliance needs.
- Implementation complexity and change management effort.
- Integration with existing OT/IT systems and data flows.
- Evidence capture for audits and quality management.
What it does not include

The term site comparison, by itself, does not imply:
- That one site is certified, compliant, or approved relative to another.
- That any formal audit has taken place.
- Commercial claims such as guarantees of performance improvement.
Operational use

Manufacturers use site comparison to:
- Identify best practices at one site that could be replicated at others.
- Prioritize investments in systems, training, or process changes.
- Support software selection or consolidation across a multi-site network.
- Provide stakeholders with a clear, structured view of differences in capability, risk, or readiness between locations.
Common confusion
- Site comparison vs. audit: An audit checks conformance against a defined standard; a site comparison contrasts sites or systems against each other or a shared criteria set. A comparison can use audit data but is not itself an audit.
- Site comparison vs. benchmarking: Benchmarking often compares performance to external or industry standards. Site comparison is more often internal, focusing on differences across a company’s own plants or solutions.
March 21, 2026
ISO 22400 KPI Categories: How the Standard Structures Manufacturing Metrics
ISO 22400 KPI Categories: How the Standard Structures Manufacturing Metrics

ISO 22400 gives aerospace and defense manufacturers a common language for describing manufacturing KPIs, but its real power shows up in how it categorizes those KPIs. The standard defines families and structures that cut across production, maintenance, quality, logistics, and energy, and it organizes indicators by object of measurement, organizational level, time horizon, and data type. For a digital aerospace factory, aligning to these categories makes it far easier to build interoperable MES dashboards, multi-site reports, and supplier KPIs that actually compare. This article explains how those ISO 22400 KPI categories work and how to apply them to aerospace operations, in conjunction with the broader ISO 22400 manufacturing KPI framework.

Why KPI Categorization Matters in ISO 22400

ISO 22400 is not just a list of 34 KPIs; it is a conceptual model for how performance indicators fit together. That structure is critical in regulated aerospace environments where programs, sites, and suppliers must align on definitions without being forced into one rigid dashboard template.

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

For teams putting this topic into daily operation, ISO 22400 KPI governance, a connected execution platform, Connect 981’s aerospace execution solutions help connect the concept to traceability, work-order reality, and audit-ready evidence.

The same operating model also depends on 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.

Linking KPI families to decision-making levels

Within ISO 22400, KPI families are implicitly tied to different decision-making levels, from shift supervision to site leadership. For example, equipment-oriented indicators such as utilization and state-based time structure sit close to Level 3 (manufacturing operations management) in the IEC 62264 hierarchy, where production supervisors and manufacturing engineers work. Order-related KPIs—such as adherence between planned and executed order times—are more relevant to planning teams and program managers who need to reconcile capacity, delivery dates, and contract performance.

In an aerospace plant, this means:
- Cell leads and work-center supervisors focus on work-unit and line-level KPIs: machine availability, changeover behavior, and state distributions that explain why a composite layup cell or machining center is not meeting expected output.
- Manufacturing engineering and industrialization teams focus on KPI families that compare planned versus actual routing times, NC program execution efficiency, and yield along the route.
- Site leadership and program management rely on aggregated, ISO 22400-aligned KPIs (for example, site-level equipment utilization or order execution reliability) for capacity reviews and program health checks.
Because KPI families are defined against the same conceptual structure, a site director can drill from a site-level scorecard down to a specific line or work unit without changing definitions along the way.

Avoiding duplication and metric overload

Aerospace factories frequently suffer from metric overload: multiple versions of “availability,” “efficiency,” or “on-time completion,” each defined differently by functions or programs. ISO 22400 reduces this risk by describing consistent categories and relationships among KPIs rather than letting each team invent their own vocabulary.

By mapping plant-level metrics into ISO 22400 families, organizations can:
- Recognize when two KPIs are actually the same concept with different names, and standardize on one.
- Differentiate truly distinct indicators—such as a state-based availability measure versus an order-based schedule adherence KPI—so they are not conflated in reviews.
- Limit dashboards to a curated subset of indicators that cover each needed category, instead of adding every variant of a similar measure.
The result is leaner KPI sets that still cover production, quality, logistics, maintenance, and energy performance without redundant metrics that confuse operators and leadership.

Functional Domains: Production, Maintenance, Quality, Logistics, Energy

ISO 22400 groups KPIs by functional domain, recognizing that production, maintenance, quality, logistics, and energy each view the same manufacturing reality from different angles. This is especially important in aerospace, where a single nonconforming part can block production, disrupt logistics, and trigger additional inspection and rework.

Production-oriented KPI families

Production-oriented KPI families focus on how effectively a plant converts planned production time and capacity into conforming output. In aerospace environments, these families are typically applied to:
- Machining cells and special processes (e.g., heat treatment, shot peening, composite curing), where time in RUN, STOP, and IDLE states directly affects backlog.
- Assembly lines for fuselage sections, engine modules, or avionics racks, where takt adherence and order progression must align with program schedules.
- Test cells for engines or components, where utilization, test cycle duration, and retest rates influence delivery performance.
Within these families, ISO 22400 distinguishes between:
- Equipment-focused indicators based on how a work unit spends its time.
- Order-focused indicators based on how production orders progress versus plan.
- Quantity-focused indicators summarizing produced, accepted, and rejected quantities over a period.
Digital manufacturing systems can use these definitions to consistently classify data, regardless of whether the underlying process is machining a titanium bracket or assembling a guidance module.

Maintenance, quality, and logistics-oriented KPI families

Beyond pure production, ISO 22400 addresses KPI families that reflect other MOM functions:
- Maintenance-oriented KPIs focus on the effect of planned and unplanned maintenance on equipment availability and capacity. In aerospace, this includes indicators such as the proportion of equipment time blocked for scheduled calibration, the impact of unscheduled downtime on critical path operations, and readiness of special-process equipment.
- Quality-oriented KPIs measure how often output meets acceptance criteria, where nonconformances occur, and how rework affects flow. Typical examples include yield at a specific operation, rework ratio at a special process, or defect occurrence along a route. These indicators are particularly important in AS9100 environments where escape risk and recurring defects must be tightly controlled.
- Logistics-oriented KPIs track material availability, work-in-progress location, and buffer behavior. For aerospace, this may cover kit completeness at line-side, staging accuracy for high-value components, and the effect of material shortages on order delays.
- Energy-oriented KPIs relate energy consumption to production output or time in particular states. For example, a test cell’s energy use per test hour or a heat-treat furnace’s energy consumption per conforming batch.
Each domain can own its specific indicators while still using a shared ISO 22400 vocabulary. A maintenance engineer and a quality engineer may discuss very different KPIs, but both can interpret how those KPIs relate to equipment states, orders, and time structures defined by the standard.

Objects of Measurement and Organizational Levels

Another ISO 22400 categorization dimension is the object of measurement—what the KPI actually describes—and the organizational level at which the KPI is applied. For aerospace operations, this is crucial for aligning cell-level realities with program-level commitments.

From work unit to plant: where KPIs apply

ISO 22400 recognizes different physical and logical objects of measurement, such as work units, work centers, areas, and whole plants. In an aerospace context, these might correspond to:
- Work unit: A single machine (e.g., 5-axis mill, autoclave, coordinate measuring machine) or test stand.
- Work center: A machining cell, composite layup area, or electrical harness assembly cell.
- Area: A major section of the plant such as structural assembly, engine module build, or space payload integration.
- Plant: The full manufacturing site manufacturing for multiple programs and customers.
The same KPI family can be rolled up or down across these levels. For example, equipment utilization may be calculated for a single autoclave, aggregated across all autoclaves in the composite area, and further aggregated into a single composite-area capacity utilization metric for site-level planning.

Aligning KPIs with enterprise/site/area/work center levels

ISO 22400 uses a hierarchy consistent with IEC 62264, including enterprise, site, area, work center, and work unit. In aerospace, program management often spans multiple sites and suppliers, so the same conceptual KPI must be interpretable at each level:
- Enterprise/program level: KPIs provide a cross-site view for a given aircraft, engine, or spacecraft program—for example, average order execution reliability across all plants producing a specific module.
- Site level: Indicators highlight how a single plant performs overall, merging MOM data from machining, assembly, and test areas.
- Area/work center level: KPIs show whether specific operations—like avionics integration or engine final assembly—are constraining throughput or generating disproportionate quality issues.
- Work unit level: Detailed, state-based KPIs drive troubleshooting of particular machines or cells.
Standards-aligned MES and reporting systems can map the same ISO 22400 KPI definitions up and down this hierarchy, simplifying multi-site benchmarking. A digital thread architecture can then tie those KPIs back to product definitions, routings, and configuration baselines.

Time Horizons and Data Types in ISO 22400 KPIs

ISO 22400 also categorizes KPIs by time horizon and data type. This is essential for aerospace manufacturing, where near-real-time decisions (such as reacting to a delayed material kit) must coexist with long-horizon metrics used in capacity and capital planning.

Real-time vs. aggregated KPIs

The standard distinguishes KPIs that are meaningful in near real time from those that require aggregation. For instance:
- Real-time, state-based views: Dashboards showing the current status of critical machines (RUN, IDLE, STOP) for a hot engine-build or spacecraft integration area.
- Shift- or day-level aggregations: Utilization and yield indicators over a shift, supporting crew debriefs and daily tier meetings.
- Week- and month-level trends: Longer-term capacity and reliability behaviors used for staffing, capital planning, and program performance reviews.
- Order-lifecycle metrics: KPIs computed per production order or lot, from release to completion, such as order execution reliability or overall order lead-time breakdown.
A standards-based MES can label each KPI with its intended time behavior, making it clear which indicators are suitable for live shop-floor management versus retrospective analysis.

State-based vs. quantity-based indicators

ISO 22400 differentiates indicators driven primarily by states (time spent in defined equipment or order states) from those driven by quantities (produced, accepted, rejected units). Aerospace plants use both:
- State-based indicators might capture the proportion of time an autoclave spends in RUN versus WAIT_FOR_LOAD, or how often a test cell is STOP due to missing instrumentation or ground support equipment.
- Quantity-based indicators describe the number of conforming parts produced, scrap and rework volumes, or the ratio of accepted to total tested units during a given horizon.
Many ISO 22400 KPIs combine both elements—for example, relating produced quantity to operating time. Aerospace manufacturers can use these distinctions to structure historians and data models: one layer describing states and times, another capturing quantities and results, and ISO 22400 KPIs defined on top of that foundation.

Interdependencies Among the 34 ISO 22400-2 KPIs

The 34 KPIs in ISO 22400-2 are not stand-alone; they share common time and quantity structures. This interdependency is especially important when analyzing complex aerospace production systems, where multiple indicators can shift together when a constraint or quality issue emerges.

How changes in one KPI affect others

Because ISO 22400 KPIs often share time categories or quantities, changing one part of the system can shift many indicators simultaneously. For example:
- Improved maintenance planning that converts unplanned stops into scheduled downtime may improve equipment availability while slightly reducing nominal production time.
- Reducing rework by addressing a recurring nonconformance at a machining operation may improve both yield and overall order execution reliability, since fewer orders are delayed for additional processing.
- Simplifying changeovers in a cell may reduce setup time, improving utilization and throughput without changing total scheduled hours.
From a standards viewpoint, these moves reallocate time among well-defined categories or change the ratio of accepted to total output. The interdependencies encoded in ISO 22400 make those trade-offs transparent.

Practical implications for root cause analysis

For root cause analysis, using ISO 22400 categories means that engineering and operations teams can rely on consistent relationships when drilling into issues. If aircraft wing assembly is behind schedule, analysts can reference:
- State-based KPIs for the key work centers to see whether availability or planned stoppages are driving lost time.
- Order-related KPIs to see whether delays are concentrated at specific operations or spread across the route.
- Quality-oriented KPIs to see whether rework or nonconformances are consuming unexpected capacity.
Because these KPIs are defined on shared time and quantity structures, conclusions drawn from one plant can more readily be compared to another site or supplier using the same ISO 22400 concepts, reinforcing both internal and external benchmarking efforts.

Designing Dashboards Aligned with ISO 22400 Categories

ISO 22400 does not prescribe one dashboard design, but its categories make it easier to build coherent views. For aerospace digital factories implementing an MES or a broader digital thread platform, these categories become the backbone of KPI visualization strategies.

Grouping KPIs by function and object of measurement

A practical way to design dashboards is to use ISO 22400 dimensions explicitly:
- By functional domain: Separate views for production, maintenance, quality, logistics, and energy so each function sees indicators relevant to its responsibilities while still sharing a consistent vocabulary.
- By object of measurement: Dashboards aimed at work-unit, work-center, area, or plant level, each using the same definitions but different aggregation scopes.
- By time horizon: Live status displays for control rooms and cells, shift/24-hour summaries for supervisors, and weekly/monthly analytics for managers and continuous improvement teams.
- By data type: Distinct panels for state-based time structure, quantity and yield metrics, and order-level execution indicators.
For example, a composite manufacturing area might have:
- A cell operator view showing current state of each autoclave, queue length, and imminent order completions.
- A supervisor view with shift-level utilization, scrap/rework rates by work center, and schedule adherence by order family.
- An engineering view focused on process capability and chronic downtime causes, using the same ISO 22400 categories but with more diagnostic detail.
Examples of cross-functional KPI views

Cross-functional dashboards are where ISO 22400 categories deliver the most value. Consider a site-level aerospace production visibility system that provides:
- Production KPIs at area and plant level (e.g., equipment utilization, order execution reliability).
- Quality KPIs linked to the same orders and work centers (e.g., yield, rework ratios, nonconformance density at special processes).
- Logistics KPIs describing kit completeness and on-time availability of critical materials for those same orders.
- Energy KPIs for high-consumption equipment such as autoclaves or test cells, tied back to output volume.
Because all KPIs use ISO 22400-compliant definitions, a program manager reviewing a late aircraft structure can see, in one place, whether the constraint is equipment availability, quality escapes, missing material, or a combination of the three. When that manager then looks across multiple sites or key suppliers, indicators are directly comparable without negotiating new definitions each time.

Platforms such as Connect 981 can implement these concepts as part of a standards-aligned digital manufacturing infrastructure, while allowing each aerospace organization to choose which ISO 22400 KPI families matter most for their operations and how they should be combined in reports and analyses.
March 9, 2026