Pilot WIP tracking across real shop-floor handovers

A planner asks where an 80-piece job is. Machining reports 55 pieces transferred, inspection reports 55 received, and rework reports ten. Adding the reports suggests more than 80 pieces, although the physical job may be perfectly balanced. The reports count activity at different stages.

WIP tracking should reconstruct current state from controlled handovers. Operation totals remain useful, but they must not be confused with the number of physical pieces currently in each state.

Turn events into a current-state account

In this illustrative routing, 80 identified pieces begin in machining. Machining transfers 55 to inspection. Inspection sends ten of those to rework and releases ten to the next completed-work location. The current view is:

This example has no scrap or other loss. A real job needs separate approved loss, dispatch or other exit records so its starting population reconciles without forcing every piece into active WIP.

The transfer history still contains 55 machining handovers. It is not another 55 pieces to add to the current-state table. If the process permits splits, each child quantity must retain its parent job/batch relationship. When pieces combine or the unit changes, define the transformation rather than forcing simple conservation in an incompatible unit.

GS1's process description connects identification with capturing and sharing data along the physical flow. A WIP handover design can apply that principle using the factory's reviewed identifier scheme. GS1 traceability process.

One handover event produces one state change

Scroll horizontally to explore the full diagram, or open the text version below.

Read the complete workflow as text

1. Identified operation handover → Check event identity quantity and sequence
2. Check event identity quantity and sequence → Valid new event?
3. Valid new event? → Yes: Update exclusive current states
4. Valid new event? → Duplicate: Return prior result
5. Valid new event? → Missing predecessor or conflict: Supervisor reconciliation
6. Supervisor reconciliation → Check event identity quantity and sequence
7. Update exclusive current states → Reconcile physical job population

Choose one routing and a useful question

Pilot one shop-floor area and a routing with a real inspection or rework loop. The decision might be whether the planner can promise the next operation's start from confirmed WIP. Include event capture, reconciliation and an exception queue. Do not begin by connecting every machine.

Required inputs are released job and operation identities, routing version, quantity/unit, parent/child references, source/destination state, event time, capture time and recording system/person. Quality disposition must remain linked to the authorised quality record. Production completion is not automatically a quality release.

The operation owner confirms the handover. A supervisor resolves missing or contradictory events. Quality owns rework/release decisions, while the inventory owner approves any stock consequences. Give the planner read access to unresolved state rather than a fabricated best guess.

Design for a scan that arrives twice or too late

Use a stable event ID. If the 55-piece transfer is uploaded twice, the second upload should return the original result without another movement. A device-generated identifier must survive offline storage and retries.

If inspection arrives before machining's delayed transfer, retain the inconsistency for reconciliation. Do not create an unrecorded upstream event solely to make the screen look complete. Where the approved correction process allows reconstruction from evidence, record who authorised it and why.

Corrections should refer to the event being corrected and preserve history. A rework return must follow the actual approved route. Reject negative balances, impossible sequence changes or unit mismatches into an owned exception path instead of silently clamping the number to zero.

Compare capture choices against the work

A paper traveller may be adequate when jobs are few and handovers are reliable. Barcode/manual capture can provide event identity with limited equipment integration. Native manufacturing execution system (MES) functions may already represent the routing. Add an application only when the required reconciliation or user flow is missing.

AI may propose a reason category from an operator note. The quantity/state account should use deterministic, reviewable rules. Automatic machine signals need a reliable job association before they can describe WIP.

Prove the pilot during an imperfect shift

Baseline time to locate selected jobs, missing handovers, unexplained quantity and capture effort across representative shifts. Run shadow capture before enabling any stock posting. Compare the pilot with physical checks and approved source records, not only with another dashboard built from the same feed.

Test the 80-piece route with a split, duplicate upload, missed scan, offline device and rework return. Acceptance requires the current-state population to reconcile, duplicates to have no additional effect, and unresolved sequence gaps to remain visible with owners. Set operating improvement targets after measuring the baseline.

During outage, use the approved manual traveller or capture method. Preserve event identities, reconcile the queued records and resume in a controlled order. Do not discard unknown events to get the integration running again.

The pilot is valuable when a planner can locate work and understand uncertainty at the handover that matters. A high scan count is not the same as a trustworthy WIP account.

1. Define the routing boundary and the decision the planner needs to make.
2. Reconstruct one split/rework job from actual handovers.
3. Shadow capture through duplicate and offline recovery before expanding the area.

Discuss a WIP pilot with NextEdge Labs using your routing, current ERP/MES and the handover that repeatedly loses visibility.