Is there a unicorn in your warehouse?

We are frequently asked “What’s the key to a smooth WMS implementation?” Well, there are no silver bullets and a smooth implementation of any software application, especially a warehouse management system (WMS), may be a unicorn. After all, each implementation is different due to requirements based on the industry, commodities, facility, and specifically business objectives.

Though the ultimate objective is to make the system go live in the DC and improve efficiencies operationally and system wise, many projects fail due to lack of clear communication, scope creep, budgetary issues and extension of project timeline name a few shortfalls. There are certain things, however, that you can pre-empt to reduce the problems that could occur if not addressed immediately. In the following guide, we aim to do just that in the exact sequence of a normal WMS implementation.

Secure buy-in from all stakeholders

When you commence a WMS implementation, it is crucial to involve all stakeholders, including business operations, finance, IT, infrastructure, system integrators and even material handling equipment vendors if applicable. It is most critical to involve the transportation and logistics team and other related teams that directly interface with the DC (customer service or production, for example). Identifying the team lead as well as approximate project timeline and roles/responsibilities for each team should be laid out well in advance of project initiation. This clarity helps reduce unnecessary overlap work during the implementation.

Document decisions not just processes

Documentation of decisions should be stressed as a first priority. We know that every facility documents processes and the physical flow of products, labor moves, pick, pack, and ship steps, etc. within a DC. However, over the course of even a couple of months, the players change, or the people will not remember the reason behind why a decision was taken.

In our experience, it is better to formally document decision pros/cons during the design phase to avoid such problems in the future. After all, the design document will be the definitive guide for all parties. That includes the infrastructure, for the sizing of hardware and cloud requirements. Quality assurance resources will use the documentation as the input for their test plans just as the configurators/developers will use this as the basis for customizations.

The point is to take more time upfront for the design to get it right and avoid rocks in the road before they stop progress. This also helps to avoid and reduce scope creep as much as possible before molehills become mountains.

Every team should understand what exactly is in the scope of the project and what is not. This will provide sufficient time to complete the assigned work not only on time, but also provide quality work. It will also improve planning and execution schedule adherence.

Approval of scope creep should be minimized, if not totally avoided, due to the impact it can have on several teams, for example, rework, retesting effort and other timeline considerations. Key decision makers from the business should be made available to all meetings pertaining to requirements gathering and design so that they are aware of the project timeline and facilitate effective key decision making.

In our project experience, the exceptions such as picking/packing are overlooked compared to happy paths and not documented well during the design phase. This is one of the key factors that DC supervisors struggle with during implementation if it is not well tested by several teams.

Development/configuration phase

If the WMS application is a packaged product, all configurations should be well documented to the satisfaction and signoff of both IT and the business owners/management. It should be reviewed periodically throughout this phase for details and errors. This eliminates many common problems for the post-implementation support team once the system is live and all the players have moved on from the implementation.

All specifications (functional & technical) should be validated by the team lead for accuracy before development starts. This will improve software quality and reduce time for development by the programmers/coders. Unit test plans should be prepared immediately once specifications are complete and approved by the team lead. It should be written by the QA team preferably and the QA team member should not be from the development team.

Testing phase

Data planning for testing should be done well in advance coordinating with system integrators, user IT, WMS vendor, warehouse control system vendor and the business for testing. The data should be real and sufficient to complete functional, integration, & DILO testing in the allocated time.

The teams from all systems, such as ERP/TMS/WMS /WCS should be available for integration testing. Already converted data for the current WMS should be used. The defects raised in this testing phase functional or integration, systematic, infrastructure, or material handling equipment should be classified as P1, P2, P3 and P4 in terms of priority. P1/P2 should be fixed and retested before moving to DILO testing. RF devices should be checked in blind spots and addressed so that the users do have response issues during the coverage.

The following testing should be done separately upfront:

1. ERP integration with WMS.

2. TMS integration with WMS.

3. WMS integration with WCS and material handling equipment.

If there is a plan to include automation, such as robotics and storage systems, in implementation, a detailed backup plan should be made to run DC operations manually and tested in case there is a shutdown of such equipment.

DILO should be planned in advance of testing. Depending upon the peak volume projected for the next few years in DILO should be done multiple times if necessary.

Most important of all, inventory sync between the ERP and WMS should be run every day to check if there is inventory variance. If there is inventory variance, it should be addressed immediately. Another major plan to be tested during this phase are the disaster recovery and business continuity plans.

User training and acceptance testing

Training should be provided to all the supervisors just before user acceptance testing (UAT) so that they understand the system and how it relates to their job.

Training materials should be well documented with handling of exceptions well in advance so that the supervisors/end users are prepared and organized to handle all scenarios and rely less on IT and support functions.

Migration/cutover

Conversion testing should be done separately and specifically. Inventory accuracy should be validated multiple times. Cutover planning should be planned. All stakeholders should be aware of the plans and regular communication in this regard helps in keeping everyone on the same page. Backup plan(s) for cutover should be made a few months in advance so that if there are problems during cutover, the old WMS can function to avoid shipping problems.

Go live!

Plan the shipping volume for the first few weeks to be less so that all system issues / operational issues can be resolved. In the first few days of go live, all types of scenarios should be tested in production. Frequently, all are happy that the order shipped out of the system. It would be advisable to run the key performance indicator reports (both at warehouse level and DC associate level) for accuracy. All of the shift associates should be aware of their roles as well as understand the system and reports that provide visibility.

Hypercare

Transition to hypercare should be done after the agreed few weeks of go live support. Issues raised should be addressed before transitioning to post implementation support. Post implementation support team members should participate in hypercare discussions to understand the flow and the type of issues they are seeing for effective support. A change advisory board (CAB) should comprise members from each team to determine what kind of defects should be fixed in terms of priority so that the system’s scalability can be increased, and performance impacts can be reduced if any.

Lessons learned

This is a key meeting for the full team to sit and talk about the positives, negatives, and factors they should/can improve. This will be the input for their future projects, and should be a document in the repository so that anyone can have access and learn from it.

I hope this sharing of lessons learned will serve you to a smooth implementation, it’s still probably a unicorn. Leave no stone unturned and you’re likely to encounter fewer rocks!

Sridhar Raman is engagement director, Global Supply Chain Consulting Practice, Tata Consultancy Services (TCS). He can be reached at [email protected].

SC
MR