Scoping: A vital initial step
A WMS deployment project represents a long-term investment. For this reason, it is not enough for the application to meet current warehouse and team requirements. It also needs to be able to adapt as these requirements evolve over time.
Selecting the right software is of course critically important (since this is what the organization will use on a daily basis). But the project scoping phase is just as crucial to the success of a WMS deployment project, because it ensures that the chosen application meets the company’s specific logistics, timing, and cost imperatives. At this step in the process, the project team models existing physical and data flows and processes, then assesses their efficiency and viability to determine whether they need changing or standardizing, in some cases benchmarking them against industry best practice.
This is also the point at which the organization considers the wider ecosystem of the logistics site(s) where the system will be deployed, focusing on three aspects: the business environment (such as suppliers, other warehouses, stores, shippers, and carriers), the IT environment (ERP system, TMS, e-commerce platform, etc.), and the industrial environment (conveyor, sorting stations, stacker cranes, pick-to-light system, order preparation robots, weight control system, and more).
In multi-location projects, the scoping phase is when the core model is defined—the common configuration that will be deployed across all sites and will require only minor adjustments in line with warehouse- or activity-specific characteristics.
Listening to logistics teams and managing change
Adjusting a WMS and integrating it into a company’s organizational, IT, and industrial environment is only part of the challenge. The success of any deployment project is also measured by how quickly and easily future users adopt the system. That’s why involving operations teams in the project scoping and design phases is so important. When deciding whether particular flows and processes need adjusting, their input is crucial—because they know better than anyone else what works and what needs changing, and where a move to a standardized approach would be welcome. In practice, this involves setting up a key user group and asking its members to define, test, and validate the target application across all processes: from incoming deliveries and storage, to order preparation and consignment.
By listening to and considering operational requirements, organizations can accurately define the functional scope of the project, thereby limiting the risk of schedule slip or overspend. But there are two important points to bear in mind. First, it’s often a good idea to speed up deployment by starting with an application that isn’t fully customized to operational requirements—to test the full capabilities of the new WMS first before adjusting it later. And second, deploying a new system always requires some degree of change management—communicating about the project, and training and assisting users of the new application in order to secure quick uptake and full buy-in.
Managing the project from end to end, including post-go-live
The all-important scoping phase is when the organization defines the technical and functional characteristics. But the project, which can run for several months, needs to be kept under review at every stage—design, development, acceptance testing, go-live, and subsequent stabilization—to make sure it remains consistent with the initial objectives. This requires end-to-end management and the involvement of key users at every step, including in the post-deployment phase.
In reality, however, companies organize their projects in one of two ways: some involve logistics warehouse managers and key users in the process alongside their routine duties, while others set up a project team solely for the initial deployment. In either case, the only way to continuously improve a WMS application is to have a dedicated structure and KPIs in place to monitor post-go-live performance—if only to take full advantage of its new features.
The importance of continuous improvement
Given the organizational, technical, operational, and human-resource implications of deploying a new WMS, the project will typically run for between six and eight months on average. This time can be reduced by implementing the predefined standard processes of the WMS, then adjusting them at a later date as part of a continuous improvement process. Moreover, this process is critical in more conventional deployment projects that include specific configurations.
No matter where the WMS is deployed, it will need to adapt so that it remains fit for purpose as the logistics site’s activities evolve. In other words, if new real-world needs and imperatives emerge, the first step is to review the WMS to see if it can cope as is. If not, new features will need to be added to the system—and a decision must be made on how to make best use of these features. All of these process steps have the same end goal: continuous improvement of logistics performance.
As part of a continuous improvement cycle, operators will require regular training and support for new processes and features. That way, the WMS and the processes it supports will keep pace with changing requirements, and the system will continue to serve its core purpose: increasing speed and efficiency so logistics teams can deliver on their customer promise.