It’s time to develop requirements for a software acquisition project. “Everyone knows what we need, right?” If only that were true. The fallacy of this assumption is that even if everyone knows what’s needed, putting it on paper reveals multiple meanings for terms and concepts. Requirements development, like training, is a frequent stepchild of WMS software acquisitions projects. Although necessary, these activities are the first items to have their resources and support cut if budgets are reduced or the project gets behind schedule.
A specification document provides an excellent compass for vendors and project managers. This document should define what the system will be able to do in language plain enough to be readily understood by a reader familiar with distribution operations (i.e., a user). It also needs to encompass strategic considerations and to provide potential suppliers with sufficient detail to elicit a meaningful response.
Strategy
There are several kinds of strategic factors to consider:
Planning horizon
Requirements definitions should address the needs of an organization for a minimum of five years. Recent technological advances have helped justify replacing or upgrading major systems with greater frequency than in the past, and all indications are that this trend will continue for the foreseeable future.
Return on investment
Requirements should support implementation of a solution that can be readily justified from a return-on-investment standpoint. Defining requirements properly makes it easier to estimate the cost of a solution and to increase the odds of having a capital request approved. The ROI for a major WMS implementation will typically range from 12 to 24 months, depending upon the scope and size of the project.
External considerations
External factors can also have strategic implications. Take the case of an existing system, however satisfactory, that is scheduled to have vendor support terminated. The requirements definition in this instance may need to include an interim solution. Achieving short-term goals can be difficult, and this usually involves modifications to existing software or the use of generic software tools, scenarios that are frequently the breeding ground for major cost overruns and scope creep.
Specific strategic objectives
A WMS application is a mission-critical tool for many organizations. To illustrate, one common strategic objective is to provide same-day shipping to customers. This may require allocation and shipment of inventory for a single order from multiple locations and the generation of a single invoice. Accomplishing this objective will require specific capabilities of several kinds from the warehouse management system. And those are just some of the strategic factors. There are also tactical considerations to be addressed.
Tactics
Important tactical issues fall into several categories based on the knowledge and experience of the system users, in this case operations executives and, indirectly, the constituents of operations in other parts of the organization. As is usually the case, the project team will benefit from including members of other divisions of the company.
What users know they need now
In some ways this is the easiest portion of the requirements development process. Users know the software currently in place, and they also know what is difficult or impossible to do with the current system and what kinds of customer requirements create problems.
Operational requirements developed as part of the early process mapping and operational analysis phase of a project will provide guideposts for developing software system requirements. You will need to define clearly those functions that require support from a software application, such as workload planning or batch-picking optimization.
What users know they will need
Users can often provide good input on future needs and trends in customer requirements. Documentation of perceived issues, problems, and trends can provide an excellent foundation for developing large portions of the requirements document. One example might be an expectation that more customers will expect to cross-dock product in their own facilities. For that reason, operations will need to provide shipments suitably marked to accommodate multiple customers’ cross-dock labeling requirements. In another instance, orders may be forecast to arrive later than usual and to be modified right up to the time they are loaded onto an outbound truck. This will require the WMS to handle order changes farther into the fulfillment cycle than may be possible using the current application.
What users may not know — best practices
With the exception of members of organizations with large staffs or unusually well-trained operators, most team members will not be familiar with the tactics, strategies, and methodology of many other operations. To supplement this lack of familiarity, you will need to incorporate “best of breed” and other best practices into the requirements to gain as much competitive advantage as possible. In aggregate these items can have enormous consequences for workflow, process cycle times, inventory productivity, and operational costs. Best practices can encompass things as large in scope as replenishment strategies and things as small as the amount of information displayed at any one time on a picker’s RF device.
What users may not know — technology and innovation
The extent of users’ knowledge of the state of technology in the industry is especially important, and it argues strongly for the presence of IT resources on the requirements team. IT input is most valuable in such areas as hardware platforms, compatibility and integration issues, software tools for data handling, and vendor/product development and enhancement strategies.
As WMS software and applications become more mature and easier to configure, it has become less of a challenge to optimize operations. This means being able to support preferred methods of running the distribution operation rather than having to design processes that match software functionality. Operations executives typically are fairly conversant with the technological aspects of distribution and fulfillment. However, knowing what’s possible (and users may not) can significantly change the outcome of a selection process for the better.
Start early
The “best” approach to the process of defining WMS software requirements will vary, depending on the internal knowledge and experience of the user group. There are, however, a number of general statements that are applicable regardless of the context or the nature of the user organization.
First, there is no substitute for an educated user. The more exposure users have to different aspects of the process, the higher the potential for a successful project.
Second, checklist tools, detailed functional capabilities lists, and other materials are available that can certainly aid in developing a useful requirements document.
Third, where expertise is lacking (or even when it is available), it is often a sound investment to add outside help to the team for the duration of the project. Software consultants can lend valuable input and methods to every stage of the project, if only to confirm conclusions and recommendations as they evolve.
Finally, start early. This process may well take longer than anticipated, but extra time spent will pay a handsome dividend.
Ron Hounsell is vice president of software solutions at Tom Zosel Associates, a distribution and logistics consulting firm based in Long Grove, IL. He can be reached by e-mail at [email protected], by phone at (847) 540-6543, and by fax at (847) 540-9988.