We have seen WMS implementations so disconnected from the way the business is actually operated, that staff members refuse to use the system and revert back to their paper-based ways of getting things done. This is not only a significant waste of a significant investment by the company but does nothing to decrease the risk or increase the competitiveness that the WMS implementation was intended to address.
To avoid this type of disconnect, a few fundamentals should be considered before making a decision on which type of WMS would be most suitable to deliver on the promises made by a supplier. Understand more than just your area of responsibilityWarehousing is part of a larger chain of events, and the more you understand the larger supply chain, the better recommendations you can make to others on how the whole chain can work together to meet changing customer demands. Understand the difference between exciting features and real business purpose
It’s very easy to get sidetracked by a large list of features once you start investigating WMS, but be warned. A WMS should be built around processes that already work optimally. Processes should not be changed or created just to accommodate a system feature that is often not as robust as marketing material may make it seem. The decision on a WMS should be made based on an understanding of the business purpose; the true value the business wants to deliver to its customers. Understand that it’s about slow and steady, not rushed and ready
The real-time nature of warehouse operations demands that a new WMS disrupts normal business as little as possible. This is only possible if all stakeholders in the WMS project team understands that rushing the initial planning process, and skimping on dry-run tests, almost always guarantees a problematic or even catastrophic implementation. Make sure time and budget are made available for running tests throughout the project based on one version of the truth which is established and maintained on a live, cloud-based, collaborative, platform. Testing at the end of a WMS implementation project based on static documents that were created at the beginning of a project causes problems based on a disconnect between the greater business processes, what the business is doing, and what the system is supposed to do. *Hein Pretorius, CEO and founder of Onpro Consulting