When a WMS project is required
- A warehouse is being built, automated or reorganised.
- The existing system no longer supports process and performance needs.
- ERP, WMS, WCS and automation responsibilities are unclear.
- Several vendors must be compared on the same requirements.
- A rollout or migration needs controlled testing and cutover.
Processes before software functions
Receiving, put-away, replenishment, picking, packing, shipping, inventory, returns and exceptions are defined before requirements are assigned to systems. Functional messages such as expected receipt, confirmation, provision order, execution report and master-data change are separated from the technical protocol.
Approach
- Define target processes, roles and performance requirements.
- Map ERP, WMS, WCS, equipment and peripheral systems.
- Create testable functional and non-functional requirements.
- Compare solutions and suppliers using a weighted model.
- Specify interfaces, migration, testing and acceptance.
- Prepare cutover, training, support and stabilisation.
Results and deliverables
- Target process map and system boundary
- Vendor-neutral requirement specification
- Interface and master-data catalogue
- System and supplier comparison
- Test, migration, cutover and acceptance plan
- Implementation roadmap and governance
Technical basis and limitations
The functional interface is described independently of its transmission protocol. It covers expected and confirmed receipts, provision orders, execution confirmations, master data, performance data, exception handling and reconciliation. This distinction follows VDI 3969 and is extended with current API, event and security requirements.
The requirement specification states what the client needs and why; the system specification states how and with what the supplier will realise it. The current VDI/VDE 3694:2014-04 is being revised. The announced project is therefore not presented as an already valid replacement. Further reading: creating a WMS requirement specification.