WMS Design Requirements: Make Use of “Tribal” Knowledge
How often have you needed to re-design a solution or change process flows during a Warehouse Management System (WMS) go-live? Was it because the system design was bad from the beginning? Did the process flows initially make sense, but ultimately, they didn’t match up with reality?
Of course, no implementation or go-live is perfect, but many things can be done early in the project to minimize issues. Remember the saying “Garbage in, Garbage out” (“GIGO”)? If the project starts with poorly defined requirements, then it likely will end up with poor results that can extend your timeline, dampen employee morale, and require costly rework and testing. What is the often-missed, critical component to developing accurate, on-target information needed to build effective requirements for a successful project?
Get Input from the Right People
From day one, ensure that you are using the best sources of information to develop the requirements. 
Integration requirements usually come from the appropriate sources: the IT staff that supports the host and other systems. Technical and integration requirements usually are accurate, because they come from the users of the system (the IT team) who know the ins/outs and needs/wants of how the systems “really” work.
On the other hand, functional requirements sometimes can fall into a grey area, and determining the right sources of input isn’t always clear. Who should provide input on the functional requirements? The short answer: the end-users. For functional WMS requirements, the best sources often are the warehouse associates: pickers, packers, inventory control staff, loaders/unloaders, cycle counters and the on-site operational staff at the facility. Of course, input from senior management (Director and/or VP of Operations) should carry weight as well, but their vision typically is assessing the entire operation and the associated metrics. Their vision should provide overall guidelines for the design, integration and output of the system, but they aren’t engaged in the daily “make it happen” operations on the floor. The functional and operational requirements should be driven by the users who will perform the activities every day.
There are numerous benefits of obtaining end-user input on processes and requirements. The most obvious is that designing a solution that will fit the end-user makes more sense than designing a solution based on what someone thinks will fit. Experienced associates know their jobs and are invaluable in giving a clear picture of what their day-to-day tasks entail and what nuances may arise. Their input is key to defining the processes in the facility that should be translated into the design of the solution.
For example, I once had a client who brought in their operations team to give feedback on their proposed processes. One of those processes was sorting during pre-receiving, during which the client wanted each case scanned to the pallet to which it was going to be sorted. But when the receiver who was experienced with these inbound pallets gave feedback, he said they were typically mixed-SKU pallets. He suggested pre-sorting the pallets and then performing scans for the appropriate tally to reduce the number of steps, thus reducing time and labor.
‘Tribal’ knowledge is real, and should be included during system design. Associates who have done their jobs for years naturally acquire a deep understanding of the role and pick up on trends and patterns that occur. A process that makes perfect sense on paper
may be completely unworkable in reality. A design process and the associated business requirements must accurately reflect reality on the floor, and this is the strength of tribal knowledge and input from experienced floor associates. Tribal knowledge covers many different areas, such as carrier preferences/patterns, picking/packing anomalies, international shipping constraints, and everything in between. It is important for a system designer to understand WHY users have adopted these important bits of knowledge, and integrate them into the design of the system.
Not only is user engagement important for system design, but it is also critical for achieving user buy-in during implementation. Users who have a hand in designing the solution feel more ownership of its success, and are more determined to make sure their design works well. Frequently, there is user push-back on solutions and processes during go-live. Forcing a poorly designed solution that was created without substantial user input often means it won’t work well, and the team’s attitude toward it will suffer. Team attitude during go-live can make or break an implementation, so keep the associates engaged and give them some ownership of the design.
There is considerable evidence of the benefits of having end-user input during the design process. Their input makes for a more realistic system design, more accurate business requirements, and stronger ownership of the final solution. People matter, and they need to know that their effort matters. By increasing end-user involvement and buy-in, there’s an increased likelihood of a smoother implementation and of driving productivity gains from the new WMS sooner rather than later.
