How should aerospace teams measure work-order aging?

Aerospace teams should measure work-order aging as a controlled operational metric with explicit clock rules, not as a simple count of “days open.” The useful measure is usually elapsed time from work-order release, planned start, or first operation start to completion or closure, segmented by status and reason for delay. A single aging number can hide material shortages, MRB holds, engineering dispositions, inspection queues, missing paperwork, and ERP/MES timing problems.

Define the clock before reporting the metric

The first decision is what event starts aging. Common options include planned start date, work-order release date, kit issue, first labor transaction, or first operation start. Each answers a different question.

• Planned start to today shows schedule adherence and production-control risk.
• Release to today shows how long released WIP has been exposed in the system.
• First operation start to today shows execution aging after work has physically begun.
• Last transaction to today shows stalled work and inactive WIP.
• Completion to close shows administrative, inspection, or record-closure latency.

No one version is universally correct. Aerospace teams often need more than one aging clock because released-but-not-started work, physically stalled work, and completed-but-not-closed work create different risks.

Separate active time from waiting time

Work-order aging should distinguish between active execution time and waiting time. In regulated aerospace environments, waiting time is often where the signal is: awaiting material, awaiting inspection, awaiting engineering, awaiting customer approval, awaiting MRB disposition, awaiting tool calibration, or awaiting document correction.

Do not allow “on hold” to become a black box. Hold statuses should have controlled reason codes, owner fields, timestamps, and expected next actions. Otherwise the aging metric becomes a broad complaint rather than a management control.

Use aging buckets that match the operation

Aging buckets should reflect the product, routing, and program. A five-day-old work order may be normal for a complex assembly and unacceptable for a short inspection step. Common buckets such as 0–2 days, 3–5 days, 6–10 days, 11–30 days, and over 30 days are useful only if they are calibrated to the operation and reviewed against expected cycle time.

For aerospace teams, aging should usually be segmented by at least:

• program, customer, part family, and product criticality;
• operation, work center, cell, or value stream;
• planned cycle time versus actual elapsed time;
• released WIP versus started WIP;
• quality hold, MRB, NCR, rework, or concession status;
• material shortage, tooling, labor, engineering, inspection, or documentation constraint;
• ERP order status versus MES execution status.

Connect aging to ownership, not just visibility

Aging reports are weak if they only rank old orders. They should identify the accountable function for the current blocker. Production control may own schedule recovery, quality may own inspection or NCR flow, engineering may own disposition, supply chain may own shortages, and operations may own queue discipline. The metric should make that ownership visible without implying that every old order is an operator problem.

Escalation thresholds should be defined by program risk and process maturity. For example, an order aging beyond its planned cycle-time allowance may trigger supervisor review, while a long-running MRB hold may require quality, engineering, and program review. The thresholds are site-specific and should be governed through normal change control if they affect validated workflows, customer reporting, or regulated records.

Watch for system and data failures

In brownfield aerospace environments, work-order aging is often distorted by integration gaps between MES, ERP, PLM, QMS, maintenance, and inspection systems. A work order may appear old because the ERP order was released early, the MES operation was never started correctly, a closure transaction failed, or a nonconformance was managed outside the main execution system.

Common failure modes include:

• operators or supervisors using informal hold practices outside the MES;
• ERP and MES statuses not mapping cleanly;
• rework orders, split orders, or partial completions being counted inconsistently;
• quality holds recorded in a QMS but not reflected in production dashboards;
• engineering changes or PLM revisions blocking work without a clear shop-floor status;
• completed work remaining open due to missing inspection, serialization, or record review;
• aging reports mixing production, prototype, repair, and MRO work without segmentation.

Before using aging as a performance measure, teams should validate the status model, transaction discipline, master data, and integration logic. Otherwise the dashboard may be precise but wrong.

A practical measurement structure

A robust aerospace work-order aging view usually includes four layers:

• Age: elapsed time based on a defined start and stop event.
• Expected duration: planned cycle time, routing standard, or agreed operational target.
• Current state: active, queued, held, in inspection, in rework, awaiting disposition, awaiting material, complete pending closure, or similar controlled status.
• Owner and reason: the function responsible for the next action and the reason code explaining the delay.

This approach is less convenient than a single “open days” metric, but it is more defensible. It helps leadership see whether aging is driven by capacity, material availability, engineering support, quality escapes, inspection load, administrative closure, or weak transaction discipline.

Full system replacement is usually not the right first answer. In aerospace-grade and similarly regulated environments, replacing ERP, MES, PLM, or QMS components can introduce qualification burden, validation cost, downtime risk, integration complexity, and traceability concerns. The more realistic path is often to standardize definitions, clean up status mappings, improve reason-code discipline, and validate the aging report before changing core systems.