How do we separate rework cost from normal production labor in our ERP data?

Yes, but only if you design for it. In most ERPs, rework cost does not separate itself automatically from normal production labor. You need a distinct way to collect rework transactions, and that method has to be used consistently on the shop floor.

The practical options are usually:

• separate rework operation numbers within the routing
• dedicated labor codes for rework versus standard production
• a separate rework work order, traveler, or order type
• nonconformance-driven transactions tied to NCR, MRB, or repair disposition records
• reason codes that distinguish planned work, unplanned rework, troubleshooting, inspection repetition, and scrap handling

If labor is booked only to the original production operation with no reason code or secondary identifier, the ERP record will usually blend normal labor and rework labor together. Once that happens, reporting can estimate rework cost, but it generally cannot reconstruct it accurately enough for operational or quality decisions.

What usually works best

The most reliable pattern is to create a controlled rework path that operators or supervisors can actually use during execution:

• Trigger rework from a quality event, such as an NCR or defect record.
• Route the item to a designated rework step, rework cell, or rework order.
• Require labor, material, and outside service charges related to that activity to post against the rework identifier.
• Maintain linkage back to the original work order, serial, lot, or batch so cost and traceability stay connected.

This gives you cleaner reporting for cost of poor quality, but it adds transaction discipline. If the process is too cumbersome, people will bypass it and your data quality will degrade.

What to separate

If your goal is meaningful ERP reporting, separate more than labor hours where possible:

• direct labor used to rework or repair
• additional inspection and test labor caused by the defect
• replacement material and consumables
• machine time if your costing model uses it
• outside processing or supplier rework charges
• administrative quality effort if your organization chooses to track it

Whether all of that belongs in ERP depends on your costing model and system design. Some plants track only direct manufacturing impact in ERP and use QMS or BI layers for broader COPQ analysis.

Key dependencies and failure modes

This depends heavily on system configuration, operator workflow, and master data quality. Common failure modes include:

• rework and normal production sharing the same operation and labor code
• operators booking time after the fact from memory
• supervisors moving parts informally without transaction updates
• quality systems and ERP not sharing a common defect or disposition identifier
• no clear distinction between rework, repair, concession, and scrap paths
• variance accounting masking execution problems until period close

If any of those are true, your reported rework cost may be directionally useful but not decision-grade.

Brownfield reality

In a mixed ERP, MES, QMS, and paper traveler environment, the answer is usually not to replace everything. Full replacement often fails because of qualification burden, validation effort, downtime risk, integration complexity, and the fact that long-lived assets and established processes cannot be swapped out cleanly.

A more realistic approach is to add a minimal rework capture model that coexists with current systems:

• keep ERP as the financial system of record
• use MES or digital travelers to enforce rework step booking where available
• link QMS nonconformance records to ERP work orders or cost objects
• add reason codes and governance before attempting broader system redesign

That approach is less elegant than a greenfield model, but it is often more achievable in regulated operations.

How to tell if your setup is good enough

Your setup is usually good enough if you can answer these questions without manual spreadsheet reconstruction:

• Which labor hours were spent on first-pass production versus rework?
• Which defects or dispositions drove those hours?
• What material and outside service cost was added because of rework?
• Can you trace rework cost by part, order, serial, work center, supplier, or defect type?
• Can you explain the postings during review without relying on tribal knowledge?

If not, the issue is usually process design and transaction discipline before it is analytics.

So the short answer is yes: separate rework cost by creating a distinct, auditable transaction path for rework and enforcing its use. If you do not capture rework distinctly at the point of execution, ERP reporting alone will not solve it later.