Logistics Distribution & Warehousing 2006: Computer-Managed Inventory
The route to supply-chain excellence often begins with a well-vetted warehouse management system.
Dennis Gerard, TNT Logistics North America and Joe Vernon, ConAgra Foods (Logistics Distribution Warehousing 2006)
If you have decided to introduce a warehouse management system (WMS) to your business enterprise, the next question is: Where do we go from here? In the planning and execution of a WMS project, there are a few essential elements that you and the WMS vendor must co-manage.

Package/Vendor Selection
Selection of a WMS software package to help run your distribution center is more of a software vendor selection process. Depending on the level of complexity and the anticipated transaction volume, the top five WMS software packages can all deliver a good result. As such, choosing a partner is the more pivotal element in this process.

The WMS product sales cycle provides the first opportunity to feel out which vendor can most effectively function within your culture and manage to your expectations. Everyone will show you features and functions, but look at their personnel and ask challenging questions that stimulate ad-hoc conversation and a more in-depth, engaging interaction. Drawing out the professional and personal qualities of the vendor and relating them to your organization will make for a more dynamic and successful project experience.

Each WMS vendor will offer a choice of releases and versions. Some of these versions are stronger than others, and the differences are sometimes difficult to discern.

First, discuss with the vendor the finer points of these differences. Ask for a version-to-version comparison sheet that lists specific improvements and features that enhance the product's value to your business. Have the vendor spell out in writing which aspects of a certain release would be a good match for your business and which features may require modification. For those that require modification, have the vendor qualify the level of modification required as high, medium, or low. This language should make its way into the "Scope of Services" document under the heading Key Assumptions.

Second, score the version similarities in terms of general process flows, transaction volumes, user counts, and - most importantly - estimated hours of modification.

In the course of the above processes, attempt to ascertain the confidence level and capability of the vendor and its employees. Further, ask the vendor to support its claims with real-world examples of customers that shared a similar set of deliverables.

The success or failure of a launch is a shared responsibility. Since it is the WMS vendor's business to write contracts that allow for egress, apply due care in constructing contract addenda that closely link the vendor to your success or failure. Some vendors will even partner with you on ROI targets. Their willingness to do so provides a built-in hedge against the risk of poor product performance. The WMS must hit on all cylinders to allow for the operation to function as projected and hit the ROI targets, which are typically based on labor projections. Here is where you can construct a set of incentive-based deliverables.

Refer to the operational process, WMS product features, and ROI assumptions. These specific cost and delivery elements can be tied to incentives and written into the contract. An example of a WMS product feature is the ability to cross-dock product. If the vendor states that the WMS will allow you to cross-dock material as part of standard functionality, any costs incurred around implementing the cross-dock feature can be refuted or at least called into question.

For labor-based ROI assumptions, the WMS implementation can be pegged to a total operational labor FTE (full-time equivalent) projection. If WMS functionality does not effectively mesh with operational objectives or is less user-friendly than expected, more bodies may be required to get the product through the warehouse. The extra labor costs can be set out as a penalty against overall billing. System reliability and uptime can drive additional penalties as well.

Such a "pay for performance" approach lends itself to team-member bonus programs and greatly mitigates the risk of a budget bust and spoiled relationship. Both sides will be financially motivated to deliver.

One other effective way to hedge your selection process is to look for an offering that another company like yours has already implemented.

Project Timelines
To keep to schedule, generate a timeline with your vendor and ask for a commitment in writing to keep the project team together. Continuity is the key. Specifically name the resources in the agreement. Agree on an estimate of how much work there may be three to six months before going live. Explore some scenarios for slippage based on seasonality factors and your gut feel for "unknowns." Common timeline factors include holidays, vacation, physical inventories, scheduled shutdowns, and your overall enterprise change control mechanism. Larger IT groups may not allow for changes during all times of the year.

Add to the project timeline a period of several months after go-live and title it Stabilization. This will be your estimate of how long it will take for your organization to take control of the new WMS system. Include in this estimate a contingency for custom reports. The metrics derived from a WMS can lend themselves to operational improvements and strategic insights. Reports can easily generate 200-300 extra hours of development.

Even if you plan to take over the application 100 percent, keep the vendor team close at hand through stabilization.

Project Scope
Focus on what you need delivered at "go-live" and allow other things to come later. Think of it as leaving the top tier of the cake unfinished.

When users get their hands on the system and start to acclimate to how it really works, they will eliminate some of the prior requirements and introduce some new and better ways of doing things. This is especially true if you are handling product in a new way in a new building on a new system. That last 5-15 percent of functionality (most of which users think they need prior to go-live) has a tendency to over-complicate the project scope and generate code that can be obsolete within the first year.

Here is where you rely on the strength of the engineering and project leads to formulate a progressive solution as you tie the operation and WMS together. Allow the last bit of coding to be developed and executed after go-live. It will save you time and money and make your overall coding efforts more effective.

Customer-to-Vendor Communication
In a WMS relationship, it is important to create a conduit into the upper echelon of the vendor organization. Let them understand the importance of your project, match them up with someone on your side who is of similar stature, and arrange for periodic reviews. If allowed, the vendor will have a tendency to drop you off with a project manager and restrict your interaction with senior management.

Formalize a regular upper-management meeting every quarter. Strive to make these meetings substantive and avoid getting wrapped up in billing conversations. The periodic "across the table" reinforcement of expectations with decision makers on both sides leaves little room for push-back at critical junctures in the project when longer hours and extra resources may be required. These meetings and regular checkpoints can help set a tone for which circumstances might compel you to seek credits on billing for things not explicitly captured in the contract.

The Project Team
• Project lead and project engineer: Get the most intelligent, capable project leader and project engineer you can get your hands on. They will lay the foundation upon which your WMS solution will rest. The wrong people in these positions can literally cost you your company. Vendors can provide some good resources, but this is not necessarily their core competency or ultimate responsibility.

The engineer and the project lead must be smart, operations savvy, and have experience with some start-up/go-live pain. Scrutinize that aspect of their qualifications. Quantify how they have fared on prior projects against the following criteria: on time, on budget, and WMS performance in relation to client expectations. Did some of the design elements they introduced become part of the standard product? Did they play a role in avoiding wasted code, CRP surprises, modification rewrites, and - most importantly - go-live "grid-lock" scenarios?

• Rounding out the project team: Whether you use a company to help you implement the WMS (an advisable strategy) or do it yourself, be careful of people "cutting their teeth" on such a project.

WMS looks simple. Vendors can sometimes be motivated to give you the lowest-level person that they can make billable. Your job is to weed out those people. You can accept someone who is a little less experienced as long as you are also given a superstar and can negotiate a lower blended billing rate.

Your company will want to put some bodies on the project team as well. But use caution - there are subtle differences between staffing a WMS project and managing the business enterprise. The business community tends to believe that you can run your supply-chain project with the same personnel that run day-to-day operations. This misconception has brought many WMS and other system launches to their knees.

When putting together cross-functional teams, the project manager needs to be alert for other managers or the WMS vendor dumping the wrong people onto the team. Execute some form of a jury screening process. Individuals with a prejudice against change or a new system will undermine the project's ability to succeed. Avoid "last assignment"-type people with one year left before retirement unless they have the proper motivations and incentives. A good mixture of young, aggressive team members and some senior managers will normally provide the right balance of experience, urgency, curiosity, and optimism.

Work diligently to craft a closely knit fixed-cost solution for your organization. Licensing, professional service hours, project manager hours, training, and coding hours can come at you in a variety of creative ways; it is the essence of how software vendors make their margin. Attempt to understand and quantify all the hours and effort that will deliver 95 percent of the project, and then roll this up into a fixed-cost proposal. The 5 percent of the project left out of the fixed bid relates to the post go-live stabilization period.

Luckily, the modern-day WMS implementation rarely results in a meltdown. The points covered above are intended to lend themselves to a higher quality launch with minimal negative impact to your business. The customer, WMS vendor, and any third-party consultants are equal partners in the outcome. Like any good business venture, smart people, solid products, and strong leadership give you the best chance for success.

Dennis Gerard is director of operations services at TNT Logistics North America. He can be reached at (904) 928-1571. Joe Vernon is logistics project manager at ConAgra Foods. He can be reached at (402) 932-1464.