Don’t Start with the WMS

It is understandable, therefore, that a WMS project often begins with the technology. Businesses research available systems, invite providers to demonstrate their software and begin compiling lists of functions they would like the new WMS to provide.

That may appear to be the logical starting point, but it risks approaching the decision in the wrong order.

Before considering which warehouse management system to select, a business needs to understand how its warehouse should operate, what decisions the system must support and what information will be required to make those decisions. Without that foundation, the selection process can become driven by software functionality rather than operational requirements.

A successful WMS project should therefore begin with the warehouse, not the WMS.

Understand the operation before specifying the system

A warehouse management system does not operate independently of the warehouse. It supports the processes through which goods are received, identified, stored, replenished, picked, packed and dispatched.

The first stage of a WMS project should consequently be to understand those processes and the operational requirements behind them.

That means examining questions such as:

• How should goods be received, checked and made available?
• What information is needed to identify and control inventory?
• How should storage locations be selected?
• What should trigger replenishment?
• How should work be allocated and prioritised?
• What information do operators need at each stage?
• Which decisions should be automated?
• Which exceptions require intervention?
• How should inventory accuracy be maintained?
• What needs to happen before an order can be dispatched?

These questions establish what the operation needs to achieve. Only once the requirements are understood is it possible to assess how effectively a proposed WMS can support them.

Without this work, a business may still be able to select a capable system. What it cannot know with confidence is whether it has selected the right system for the operation.

Features and requirements are not the same thing

Software demonstrations are designed to present a system at its best. They can introduce useful ideas and reveal capabilities a business had not previously considered. However, they can also begin to shape the requirement before the requirement has been independently defined.

A feature appears useful, so it is added to the specification. Another provider demonstrates a different function, which is then added as well. Over time, the specification can become a collection of attractive software capabilities rather than a considered description of how the warehouse needs to operate.

This is where it is important to distinguish between a feature and a requirement.

A feature describes something a system can do. A requirement describes something the operation needs to achieve.

The requirement might be to prevent stock from being allocated before a quality-control process has been completed. Different systems may satisfy that requirement in different ways. The purpose of the specification is not necessarily to prescribe the software mechanism, but to make the operational outcome clear enough for each provider to explain how its system would deliver it.

That produces a more meaningful evaluation. Instead of asking providers to demonstrate everything their systems can do, the business can ask each provider to show how the proposed solution would support the warehouse’s defined requirements.

Do not simply reproduce the existing warehouse

Understanding the current operation does not mean documenting every existing process and requiring the new WMS to replicate it.

Some processes may have developed because of limitations in the current system. Others may depend on spreadsheets, manual records or the knowledge of individual employees. A process may be familiar and well established without necessarily being the best way of working.

The specification process should therefore examine both the current operation and the required future operation.

It should distinguish between processes that need to be retained, processes that should be improved and activities that may no longer be necessary once better information or system functionality is available.

This is particularly important where the business expects growth, operational change, automation or a different service model. A WMS selected solely around today’s processes may become a constraint as the operation develops.

The aim is not to digitise the warehouse exactly as it currently works. It is to establish how the warehouse should work and define the role the WMS will play within it.

Consider the wider system environment

A WMS rarely operates in isolation. It may need to exchange information with an ERP platform, order-management system, transport management system, e-commerce platform, automation controls or customer and supplier systems.

Those interactions need to be considered as part of the operational requirement rather than treated as a separate technical exercise.

For example, it is not enough to state that the WMS must integrate with a transport management system. The business needs to understand what information must pass between the systems, at what point in the process it is needed and what operational decision or activity that information enables.

The same principle applies to warehouse automation. The WMS, warehouse control system and physical equipment must support a coherent operational process. Selecting the software and equipment independently can create gaps, duplicated logic or uncertainty about which system controls particular decisions.

The requirement should connect the process, the information and the technology.

Use the requirement to evaluate potential systems

Once the operational and functional requirements have been defined, the WMS market can be approached on a much stronger basis.

Providers can be asked to demonstrate how their systems would meet specific requirements using relevant warehouse scenarios and data. Differences between proposed solutions become easier to identify because each system is being assessed against the same operational needs.

This approach also helps the business distinguish between genuine gaps and differences in how systems work. One WMS may satisfy a requirement through standard functionality, another through configuration and a third through additional development. Those distinctions can affect cost, implementation risk, support and the ability to adapt the system later.

The objective is not simply to identify whether a provider can say yes to a requirement. It is to understand how the proposed solution would deliver it and what that means for the operation.

Carry the requirement through implementation

The requirements developed for selection should continue to guide configuration, testing and implementation.

During a project, individual decisions can gradually move the solution away from its original purpose. A requirement may be interpreted differently during configuration, a proposed process may become more complicated than expected or functionality may not work operationally in the way it appeared to during selection.

The specification provides a reference point throughout that process.

It allows the business to ask whether each requirement has been configured, whether it has been adequately tested and whether the resulting process works in practice. It also creates a more useful basis for user acceptance testing because tests can be built around genuine operational scenarios rather than isolated system functions.

A specification should not be produced solely to help select a WMS. It should provide continuity from the initial operational requirement through to the implemented solution.

Start with the warehouse, not the WMS

There are many capable warehouse management systems available, and there may be several that could support a particular operation. The challenge is not simply to find a good system. It is to identify the system that best fits the business’s requirements and to implement it in a way that supports the intended operation.

That cannot be established from generic demonstrations or long lists of functionality alone.

The business first needs to understand how the warehouse should operate, what decisions the system must support, what information is required and how the WMS will interact with the wider technology environment. Those requirements can then provide the basis for system evaluation, selection, configuration and testing.

The conclusion is straightforward: a WMS project should not begin by asking which system to buy.

It should begin by defining the warehouse operation that the system needs to support.