Reworked Unit, Replaced Component: Does Your Build History Still Tell the Truth?
During NPI, repair and rework can change the as-built configuration. EMS genealogy should update component, operation, defect and repair history so the delivered unit record reflects what actually happened.
The short answer
The as-built history remains truthful only if rework and repair update the manufacturing genealogy. During NPI, a unit may have components replaced, firmware changed, operations repeated or defects repaired. If the original build record remains unchanged, traceability no longer represents the delivered unit.
Rework is therefore both a quality process and a configuration-control process.
The same question belongs to the wider Prototype Built. How Do You Turn NPI Into Stable EMS Production? operating picture: rework and repair genealogy has to remain connected to the decisions made before and after it, rather than becoming a separate local control.
Distinguish defect from repair action
A defect explains what was wrong.
A repair action explains what was done.
Keep both.
Replacing a component does not tell the team why replacement was necessary. Update component genealogy. If a trace-controlled component is removed and replaced, the final record should show the new component identity.
Where required, preserve the removed component history too. Track firmware changes. Repair can include reprogramming.
If firmware revision is part of product configuration, update the final as-built state. Record repeated operations. A board may return to test, inspection or another operation.
The route history should show the rework loop rather than pretending the original path succeeded. Control rework instructions. A technician may know how to repair a defect.
Volume production needs approved methods for recurring rework.
If a repair becomes common during NPI, formalize the instruction.
Separate engineering modification from production rework. NPI engineers sometimes change a unit intentionally to test a design idea.
That is different from repairing a production defect.
Classify the event correctly so genealogy remains understandable. Use authorization for high-risk repair. Some repairs may affect safety, reliability or customer approval.
Define who can authorize them.
Do not let all repair decisions become technician discretion.
Trace material used during rework
If the replacement component needs lot or serial traceability, capture it at the repair station.
The genealogy chain should remain complete. Review scrap decision. Some failures are not economically or technically repairable.
Use controlled disposition so bad units do not repeatedly cycle through rework. Learn from repeat repairs. High repair frequency indicates the process or design is not stable.
Aggregate rework by defect and cause.
Do not normalize repair as standard production. Connect rework cost. Repair consumes labour, components, test and cycle time.
Capture enough cost to understand whether NPI problems are becoming a recurring volume burden. Preserve customer-visible history where required. Some customers require disclosure or limits on reworked units.
The system should support the agreed rule.
Keep repair stations under the same revision control. Repair technicians need current schematics, firmware and rework instructions.
An old repair document can reintroduce a superseded component or setting.
Treat repair documentation as part of the controlled manufacturing baseline. Track no-fault-found separately. Units that pass after retest without a confirmed repair should not be mixed with known fixes.
A high no-fault-found rate may indicate fixture, test limit or intermittent process problems.
That is valuable NPI evidence.
Use repair data in design feedback
Repeated component replacement at the same location can indicate a design or manufacturability weakness.
Feed that pattern back to engineering rather than optimizing the repair process around a permanent defect source. Define repair genealogy by product risk. Some products need only work-order-level repair history.
Others require serial-to-component genealogy.
Define the rule during NPI.
The execution system should capture the level the customer or quality model actually requires.
This avoids both under-control and unnecessary scanning. Control salvaged components. If a component is removed and considered reusable, define whether it can return to inventory and under what identity or inspection condition.
Uncontrolled salvage can break traceability and quality status.
Many manufacturers choose stricter rules for high-risk components.
Record technician and station context. For significant repair, knowing who performed the work and at which station can support investigation and training.
This does not need to become punitive tracking.
The purpose is to preserve enough context to understand recurring repair patterns. Retest against the correct revision. After repair, the unit should return to the appropriate test process for its current hardware and software configuration.
Do not assume the original test path remains valid after a material or firmware change. Keep repeated repair visible. A unit that fails repeatedly may need escalation or scrap.
Define limits or review rules.
Unlimited rework can consume time and create reliability risk.
Use repair evidence to improve test
If many units are repaired but the root cause is actually fixture or limit instability, the repair station may be treating healthy units.
Compare repair findings with test-failure data.
This can reveal false failures. Connect repair cost to NPI decisions. High repair content can make the product appear to reach final yield while hiding poor economics.
Capture repair labor and replacement components sufficiently to understand the cost of instability. Close the loop before volume. If one repair action becomes frequent and predictable, either remove the cause or formalize a controlled process with appropriate pricing and capacity assumptions.
Do not allow “NPI-only repair” to become invisible standard work.
Define disposition categories. Repair is only one possible disposition.
A failed unit may be:
- reworked;
- used as engineering sample;
- scrapped;
- returned to supplier;
- accepted under deviation.
Use clear categories so inventory, cost and genealogy remain consistent. Protect traceability after board swap. In box-build or higher-level assembly, a complete PCB or module may be replaced.
The finished unit genealogy should update to the replacement assembly where unit-level traceability is required.
Otherwise the parent serial still points to hardware that is no longer inside the product. Link rework to the original defect ticket. Keep the defect, disposition, repair and retest connected.
Separate records force quality teams to reconstruct the story later.
A linked history also improves analysis of which repair actions are effective.
Validate repaired units against shipment policy
Some customers allow repaired production units; others restrict them.
The system should support the agreed rule and make status visible before shipment. Measure repair turnaround. Long repair queues can delay NPI schedules and hide capacity needs.
Track time from defect detection to disposition and successful retest.
This reveals whether diagnostics, parts availability or authorization is slowing recovery. Use rework to improve service planning. If similar products in the field may need repair later, NPI rework evidence can inform service procedures, spare strategy and diagnostic tools.
This creates value beyond the launch itself. Keep replacement-material control aligned with AVL rules. A repair technician may urgently need a replacement component.
The same approved-manufacturer and source rules that apply to normal production should apply to repair unless a controlled deviation says otherwise.
Repair should not become a back door around component governance.
Review rework instructions after design change. A repair method valid for one revision may be wrong for another.
When an ECN changes the affected circuit or component, review the associated rework instruction.
This keeps repair knowledge aligned with the current product baseline. Close repaired-unit genealogy before completion. Do not allow the work order or unit to move to completed/shippable status while required repair genealogy is still pending.
Making trace completion part of the workflow reduces after-the-fact data cleanup.
This keeps the delivered unit record aligned with the actual repaired configuration and the controls used to approve it.
For high-control products, this discipline also supports faster customer response because the company can reconstruct the final repaired configuration without relying on technician memory.
What management should measure
Useful indicators include:
- rework rate;
- repeat repair;
- component replacements;
- firmware reprogramming;
- units with genealogy update after repair;
- recurring rework instructions;
- scrap after failed repair;
- repair hours during NPI.
A practical review
Choose one repaired NPI unit. Ask whether the system can show the original defect, repair action, replaced component, retest result and final configuration without reconstructing the story manually.
Where Epicor Mars fits in rework and repair genealogy
For rework and repair genealogy, the key system-design question is how to keep enterprise control and electronics-specific execution on the same operating thread. Epicor provides the enterprise-grade ERP foundation for customer orders, purchasing, inventory, planning, costing, finance, approvals and governance. Epicor Mars extends that foundation with the EMS industry context needed at the point of work, including NPI execution and handover evidence.
That connection is directly relevant to Reworked Unit, Replaced Component: Does Your Build History Still Tell the Truth?. During NPI, repair and rework can change the as-built configuration. EMS genealogy should update component, operation, defect and repair history so the delivered unit record reflects what actually happened. When the Epicor Mars execution record stays tied to the Epicor work order, material and customer context, management can compare the business commitment with what the factory actually executed without maintaining a second source of truth.
For rework and repair genealogy, that complementary positioning is the point: Epicor remains the enterprise-grade foundation, while Epicor Mars adds the EMS workflows needed to make this particular control operational on the factory floor. Explore Epicor Mars for electronics manufacturing.
Frequently asked questions
Should every repair update genealogy?
Only to the level required by the product/customer traceability model, but controlled configuration changes should be reflected where relevant.
Is rework always a quality failure?
It is evidence of an abnormal path, but the cause may be design, material, process or handling.
Can repaired units ship?
That depends on product, customer and quality policy. The disposition should be controlled.
Why track removed components?
For high-traceability products, it can support investigation and complete repair history.