No Pain, No Gain: WMS Implementation

Oct. 1, 2004
by Todd Lawson, project manager, Q4 LogisticsWhen working on the implementation of a warehouse management system (WMS), nothing beats experience. The

by Todd Lawson, project manager, Q4 Logistics

When working on the implementation of a warehouse management system (WMS), nothing beats experience. The only negative part of that concept is the pain that one has to go through to get that experience. So that you may avoid some of the grief, here are a few lessons that I have learned recently from some particularly painful implementations.

Lesson 1: You know what happens when you assume the details of package integration.

Integration between any two packages can be a tricky process. Specifically between a WMS and a host ERP, it can be downright treacherous. Rule #1: Never assume that packaged interface modules are everything the salesperson tells you. You are often well into the implementation when you finally roll back the covers and see what interfaces need to be modified or created. At this point, it is crucial that all parties involved focus on the effort required, avoid finger pointing, and make effective communications a priority.

On a recent project, integration work was being done by the software provider for their host system. Even though it was a critical path item, our progress on package integration was incredibly slow in the beginning -- in large part because of communication problems. The end user’s IT department insisted that all communication to their host system software provider go through them. This added avoidable delays to the process. Another issue was the fact that 3,000 miles and three time zones separated the parties working on the integration. The package integration effort made huge strides when it was decided that both parties (project team and host software provider) be in the same place working on the interfaces. Even though there were unexpected travel costs involved, a host software resource was brought to the West Coast facility and in a couple of weeks, more progress had been made than was accomplished in months.

Lesson 2: Don’t underestimate the value of field acceptance testing.

I was recently reminded about the value of extensive field acceptance testing (affectionately known by consultants as FAT). User acceptance testing (UAT) had been progressing with some mixed results. For example, test scripts needed to be rewritten, data set-up proved problematic, and our designated “super users” did not seem to be picking up a lot of knowledge. So the decision was made that only two rounds of UAT be conducted (instead of the originally planned three) and more emphasis be placed on starting FAT right away. This was successful and flushed out a lot of things that we would not have found with more UAT.

The FAT provided enough stress to the client’s network to highlight the fact that the additional load would start causing network problems. Earlier testing had already revealed a faulty core switch in their network. Also, the client wanted some assurance that reasonable throughput could be expected after go-live. So after the first few rounds of FAT, an additional round of "volume testing" (in reality another FAT) was conducted. In total, we conducted FAT five times, including the "volume testing." This testing not only validated expected throughput, but also provided a lot of practice for operators and served as a great training vehicle. To highlight the value of learning through hands-on testing, I remember an operator on another project who had been through two rounds of RF training in a classroom setting. When out on the floor to help with system testing, RF unit in hand, he looked up with a blank expression and said, "What do I do?".

Lesson 3: Use experienced project management resources to minimize risk.

All successful projects are based on realistic expectations. Even though acquiring that experienced project manager may be costly, he is worth his weight in gold to minimize risk to your business. An experienced project manager will realize that you really cannot apply a cookie-cutter approach to each project. Even though the WMS may be the same, and the integration resources are the same, you must understand that each implementation has its unique set of challenges. Also, his experience will allow your team to avoid the all-too-common landmines that exist as you move toward go-live.

Lesson 4: Look for opportunities to “slice and dice” the implementation to reduce risk.

A recent project was originally planned to go live with the whole facility all at once -- a risky venture under the best of circumstances. In the midst of the project, a decision was made to focus on the e-commerce fulfillment facility first; then attack the wholesale facility later. Now that the e-commerce facility has been launched successfully, we are planning on bringing up a portion of the wholesale business before the remaining portion -- once again, splitting the implementation to minimize risk to the business.

Hopefully these lessons will be of assistance to those of you who are setting out to implement a WMS. Learn from the mistakes of others. I’ve certainly learned from my own. As my dad used to say, “If a dog bites you once, it’s the dog’s fault; if a dog bites you twice, it’s your fault.”

Todd Lawson is an experienced project manager and systems implementer, with a specialization in warehouse management systems selection and implementation. He has a bachelor of science in industrial engineering from the University of Tennessee, Knoxville, and is a member of WERC. He can be reached at [email protected]