Published June 20, 2004
With today’s emphasis on optimizing the supply chain, many warehouse management system (WMS) vendors have repositioned their packages as supply chain execution solutions. From an implementation perspective, adding “execution” to the product’s name invokes a certain degree of irony. The success or failure of a WMS implementation can dramatically affect a company’s bottom line and market share-not to mention the careers of the key staff involved.
This shouldn’t be surprising to anyone familiar with warehouse operations or WMS packages. A WMS tightly controls every aspect of a warehouse’s operation from receiving through shipping. A WMS that does not work within acceptable tolerance levels at “go-live” will keep a company from shipping product. You probably don’t have to go far to find a WMS horror story about an implementation that shut down a distribution center (DC) for weeks. More frequent examples are sub-performing implementations of warehouse output levels that are still well below pre-installation levels months later. The pain of these implementations may appear to lessen as time goes by and the system settles down. However, a considerable amount of money can be spent on fixing problems and a lot of customer goodwill can be lost before stability finally arrives.
Failure is not an inevitable outcome of a WMS implementation. Many implementations are completed successfully and some greatly exceed initial expectations. What determines success or failure? Certainly selecting the right package and vendors for the job as well as developing a sound, well-funded project plan are definite prerequisites for success. Still, these elements alone cannot guarantee an implementation’s success. In fact, much more is needed. Implementing a WMS involves numerous tasks that directly impact how people, product flow, procedures, equipment and information interact. While the details of these tasks vary between implementations, there are elements common to all implementations, and the success of any implementation hinges on how well an organization manages these elements.
1. Design for Operational Improvement
When an implementation starts to sour there is a natural tendency for a distribution operation to blame outsiders. This is understandable-much of an implementation appears to fall under the control of outside vendors, integrators and contractors, so any failure or shortcomings must be the fault of one of these outsiders, right? While a WMS implementation has many technical aspects, it is an operational exercise-its goals and objectives are operational. Many key activities are the direct responsibility of the business that is going to use the software. The ultimate fate of an implementation clearly lies in the hands of the organization that will benefit the most from its success-the end-user company. To have a successful implementation, an organization must pay attention to the operational and people sides of the implementation. This aspect of the implementation begins at project initiation and ends well after go-live.
All WMS implementations go through a design process or gap analysis where the business and operational requirements of the end-user company are matched up against the software package’s functionality. Improving operations is often the primary reason companies go through the expense of implementing a WMS. And, any operational improvement program is not going to work if it does not involve warehouse personnel.
During the implementation, there is a natural tendency to cede the design process to the software vendor. But a software vendor’s core competency is their product, not the warehousing function. The vendor’s job is to apply their software to meet customer operational requirements. They rely on the end-user company to define its needs. If this definition is not forthcoming or well developed, then vendors usually seek the simplest, most straightforward application of their technology.
Furthermore, any attempt to improve operations by concentrating only on software is going to produce very limited results. Operations is a holistic exercise involving people, equipment and procedures. Merely concentrating on software functionality will leave a wealth of potential improvements untapped.
2. Manage Risks
Unknown factors and human failings make risk a constant companion when implementing a WMS. While risk cannot be eliminated, it can be managed. The keys to successful risk management in a WMS implementation are the same as in most business projects-any good project manager would point to planning, knowledge, preparedness and communications as essential elements. But there is another factor that drives risk in a software project: complexity. Complex processes involve more variables, and more variables mean more potential failure points.
There is no canned solution for how much complexity to interject into a process. Each organization must weigh the potential risks against the gains. All aspects of the equation, from cost to customer satisfaction, must be considered.
3. Manage Communications and Expectations
Implementation is a people process. From top management to hourly floor personnel, an implementation must have support from all levels to succeed. Since an implementation involves organizational change, it can evoke uncertainty and anxiety. Employees may worry about losing their jobs. Supervisors may resist new ways of doing business. Management may have severe reservations about the investment they approved. If unchecked, these trepidations can sink an implementation even before it gets started.
Open communication is the best mechanism for combating negativity. Communication should start at the selection process and continue through go-live, and it should be well planned and carefully executed. This requires regular status meetings with key players as well as periodic sessions with other personnel. These sessions should encourage open, critical discussions and bring any underlying issues out into the open.
4. Develop a Solid Project Plan
Many organizations make the mistake of relying solely on the software vendor to develop and administer their project plan. Most end-user companies typically assign their own project manager to the implementation, but this internal project manager usually does not control or manage the project plan. Since an implementation is much more than a software project, “client” responsibilities such as facilities preparation, equipment acquisition, acceptance testing and end-user training need to be fully planned and tracked. The vendor does not know the intricacies of your operation-their focus is software. Unless the end-user company takes ultimate ownership of the planning process, many key tasks will suffer-they will not be fully planned, correctly staffed or properly executed. This doesn’t mean that the software vendor shouldn’t play a key role in plan development and administration. They know their product, implementation methodology and resource requirements. But the end-user organization should take final ownership of the master project plan that ties software implementation together with facilities preparation.
5. Prepare to Deal with Adversity
A WMS implementation is an extremely complex endeavor. No matter how well it is planned or executed, things may go wrong. Hardware may fail at a critical moment. Key people may quit at the most inconvenient times. Vendors may miss delivery dates. Key components may fail in production despite rigorous testing. The success of an implementation team hinges on how well it responds to adversity.
The most thorough and diligent project team cannot eliminate uncertainty and problems. However, a project plan with well-defined milestones and tasks will serve as the primary warning system that a project is in trouble. The project plan should be supplemented by contingency plans documenting the actions needed to respond to major problems and failure points.
More important than formal contingency plans is a responsive and flexible mindset, starting with the realization that uncertainty and problems are constant companions during most implementations. Problems can’t be solved through denial or managerial edict. Issues must be met head-on with clear direction and timely action.
6. Pay Attention to Facilities Preparation
Getting a facility ready for a WMS implementation is a lot of work. Even after accounting for the installation of any new material handling equipment, there are still numerous facilities preparation tasks that must be addressed. These include reconfiguring racks, labeling locations, re-warehousing product, delineating staging areas and installing workstations.
It is easy to lose track of these activities, as the physical aspects of the implementation sometimes seem secondary to computer-related tasks. Facilities preparation takes a great deal of planning, resources and management. Scrimping on any of these components is flirting with disaster. Quality and timeliness are also necessary for success. It doesn’t take a systems issue to halt an implementation. Bad bar code labels and improperly located product can cause failures.
7. Build a Knowledge Base and Take Ownership
Top-tier WMS packages are complicated mechanisms. They have enormous functionality driven by intricate configuration parameters. They can be very difficult to understand, let alone master. All this complexity can be a bit intimidating. Instead of embracing the system themselves, companies tend to leave the technical side to the vendor. At first glance this appears to be an equitable delegation-let the vendor and operations personnel do what they do best. But this line of thought is really a communication barrier that will prevent an implementation from reaching its full operational potential.
Furthermore, it is unrealistic to assume that the vendor will truly understand the intricacies of the warehouse and the company’s business environment. The end-user company must meet the vendor half way by learning enough about the package to ask intelligent questions during the implementation and to prepare itself to take ownership of the system after the vendor leaves.
The ownership process should start as soon as the contract is signed. Training courses and documentation are only part of the learning process. A fully functional test or training system is essential to provide key personnel the opportunity to work with the software without impacting production. This does not mean that people should attempt to master all aspects of the system. But key personnel should be encouraged to learn the intricacies of relevant functionality.
8. Institutionalize Training
Training is usually at the top of any critical activity list for a WMS implementation. Yet most implementations fall woefully short in this arena. Most WMS vendors employ a “train the trainer” approach. This means that they train key client personnel or “super users” on how to use the system to support their operation. It is up to the end-user company and these “trainers” to train all warehouse personnel.
A comprehensive, well-developed training program is essential to the success of an implementation. The cornerstone of any effective program is classroom instruction. Courses should be designed around specific job functions and utilize realistic, hands-on exercises that reflect the warehouse’s operating environment. Classes should be supplemented with job aids that not only assist the students with the exercises but can also be used on the floor to perform specific functions. Classroom instruction prepares people to meet the challenge and change involved in using a new system. But more is needed to maximize a workforce’s potential. A competency based development (CDB) program makes worker improvement an ingrained part of WMS implementation and operation. A CBD program combines skill-level classification and testing to rate an end-user’s competency in a particular job function. It provides a mechanism to encourage workers to improve their WMS and operational skills that will last long beyond go-live.
9. Understand the Value of Testing
A WMS package contains innumerable lines of programming code and configuration parameters. Software “bugs” and configurations issues can devastate an implementation. Even an operation that implements a base package without any modifications must test to validate their setup and configuration, and the ability of the system to meet their daily operational needs. Adding modifications and interfaces to the equation makes testing a critical success factor.
Testing helps validate that modifications, interfaces, configuration and base functions produce acceptable results and perform according to specifications. Software vendors test their products, but even the most rigorous vendor testing does not eliminate the need for the end-user company to thoroughly test its new software.
This additional level of testing must be more than a final check of the vendor’s quality control processes. It should validate that the software package, as configured for the operation, performs according to needs and specifications. These goals cannot be obtained unless the testing process is well planned and structured.
User acceptance test (UAT) and integration test scripts are essential components of any effective testing regime. A UAT script is a structured test plan designed for a specific system routine. It lists each step required to perform normal and exception activities documenting input requirements and expected results. UATs not only help ensure that the system operates as required, but their development aids in building a knowledge base about the package. Integration scripts evaluate the touch points between related system routines and interfaces to external systems such as an order management module or conveyor control system. Integration scripts address specific material and information flows that cross specific system functions. For example, an inbound integration script may test the processes and interfaces involved in shipment receipt from ASN download to putaway staging.
UAT and integration scripts are used to test the system in a controlled fashion typically running a small number of transactions through linear steps. While they are effective mechanisms for testing functionality and interfaces, they do not stress the system with production level processing loads. Volume testing addresses this need and can be accomplished through automated testing tools or manually by employing a sufficient number of testers to provide a near production transaction level.
Once a problem is discovered during a test cycle, any system options or interfaces affected by the resulting remedy should be re-tested. All testing should occur in an environment that mirrors production. Go-live does not eliminate the need for testing or a separate test environment. Configuration changes and code updates dictate that testing be an on-going part of any installation.
10. Plan for Exceptions
During an implementation, people naturally focus on major activities and routine job functions. They know how to pick a “normal” order or put away a “normal” pallet. They know how to perform the basic operations forward and backward. But they are generally unclear about what to do when an exception occurs. What should the picker do if the product is damaged? What steps should be taken to change the carrier on an order after it has been staged on the shipping dock?
Exceptions are like mishaps, they tend to occur at inappropriate times and in batches. They can prevent a major shipment from going out on time or tie up supervisors so that normal operations suffer. Exception handling must be an integral part of an implementation. Exception processing must be designed and tested from both a systems and an operational standpoint. It must then be incorporated into the training program. However, this isn’t enough. Exceptions by definition are infrequent. People won’t necessarily master them through practice. Exception handling should be documented and targeted toward key users and supervisors who can in turn instruct floor personnel on how to deal with specific situations.
11. Document Procedures
Although vendors provide users with manuals and configurations guides these documents deal with base functionality from a systems perspective and they usually don’t describe custom modifications. More importantly, they don’t describe what needs to be done from an operational perspective. There is more to receiving a shipment, running a wave and picking an order than simply entering data and scanning bar codes. Furthermore, implementing a WMS can generate completely manual procedures that must be done before or after systems related activities.
Training can help ensure that people know both the operational and systems steps required to perform a specific job function. But it is unrealistic to expect people to retain everything taught in training for as long as they are employed. There also is never enough time to fully teach every aspect of every job function. This is especially true about exception handling.
The limitations of training and vendor documentation should be rectified through the development of standard operation procedure (SOP) manuals. SOPs describe the operational and systems steps involved in each job function. They should be tailored to the way a facility operates using terminology and examples that will be familiar to prospective readers-managers, supervisors and other key users. Content should be developed with this audience in mind.
Ease-of-use and accessibility should play an important role in SOP development. Electronic delivery methods such as Web-based HTML or Windows-based help files should be investigated.
12. Take Control of Go-Live
Despite rigorous preparation and best intentions, things can still go wrong at go-live. Turning on the production system for the first time is the ultimate trial. While testing, hopefully, has shaken out most of the software bugs and configuration issues, there is no guarantee that problems won’t surface.
Problems and issues that surface at go-live must be dealt with promptly and effectively. Sufficient support personnel must be available during go-live week to deal with any potential issues. It means being able to handle multiple situations simultaneously. If there are not enough project team members to provide coverage, then additional personnel familiar with the process must be recruited. Chances are, support personnel will spend most of their time standing around waiting for something to happen. But during go-live it is definitely better to be safe than to be sorry.
Making it Work
The most essential element in a successful WMS implementation is hard work. This requires a considerable investment of the staff’s time to address all the operational, facilities, systems and training activities that must be successfully accomplished. Implementations that fail typically underestimate the magnitude of this investment. Many companies who have had failed implementations also made the false assumption that their own personnel can perform all the end-user company responsibilities without any effect on their regular job functions.
Some organizations have the internal resources necessary to successfully implement a WMS. Companies who don’t must either hire additional employees or partner with outsiders to fill the gaps. Going outside of the organization has the added advantage of increasing the breadth of experience that is directed toward implementation. While end-user company personnel know their own business and operation, they usually are not well versed in the ins and outs of WMS implementations.
Companies implement WMS packages because of the benefits they produce. They are cognizant that an investment must be made in order to realize the desired returns. But some shy away from investing the total amount required to succeed. Once costs are tallied up for all the required software and hardware, many organizations start looking elsewhere to hold the line on costs. Facilities preparation, testing, documentation and training all begin to seem like “accessories” they can’t afford.
But sometimes compromises are required. Budgets are certainly not unlimited. But decisions must be based on a clear understanding of what it takes to succeed. If budgetary compromises must be made, then all aspects of the project should be evaluated. Pouring money into the systems side, while starving the operational and people requirements, simply will not work.
Implementations can only be truly successful if the essential elements are properly addressed. Neglect risks either total failure or reduced performance. In either case, it will cost much more to fix problems afterwards. When it comes to a WMS implementation, it is definitely better to do it right the first time.
