Consultants Forum Advertise
Subscribe
Close

  • Free for qualified executives and consultants to industry

  • Receive quarterly issues of Area Development Magazine and special market report and directory issues

Subscribe Now
Renew

Area Development - Site Selection, Facility Planning and Workforce Development

Logistics Distribution & Warehousing 2006: Computer-Managed Inventory

The route to supply-chain excellence often begins with a well-vetted warehouse management system.

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.


Exclusive Research