For many people, selecting and installing a warehouse management system (WMS) is a once, maybe twice, in a career decision. Unless of course you move companies often. But even then, the average lifespan of an installed WMS is about seven to 15 years—even longer in some vertical markets. In other words, this is an expensive, long-term decision that can often make or break a career.
Much has been written and showcased on the topic of selecting and implementing a new WMS. You can Google the topic and you will get approximately 99,700 results, varying in detail from supply chain vendor websites, published articles, and topics totally unrelated to what you were looking for. If you filter your results into a more manageable set of results, you will find varying opinions on the Top "X" number of factors/steps/keys to successfully choosing the right software vendor to satisfy your business goals. Good luck weeding through the reams of documented "what to do" and "what not to do."
Given this lack of experience, the information overload, and the criticality of the decision, it comes as no surprise that for many companies the vendor-selection process often ends up taking longer than anticipated. How do you make sure that your project takes off running and avoids being trapped in a system of "ready, set, delay"? After years of implementing countless systems, we have some advice on how to make the process flow smoother.
First, let's talk about what exactly is a warehouse management system. In the 1980s, the 1990s, and even the early 2000s, it was a pretty simple and straightforward explanation: "A WMS is a software solution, either home-grown or vendor-coded, that helps a distribution center receive, store, pick, pack, and ship goods to its customers in an efficient manner." Today, however, the topic can be (and often is) heavily debated.
To understand what I mean, take a look at the chart in Figure 1. All of the listed systems could be used to satisfy the requirements of a distribution operation, and many companies use more than one. Additionally, the lines between them are growing more and more blurred. Most enterprise resource planning (ERP) systems, for example, have some warehouse management functionality, while WMS solutions are expanding to include such capabilities as supply chain visibility. Similarly warehouse control systems (WCS) and warehouse execution systems (WES), which used to focus on controlling automated warehouse equipment, are now expanding into what have traditionally been seen as WMS functionality, such as inventory management and pick management.
Before beginning a software implementation for your distribution operations, you need to decide which of the software options are a fit for your future state supply chain execution solution. There are many great articles out there that describe each of these systems in detail and the differences among them. Do your homework and understand what functionality each of these systems provide. Don't assume that any single solution would be a complete fit for your project, or that any one software vendor could satisfy your overall requirements. In fact, it could be argued that each of these system options represent a clearly delineated best-of-breed solution. Finally, it should be mentioned that in virtually any project, there will be a whole host of integration needs and connectivity options among these systems.
Where to start?
Next I would suggest that you should look within your company to figure out if you have the wherewithal to take on a long-term, full-time project like a WMS implementation. Take into consideration your company's resource constraints, industry knowledge, and overall strategies, and then create a well thought-out, end-to-end plan to accomplish the overall goals.
Here are some high-level considerations that will need to be incorporated into your implementation plan and communicated to potential vendors:
Selecting your vendor
Here is where the rubber meets the road. You now have to go through the process of figuring out what options are available. (Fortunately, there are a bevy of options available; unfortunately, there are so many options that it is hard to know where to start.) There are different schools of thought on how to identify possible vendors. Do you look at the most recent Gartner Magic Quadrant for the top-ranked providers? Do you hit LinkedIn and poll your contacts for references? Do you go with a provider that has served you well in the past? Do you consider new and upcoming thought leaders? The answer to all of the above should be, "yes." Exhaust all your options, and take advantage of others' wins or losses.
Once you have figured out what options are available, create a request for proposal/request for quotation/request for information (RFP/RFQ/RFI or "RFX") that outlines and matches exactly what your short- and long-term goals and plans are. There are a variety of really good pre-written RFP/RFQ/RFIs available for free online that you can leverage as a starting point. But be sure to take the time to read them and cut out anything not relevant. (In other words, do not ask vendors whether their software supports RFID/serialization/garments on hangers if you have zero intent of ever deploying those functions.) And be sure to add line items that are missing and relevant. You should end up with a document that is succinct, meaningful, and can be leveraged in the upcoming phases of the project.
Once you have prepared your initial RFX, who do you engage? I would tell you from experience that if you initially engage more than five potential vendors, you are creating unnecessarily a whole bunch of extra work and expense.
Next, invite your initial pool of five vendors to your site(s) for a two- to three-hour tour, depending on the size and complexity of your operations. Give them a chance to visualize your operation, while you take the time to meet the people representing the company that you may be engaged with for a long time. While they are there, you should have a few things prepared: a short video or presentation of your company, what this project represents, and a tentative timeline of dates. (By the way, the vendor should cover the cost of this tour, not you.)
These tours serve many purposes. First, vendors cannot be expected to effectively answer a sophisticated RFP/RFQ/RFI without having seen where it will be deployed. Second, the questions asked and the information given by the vendors will give you an initial impression of what the implementation will involve and what it will be like to work with them. Third, these tours will decrease the chances that the implementation will be delayed at a later phase because of something you or the vendor didn't know.
After the visits you can hopefully qualify your top three choices. Any more than that is creating a whole lot of added time and effort on your side of the equation. Once you have decided on which vendors you want and have notified them, it's time to provide them with the final RFX along with the timeline that was already shared during the visit.
The final mile
From here, the heavy lifting starts as you move through the remaining steps and ultimately get to your preferred vendor. Outlined below are the high-level steps you might consider. If you are lucky, you might be able to narrow the field down to your final two before demo day.
"Go-See-Do": Visit no less than one current customer for each vendor still in the running. When you do so, make sure upfront that the customer you are visiting:
1) Is using the version of software that you are evaluating, hopefully a current version.
2) Is in an industry or operating environment that closely matches your own.
3) Understands that you are there to evaluate the vendor in all regards: software, infrastructure, and implementation. Let them know that you want to hear pros and cons as well as words of advice.
On-site vendor(s) demonstration: Finally it's time for your final two vendors to demonstrate their software at your site. Leverage the RFX as your starting point when creating the demo scripts. Why sit through a software demonstration of functions or processes that have nothing to do with your business model? Demos can last anywhere from a few hours to a couple of days. It's up to you how deep you want to go. In our experience, one day seems to work well. Again, if you have done your part, you should have a demo that closely matches what your end state looks like.
Now that you have hopefully whittled it down to a couple of vendors that you would be equally happy with, you have to think once again about the short and long-term goals that started this whole process and pick the one that's the best match.
A word about costs
By now you should know which vendor you want, and it's time to consider the license and implementation fees. At this point you need to consider questions such as: Do you want a subscription-based license or a perpetual license? Will you own the source code, and can you change it? Will the software be hosted or on-premise (or a combination)? What licensing options are available?
When it comes to choosing a licensing option, pricing is clearly a big consideration. This is an expensive proposition no matter how you slice it. As you begin the negotiation process, you should ask yourself the following:
Keep in mind that the vendor you are negotiating with likely does this day in and day out, so if you can dream it up, they have likely already "been there, done that."
License fee cost is only one side of the equation. Usually, the more expensive side of the equation is the implementation cost. As a rule of thumb, you should budget somewhere between 1.5X and 2X the prices of the license fee (in a perpetual license model) for implementation cost. Also find out whether you are negotiating a fixed fee, a "not to exceed" value, or "time and materials" cost structure. All of these have pluses and minuses depending on hundreds of variables.
Much of the implementation pricing depends on the complexity and duration of the proposed project. During the sales cycle, you will have likely heard something that sounded like, "We are usually a 90% fit 'out of the box' with no code modifications for most implementations." Take these statements with a grain of salt, however, as you will have modifications. How many will depend on a few factors; first and foremost being how willing are you to bend your processes and follow the vendor's guidance with regards to what they will call "best practices."
Once you think you have a good strategy for how to negotiate the implementation costs, build into your model/project plan some amount of "scope creep." It will happen, although how much is solely dependent on how well the project is being run.
After the contract is signed
As the project starts, there will be some initial growing pains. To limit the pain, you should formulate, with the help of the vendor, a very detailed and complex project plan. It is vital that all parties are in line with overall goals and expectations in order to satisfy the stakeholders. Below are a few helpful hints to keep in mind as the implementation progresses:
Choosing a new WMS can be an overwhelming and seemingly impossible task. The keys to getting it right are a solid, yet flexible, long-term plan. Do your homework, and remember that one size does not fit all. There is a solution out there that will meet your goals and expectations.