RFID and WMS integration: why working hardware still produces bad records

01 / FIELD NOTE

Keep the decision tied to the operating context.

An integration that fails usually does so with the hardware working. The readers are installed, the tags respond, the network is up, and the warehouse system is the same one that ran the operation before. What does not work is the translation between them, and that failure is easy to misdiagnose as a device problem because the devices are the visible part.

The root of it is that the two systems describe different things. A reader reports that a tag was observed in its field, repeatedly, for as long as it remained there, along with every other tag it could hear. A warehouse system acts on business events: a receipt, a put-away, a transfer, a pick, a dispatch. Presence is not an event, and the distance between them is where the design work lives.

The first failure mode is posting reads directly. Sending raw observations into the warehouse system produces duplicate transactions, movements attributed to the wrong step, and an audit trail that cannot be trusted. The symptom that usually surfaces first is the same pallet appearing to be processed more than once, which is the reader doing its job and the integration not doing its.

The remedy is a layer that decides. Filtering removes duplicates and applies a rule for how long a tag must be absent before it can be counted again. Time windows separate separate crossings from one continuous presence. Read-zone rules decide which reads are eligible to become events at all. Mapping assigns each eligible read to a specific business step. Only then does something reach the warehouse system, and it is a decision rather than an observation.

The second failure mode is a mismatch between what is tagged and what the system models. A tag may identify an individual unit, a carton, a pallet or a returnable container, and the warehouse system may be organised around product codes, storage locations, lot control or dispatch units. If the relationship between the two is undefined, the hardware performs correctly and no useful transaction results, because nothing has said what the read means.

That mapping has to be settled before deployment rather than during it. What each tag represents, at what level tagging happens, how the identifier in the tag connects to a record in the warehouse system, and where serialisation is genuinely needed rather than merely possible. Projects that begin with reader installation and leave this question open tend to discover it in production.

The third failure mode is volume. A reader can produce more observations in a minute than a warehouse system should be asked to store in a day. Pushing all of them in creates an event history too large to read, exception review that takes too long, and a signal-to-noise problem for the people expected to act on it. Raw observation history and business transaction history are different records with different retention needs, and keeping them separate is what makes both usable.

The fourth is that live conditions do not match the test. Metal racking, liquid contents, dense pallet storage, traffic through the read zone, overlapping coverage between neighbouring points. A portal validated in an empty aisle can behave differently once the aisle is full. This is not an integration fault, but it presents as one because the read that never arrived looks like a transaction that was never created.

The fifth failure mode is an exception path that does not exist. Some tags will not read, some shipments will not match, some items will be in the wrong place. If there is no defined handling for those cases, staff invent one, and the invented version happens outside the system. That is the point at which traceability stops, and it is usually invisible in the project documentation because nothing failed to work.

The sixth is that the process was never redesigned. Adding automated capture to a workflow built around manual scanning leaves the manual steps in place and the benefit unrealised — staff still stop and verify items individually at a point where the system could have confirmed the movement by itself. The hardware change is the smaller part of the work; the workflow change is what produces the result.

The seventh is trust, which is a failure mode rather than a symptom. Once supervisors believe the data is inconsistent, they reintroduce the checks the system was meant to replace: a manual recount, a spreadsheet, an extra scan. The system is still running and still costing what it cost, and the operation has reverted. Trust is built by predictable behaviour and visible exceptions, not by the absence of manual work.

The questions worth answering before starting are therefore not about hardware. What does each tag represent in the workflow. At what level will tagging happen. How will duplicate reads be filtered. What happens when a tag cannot be read or an unexpected item appears. Which single workflow will be piloted first, and what will be measured. A project that can answer those has designed the integration; one that cannot has bought readers.