Turned warehouse requirements into a consolidated WMS workflow
Completed one week before the Christmas peak, reducing cross-referencing and allowing one operator to handle work that previously required two.
The project started after I heard repeated frustration about having to check three different WMS tables to confirm inventory information. Experienced staff knew which values to compare and where to look, but the process was difficult for newer staff to learn and easy to get wrong.
I translated that operational problem into a technical specification for the WMS software developer. I mapped how the three tables related, identified the fields and calculations needed from each, defined filtering and edge-case behaviour, and described how they should be combined into one reliable operational view.
I translated staff and management needs into technical requirements, worked with the WMS software developer during implementation, and validated the finished workflow.
Staff could describe the warehouse problem, but the software needed precise rules for what data mattered, how the fields related, what should be calculated, and what should appear in the final view.
I had to identify which fields across the three WMS tables affected replenishment accuracy and efficiency, how those values depended on one another, and which calculations, filters and edge cases were required for a reliable combined view.
The solution needed to be defined, implemented and checked within roughly one week before the Christmas peak. That made it important to keep the requirements clear, validate the calculations carefully, and make sure the new view was reliable before staff depended on it.
After the new report went live, some items that still needed to be replenished were present in the old report but missing from the new combined view.
I asked staff to stop relying on the new report and return to the existing report while the issue was investigated.
I used the old report as the reference point and compared it against the new view, collecting rows that were missing or returning incorrect values.
Once I confirmed the issue was repeatable, I contacted the WMS software developer immediately rather than waiting until I knew the exact cause.
Without access to the underlying implementation, I considered several possibilities, including incorrect implementation of the specified logic, missing data inputs, or incorrect handling of calculated values.
While waiting for a response, I compared affected and unaffected rows, looking for repeated values, unusual fields, or any common characteristic that could explain the failures.
The strongest pattern was that the missing rows shared the same date. I passed that observation to the software developer as a possible clue that the report was not recalculating correctly as the source data changed.
The software developer used that information during their investigation and identified the implementation issue.
I reviewed the available WMS reports to determine which data was actually needed for replenishment. Some information overlapped across reports, so I narrowed the workflow down to three main tables and identified the fields required for the combined view.
I mapped the relationships between those fields, defined new calculated values where the existing reports did not provide what staff needed, and specified which information should appear in the final operational view.
Before implementation, I documented the calculations, filtering behaviour, edge cases and expected outputs so the WMS software developer had clear rules to build and validate against.
For example, stock already moved into replenishment locations should reduce the remaining quantity shown to staff, and rows with nothing left to replenish should no longer appear in the view.
The full specification includes the calculations, filtering rules, edge cases, example data and post-deployment validation.
View Technical ReportNote: This report represents only part of the implementation documentation; additional project reports and follow-up communication were handled through ECHT management.
The goal was to turn three separate WMS views into one reliable replenishment workflow, making customer-item retrieval faster and more accurate while reducing a process that typically required both a computer operator and forklift operator into something one person could coordinate.
Replenishment errors could leave pick locations empty, delay customer orders, and create backlog for the following day. During the Christmas peak, mistakes late in the week could also carry into Monday, increasing labour pressure and sometimes requiring additional casual staff to recover.
Additional verification is available on request, including direct correspondence from ECHT management.