Warehouse Management

In Part 1 of this post I blogged about WMS implementation projects and the severe consequences of failure. What is the mantra for a sucessful WMS implementation? What makes a WMS implementation project a failure or a success? Here are some thoughts:

Build a Team for Success

A failed WMS project has organizational issues from its inception. The project team either does not have the authority to make decisions about the project or lacks the expertise in WMS and/or warehouse processes. Absence of executive sponsorship also hampers the project.

A successful WMS project gets the team building part right. This is the first critical step for a WMS implementation project. Most successful projects have an executive sponsor,  usually a key executive from the operational side of the business who has a stake in the success of the project. The executive involvement is necessary to get necessary resources, resolve conflicts as well as handle contingencies. Besides its also important to dedicate resources for important roles such as project manager, WMS experts and business champions. While the project manager could be an internal resource, it may be necessary to staff the WMS experts from outside. They could be either consultants or new employees who have successfully "been there and done that" elsewhere. However it's very important to staff this team with internal business champions. These are end users who have the trust and respect of the warehouse employs and is familiar with the warehouse environment. Chosen carefully they can act as powerful change agents. These are the people who will own the system after go-live when the consultants and contractors have departed.

Begin with the end in mind

A failed WMS project has the characteristics of old wine in a new bottle. People responsible for the project succumb to the natural tendency of implementing the new system the old way. The project team either lacks the foresight or has other agenda besides success of the project.

A successful WMS project team knows that gaining operational efficiency is after all the #1 reason for implementing WMS. Their approach is forward looking. The new WMS processes are designed after careful scrutiny of the current processes. The team looks out for inefficiencies in the current process and how WMS can help resolve it. A successful WMS implementation team does not rely on WMS features alone to deliver the benefits. While looking at software features is a good idea, it's also important to pay attention on things such as warehouse layout, warehouse storage policies, work assignments, resources and automation equipments, etc. WMS implementation project as an opportunity to get things right from the very beginning. This opportunity should not be squandered. A successful project also considers the future growth of the enterprise while designing processes today.

Manage Expectations

A failed WMS project starts with unrealistic expectations about the project. Other times these projects start with no clear-cut criteria for project success. Either way it's a recipe for failure.

A successful WMS project starts with manageable set of expectations. Most successful WMS projects start with modest goals. The project team does not oversell the benefits early on as it's so much better to underpromise and over deliver than the other way around. While some features may appear to be cool, it's important to rationalize if they are feasible for your warehouse. Do you have all the data that is needed, is the date accurate, what will be the impact on productivity if additional data input is needed, does the technological infrastructure exist to support the feature, how reliable is it?

Minimize Customization

A failed WMS project attempts to customize the product to suit its current processes. While customization itself is not a bad thing as many WMS projects need some degree of customization. It's the customization that works around the best practices ingrained in WMS or compromises the maintenance or upgrade aspects of the system that is bad.

A successful WMS project has minimal customization. A successful WMS project treats customization as the last resort. When nothing else such as change in processes or work around would be feasible. The customization is also carefully planned. Only the public APIs or Open interface tables are used. Customization is authorized only after a careful cost benefit analysis.

Document Everything

A failed WMS project has poor knowledge management policies. The warehouse policies, procedures and process are not documented while the project is on-going. When an important project member leaves the project, critical information about the project also walks out the door.

A successful WMS project treats documentation of procedures with utmost importance. Documents are prepared for warehouse processes and policies, configuration document, technical architecture, change management and patching policy and user training. These documents are formally assigned to project team members who are responsible for maintaining it.

Formulate a Change Management Policy

A failed WMS project does not have a well laid out change management and patching policy. Configuration changes and patches are often applied without testing. Worse the patching may occur with total disregard to warehouse schedules.

A successful WMS project has a 3 system approach. Changes are rolled from development instance to test instance for QA. Only after changes or patches pass muster are they rolled into production. A successful WMS project also looks at recommended patch list available on Metalink and applies these patches prior to go-live..

Do not underestimate Testing

A failed WMS project underestimates the importance of testing.

A successful WMS project tests the hell out of WMS before they go live. Any configuration changes such as profile options, rules changes are tested before they are rolled over to production environment. Successful WMS project also do a "day in the life" testing. This is a mock run of an actual go live environment. The testers are the end users themselves. This is a good way to test system stability, ability of the system to withstand volume, technical and network infrastructure. It also tells you if the end users are adequately trained in the system or just shooting the breeze.

Plan Adequately for Go-Live

A failed WMS project does not adequately plan for Go-Live. They either choose a wrong time to go-live, fail to anticipate problems and often start with incorrect inventories.

A successful WMS project diligently plans for the D-date by doing the following:

1. Go-Live Date:  It sets a realistic date for WMS go live. This is done well in advance. The go-live is usually scheduled on a weekend or a holiday (if its not a 24X7 operation). If the warehouse observes seasonal variations in demand, the go-live is scheduled during lean times

2. Facilities Planning: Physically mark your warehouse areas prior to go-live. Use barcode tags and mark the aisles prior to go-live.

3. Set help Desk: It's realistic to expect problems in the first few days. A help desk is setup to resolve these issues. The people manning the help desk are experts from the project team. They know if an issue is user/training issue or a configuration issue or a genuine technical issue for which a TAR needs to be opened.

4. Inform trading partners: It's essential to keep vendors, customers, carriers etc informed about your go-live schedules. This is all about managing expectations. That way any delays or changes will not come as a surprise to them. Its also a good idea to close all open transactions prior to go-live.

5. Perform physical inventory: With a new WMS, you want to start with a clean slate. You don't want your warehouse operators to distrust the system from day 1. Therefore go ahead and do a wall-to-wall physical inventory prior to go live.

6. Equipment Planning: Equipments such as handhelds, label printers, desktops are placed where they should be. Employees are trained to handle them, recharge them and troubleshoot basic issues. 

7. Contingency planning: If shit can happen, it will. Question is what will you do if it does? What are you going to do if network infrastructure is down? Handheld devices are not working? Carousel isn't spinning? System performance is abysmal? It's important to have a contingency plan. It could just be as simple as manual picking and shipping. Important thing is to be prepared for such an eventuality.

Continuous Improvement

A failed WMS project ends with go-live. The next project is initiated only when the current system is unstable, unusable or out of support.

A successful WMS project knows the importance of continuous improvement. Most successful WMS projects start with modest goals and continually refine their usage of WMS. They are up to date with patches and new WMS releases. Features are implemented and system is patched round the year.

Did I miss anything? Your thoughts are welcome.