What a mock recall is for
A mock recall is a rehearsal: you nominate a lot as though it were affected, trace it in both directions, and produce the records a real event would demand - usually against a clock.
Its purpose is not to prove your system works. It is to find the point where it does not, while the cost of finding out is a slightly awkward afternoon rather than a regulator, a customer, and a news cycle.
Choose the awkward lot, not the easy one
The most common way to waste the exercise is to pick a clean, recent, single-supplier lot that shipped to two customers. It will pass, and it will teach you nothing.
Pick something that stresses the system instead.
- A lot that went through rework, so a new lot was created from existing ones
- An input that was partially consumed across several production runs on different dates
- Material from a supplier you have since stopped using
- A lot old enough that the people who handled it have moved roles or left
- Something that moved between locations before being consumed
Trace in both directions
Backward tracing starts from a finished product and works back to the inputs and suppliers behind it. That is how you find a root cause and how you learn whether other products share the same suspect input.
Forward tracing starts from a suspect raw material lot and finds every batch and shipment it reached. That is how you scope the recall. Many exercises only run one direction, which means half the capability is never tested.
What to measure
Time is the headline number, but on its own it hides the interesting detail. Record where the time went and how confident you are in the answer.
- Elapsed time from nominating the lot to a defensible list of affected product
- How much of that time was retrieval versus reconstruction from memory or paper
- How many separate systems or people were needed
- Quantity reconciliation - does what you made, hold, and shipped add up
- Whether the scope narrowed as you learned more, or stayed defensively broad
The failure patterns worth looking for
Across most operations the same handful of breaks recur, and they are process problems rather than software ones.
- The trail ends at a paper receiving log that was never entered anywhere searchable
- A transformation step recorded output quantity but not which input lots produced it
- Rework created a lot with no link to what it was reworked from
- Partial containers returned to stock lost their original identity
- Two systems disagree on quantity and nobody can explain which is right
Do it again
A mock recall run once a year, always on the same easy product, is theatre. Rotating the scenario and running it more often turns it into a genuine measure - and the trend matters more than any single result.
If the scope of what you would have to withdraw shrinks over time, your lot records are getting more precise. That is worth real money on the day it counts.