Most manufacturers discover the true state of their traceability during a recall, which is the worst possible moment to find out. The question that arrives is narrow and unforgiving: which customers received product containing this batch of material, and can you prove it. Everything else about the system becomes irrelevant for the duration of the answer.
This article walks through what a recall actually asks of your records, why spreadsheet-based traceability tends to fail under that pressure, and what a workable setup looks like in a small manufacturing business.
What a recall actually demands
A recall requires two directions of travel through your data, and most systems handle only one of them well. Backward traceability answers what went into a given unit, which is the direction a quality investigation runs. Forward traceability answers where a given batch ended up, which is the direction a recall runs. If you can only walk backward, you can explain a failure but you cannot contain it.
The scope question follows immediately afterwards. A supplier notifies you that a batch delivered eight months ago was out of specification, and you need to establish how many of your finished units contain it, which customers hold them, and whether any remain in your own stock. Regulators and large customers generally expect that answer in hours rather than weeks, and the gap between those two timescales is usually the gap between a contained incident and a serious one.
Why spreadsheets fail at exactly this point
Spreadsheet traceability normally works, right up until the moment it is tested properly. The failure is rarely that records are missing. It is that the records exist in several places and were never designed to be joined. Goods-in is logged in one sheet, production in another, despatch in a third, and the link between them is a part number rather than a batch. A part number tells you what the item was. It does not tell you which delivery of it went into which job.
The second failure is that batch identity is captured at the wrong moment. If the batch number is written down when someone has time rather than when the pallet arrives, the record reflects what a person remembered rather than what happened. Any traceability system that depends on retrospective data entry will produce confident, incorrect answers under pressure.
What a working setup looks like
The mechanics are less complicated than the reputation of the subject suggests. Capture the supplier batch at the point of receipt, before the stock is put away, because that is the only moment when the information is both available and unambiguous. Consume against that batch when material is issued to a works order, so the link between raw material and output is created by the act of doing the work rather than by a separate administrative step. Carry the resulting batch through to the delivery note, so the outbound record identifies what was actually sent.
Done that way, the forward and backward views are simply two readings of the same chain, and neither requires reconstruction. The recall question becomes a query rather than an investigation.
A test worth running before you need it
Pick a batch of raw material received in the last six months and give yourself an hour to establish, from records alone, every customer who received product containing it. Do not allow anyone to fill gaps from memory, because memory will not be available during an actual recall and its presence during the rehearsal will hide the problem you are looking for.
- Identify the batch and the date it was received.
- List every works order that consumed it.
- List every finished unit or batch those orders produced.
- List every despatch containing those units, and the customer on each.
- Note how long it took, and which steps required somebody to remember something.
The final step matters more than the total time. Every point where a person supplied information that the records did not contain is a point where the system will fail when that person is unavailable.
Where the software fits
Brytebuild captures lot and batch identity at goods-in and carries it through consumption, production and despatch, so the genealogy is built as a by-product of normal work rather than as a separate exercise. The same records support quality investigations, customer questions and, if you export to the EU, the product data that a digital product passport draws on.
You can read more about how that works in our guide to lot numbers in UK manufacturing, or see the sector-specific version on the food and drink and electronics assembly pages.