Aerospace teams should measure queue time as the elapsed time between a unit, lot, or work order becoming ready for the next controlled step and that step actually starting. That sounds simple, but it only produces useful data if the site defines “ready,” “started,” “on hold,” “in inspection,” and “in rework” consistently. In regulated aerospace environments, queue time should not be treated as one generic delay bucket. Quality holds, material shortages, engineering dispositions, inspection waits, tooling issues, and true capacity queues need to be separated.
Start with a controlled definition
The most useful baseline is operation-level queue time:
- Start: the previous operation is completed, accepted, and released to the next operation.
- Stop: the next operation is actually started by the responsible resource, operator, machine, cell, or inspection function.
This should be measured against the released routing and revision in effect at the time. If the routing changes, the measurement rules should remain traceable. Otherwise, historical comparisons become misleading.
Some teams also measure resource queue time, which starts when work physically or electronically arrives at a work center and stops at first touch. That can be useful for local bottleneck analysis, but it is not always the same as operation queue time. A job may be complete in the MES but not physically staged, kitted, inspected, or authorized to proceed.
Separate queue from holds
A common failure mode is counting every idle period as queue time. That hides the real constraint. Aerospace teams should usually separate at least these states:
- Capacity queue: work is ready, but the required resource is not available.
- Inspection queue: work is awaiting source inspection, in-process inspection, final inspection, or delegated inspection activity.
- Quality hold: work is stopped due to NCR, MRB, suspected nonconformance, containment, or disposition.
- Engineering hold: work is waiting for technical clarification, drawing interpretation, planning update, or deviation handling.
- Material or tooling hold: work cannot proceed because required material, kit, fixture, gage, calibration status, or tool availability is missing.
- Administrative hold: work is waiting for release, signoff, customer approval, export-control review, or record correction.
These categories do not need to be perfect on day one, but they need to be stable enough to support trend analysis. If operators or supervisors choose reason codes inconsistently, the metric will look precise while still being unreliable.
Use timestamps from execution systems, not only ERP dates
ERP planned start and finish dates are usually too coarse to measure queue time accurately. They are useful for planning and financial control, but they often do not capture actual first-touch events, inspection queues, partial completions, rework loops, or local holds.
Better queue-time measurement usually comes from MES, digital travelers, barcode scans, equipment events, inspection systems, or controlled work center transactions. In brownfield plants, those sources often need to be reconciled with ERP, PLM, QMS, calibration, maintenance, and supplier systems. Full system replacement is usually unrealistic in aerospace-grade environments because of qualification burden, validation cost, downtime risk, integration complexity, traceability obligations, change control, and long asset lifecycles. A practical approach is usually to standardize state definitions and integrate the minimum reliable events first.
Measure at more than one level
One average queue-time number is rarely useful. Aerospace teams should analyze queue time by:
- program, product family, part number, and routing revision;
- serial number, lot, work order, or shop order;
- operation, work center, cell, inspection point, and supplier step;
- queue reason code and hold type;
- priority class, customer commitment, and rate-readiness impact;
- calendar time and working time, reported separately where both matter.
Percentiles and aging buckets are often more useful than averages. A few long-tail queues can create delivery risk even when the average looks acceptable. P50, P80, P90, and oldest-open-WIP views can show different operational realities.
Watch the data quality problems
Queue-time metrics fail when the event data is weak. Typical problems include late scans, batch completions, backflushing, informal movement between cells, unrecorded holds, rework that bypasses the normal routing, shared queues that are not visible in the system, and manual timestamp corrections without sufficient audit trail.
Shift calendars, weekends, holidays, time zones, and daylight saving changes also matter. Some plants need both elapsed calendar time and staffed working time. Neither is universally better; they answer different questions.
Automated timestamps can help, but they do not remove the need for validation. Equipment events, MES transactions, RFID reads, and operator scans still need rules for exception handling, false starts, restarts, and partial work. In regulated environments, changes to those rules should be controlled, tested, and documented.
Use the metric to locate constraints, not to blame the floor
Queue time is most useful when it identifies where work is waiting and why. It should be paired with WIP aging, touch time, cycle time, inspection backlog, MRB aging, shortage status, and constraint capacity. If queue time is used only as a labor performance measure, teams may learn to close transactions early, delay status changes, or move work physically without recording it properly.
The goal is not a perfect theoretical number. The goal is a traceable, repeatable measurement that helps distinguish capacity problems from quality, material, engineering, and system-control problems. The accuracy of the metric depends on process discipline, system integration, master data quality, and the maturity of local execution controls.