What a WMS audit actually inspects
Not a licence check and not a training day. A WMS audit is a comparison between configuration, logs, and the floor.
Operators sometimes book a ‘system audit’ expecting a vendor health-check: version numbers, unused modules, a slide about best practice. That is not what we do. A warehouse management system audit is a comparison. On one side: how the application is configured and what its jobs record. On the other: how receiving, putaway, picking, and counting actually happen between 7 a.m. and the last wave.
We start with the location master. Duplicate bin IDs, zones that were created for a layout that no longer exists, and coordinates that never matched the racking are ordinary. They are also how a directed putaway sends a pallet to a ghost. If supervisors already keep a printed map beside the RF screen, that map is evidence. We photograph it, then ask the system to produce the same picture.
Wave logic is next. Many Malaysian DCs still release work in a pattern that made sense at go-live and has not been revisited after a mezzanine, a new customer, or a night shift. We sit with the planner, watch a release, and then walk the floor with the same wave ID. Short picks, skip locations, and ‘pick from anywhere’ overrides tell us whether the system is directing labour or merely recording it after the fact.
Exception paths deserve their own hour. Damage, mis-label, catch-weight, and the override password that everyone knows — these are where inventory truth leaks. We ask to see the last thirty days of those events, not a demo script. If the vendor portal cannot export them, that limitation is written into the brief.
The deliverable is a findings document ordered by operational risk, not by module name. Each item names a screen or job, a floor observation, and a next action. We will walk it with your implementer if you want them in the room. We will not pretend a configuration change is a culture change, or the reverse.