Aerospace teams should measure rework impact as the combined effect on cost, capacity, schedule, and quality risk. Labor hours matter, but they are not enough. A reworked part can consume constrained inspection capacity, trigger MRB or engineering review, delay downstream assemblies, consume replacement material, and increase traceability burden even when the part is ultimately accepted.
The first step is to define rework consistently in the QMS. In aerospace environments, rework is often treated differently from repair, scrap, concession, deviation, or use-as-is disposition. Those distinctions matter because they drive approvals, records, cost treatment, and customer visibility. If the site uses inconsistent definitions across programs or plants, the metric will be hard to trust.
Measure more than rework hours
A practical measurement model usually includes several views:
- Direct labor: additional touch time, inspection time, setup time, test time, and supervision time tied to the rework activity.
- Capacity loss: lost throughput at constrained work centers, queues created by reinspection, and disruption to planned routings.
- Schedule impact: days of delay to the work order, assembly, shipment, or customer milestone.
- Material impact: replacement parts, consumables, tooling wear, retest articles, and any scrapped components created during rework.
- Engineering and quality burden: MRB time, NCR processing, disposition review, source inspection support, documentation updates, and CAPA activity where applicable.
- Recurrence: repeat defects by part number, process step, supplier, operator group, tool, machine, revision, or characteristic.
For leadership reporting, the most useful indicators are often rework hours as a percentage of earned standard hours, rework cost as part of cost of poor quality, rework-related schedule slip, repeat NCR rate, and constrained-resource hours consumed by rework. No single metric is sufficient.
Use traceable operational data
The measurement should be tied to the actual execution record: serial number or lot, work order, routing operation, revision, nonconformance record, disposition, and reinspection result. Without that linkage, rework reporting tends to become a finance estimate or a manual quality spreadsheet rather than an operational control.
In brownfield plants, the required data is usually split across MES, ERP, PLM, QMS, inspection systems, maintenance systems, and sometimes supplier portals. Full replacement of these systems is usually unrealistic in aerospace-grade environments because of qualification burden, validation cost, downtime risk, integration complexity, change control, and long equipment lifecycles. Teams normally get better results by improving definitions, integrations, and data capture at the points where rework is created and closed.
Separate cost from constraint impact
Cost is important, but it can hide the real operational problem. A low-cost rework activity at a bottleneck inspection station may be more damaging than a higher-cost activity on an unconstrained bench. Aerospace teams should therefore report both financial impact and capacity impact.
A useful distinction is:
- Financial impact: labor, material, outside processing, scrap, and overhead allocation.
- Operational impact: lost bottleneck time, schedule recovery effort, queue growth, expediting, and delayed downstream work.
- Quality-system impact: NCR aging, MRB backlog, repeat causes, CAPA linkage, and audit trail completeness.
Common failure modes
Rework metrics fail when teams count only what is easy to capture. Common problems include off-system rework, operators not booking time to the right activity, rework hidden inside normal operation time, inconsistent reason codes, missing links between NCRs and work orders, and duplicate defect coding across plants.
Another common failure is measuring rework only after escape or customer impact. Internal rework still matters because it consumes capacity and may indicate process instability. That said, not every rework event has the same risk profile. A documented, approved, low-complexity rework step is not the same as repeated rework on a critical characteristic requiring engineering disposition.
What good reporting looks like
A credible rework dashboard should let teams drill from enterprise trends down to program, part number, operation, defect mode, supplier, and serial or lot history. It should show both volume and severity. It should also separate first-time events from repeat events, because recurrence is where many RCCA and CAPA priorities should be focused.
The numbers are only as reliable as the process discipline behind them. Teams need controlled reason codes, defined ownership for NCR and MRB closure, validated system interfaces, and change control when routings, inspection plans, or disposition workflows change. Rework measurement does not by itself improve quality or guarantee compliance outcomes, but it can give operations, engineering, quality, and finance a more defensible view of where capacity and cost are being consumed.