Published February 8, 2022
My previous post on warehouse management system implementation pitfalls started with the proposition that many warehouse management system implementations end up exceeding the budget, blowing out the planned schedule and failing to deliver the promised results. I went on to examine four common pitfalls that may be encountered when deploying a new warehouse management system. Below are five additional challenges that can negatively impact your warehouse management system implementation, as well as solutions for dealing with each pitfall.
- Over Automating Exception Handling – Exception processes are the bane of most distribution operations. It should be no surprise that they can have a significant impact on implementation resources and timeline, from design through end user training. Exceptions are a given, but how they are handled within the new warehouse management system (WMS) shouldn’t be. There is a natural tendency to want to make exception handling as automated and seamless as possible to the end user regardless of the implementation effort required.
Automating an individual exception process as much as possible within the WMS can be eminently justifiable based on its frequency and the cost involved. It probably makes sense to try to shave a few seconds off of an exception process that constantly occurs throughout the day, but the same may not apply to an exception that occurs once a quarter, even if the alternative is a rather messy, time-consuming manual process.The best approach for addressing the outliers is usually obvious, but figuring out how to address all of the exceptions that fall in between can be challenging. Ideally, this involves comparing benefits for each exception alternative against its associated deployment cost and risks. However, depending on the business requirements and total number of exceptions involved, this can take too much time and effort. The best approach in these situations may be to avoid more automated designs whenever justification is not immediately apparent. Improvements can always be made during subsequent phases when the need has been established through experience with the new WMS system.
- Not Enough Time to Test and Train – Most distribution operations about to embark on a WMS implementation appreciate the importance of testing and training to the success of their projects. If they don’t, their software vendor or systems integrator will likely educate them, so hopefully adequate time and resources were allocated to testing and training in the original budget and project timeline. However, as the other pitfalls indicate, things don’t always go according to plan. The requirements can turn out to be more complex than originally expected. Vendors can be late on configuration and development delivery. Interface development can lag behind schedule. Processes can fail initial test cycles and require significant rework.
These situations can place significant pressure on test plans and timelines. They also impact training plans since most end user training is provided after user acceptance testing. Ideally, whenever the prospect of potential testing and training slippages arises, it is immediately highlighted so that mitigating measures can be considered and applied. However, these mitigating measures typically involve additional resources and expenses as well as scheduling adjustments, so executive management may be resistant to these steps. Furthermore, pushing the schedule back may be extremely painful when external factors such as new building availability or the start of peak season are involved. The best that project management can do in these cases is to make sure that executive management clearly understands that the cost and pain of dealing with this issue now is going to be less than at go-live. If there still isn’t enough time and budget to address testing and training shortfalls, then the project team needs to prioritize which areas and processes should receive the most attention.
- Stumbling Through Go-Live Transition – Detailing post go-live resource requirements and activities is frequently given little attention during the project planning process. Usually, there is some sort of ‘hyper-care’ built into to the schedule immediately after go-live. Typically, this means that some of the software vendor’s or integrator’s implementation team remains on-site and/or on-call to promptly address issues as they arise. After this post go-live period, support then transitions to normal vendor help desk functions.
This may or may not be sufficient depending on the operation and the state of the implementation. It also does not address transitioning internal WMS support resources to a production support mode. First, the amount of vendor or integrator and internal WMS resources required to adequately support operations immediately after go-live is dependent on the operation size, complexity and shift schedules. Also, the resources needed are directly related to the overall health of the implementation at go-live. The more problems-especially surrounding testing and training-the more resources that are going to be needed on the floor. Waiting until the last minute to request additional external resources is an invitation for disappointment, as there is a very good chance that the vendor or integrator won’t have them available. Even leveraging internal resources to help fill the gap can be problematic if you wait too long, as these resources must be onboarded.
Second, the implementation needs to transition to a production level support mechanism once the solution achieves some level of stability. This requires internal resources as well as the software vendor’s support structure. There needs to be an internal help desk structure that directly addresses end users’ issues and problems. If internal support cannot resolve an issue, it then escalates to the software vendor’s support structure. The internal support structure should be in place before go-live with its resources on the frontline during the immediate post go-live period.
- External Dependencies – Whenever a WMS implementation is connected to another initiative there is always the possibility of a WMS schedule slippage due to pushback on the other project’s timeline. Examples of projects that may be linked to a WMS implementation include new building startup, major material handling automation installation and ERP deployment or upgrade.
If the WMS go-live date is dependent on the other project’s milestones, then slippage in these milestones must be reflected by adjusting the WMS go-live date. This can have a significant impact on resource allocation and budget. While there may not be much that WMS project management can do to avoid this hazard, early identification may help minimize its impact. Moreover, the possibility of its occurrence should be addressed with the software vendor and/or integrator during contract negotiations and repeatedly reviewed as part of project status communications.
- Excessive Finger Pointing – Most WMS implementation teams would emphatically agree that teamwork is critical for success. Yet, whenever a WMS project starts to struggle, there is a tendency for teamwork to become a casualty. This is understandable-when things go wrong, people become stressed and defensive. Even worse, they can become antagonistic towards others and start playing the blame game. This toxicity can easily get out of hand and become a major drag on project productivity and results.
WMS projects can be stressful, and people have egos and tempers that can flare in direct response to this stress. This can’t be entirely avoided, but whenever the level of stress and antagonism starts becoming more prevalent and pronounced, project management and the core team need to take direct action to defuse the situation. The remedy can vary according to the situation and team structure, but it should include team-wide communication combined with the opportunity for individuals to express their concerns and frustrations in a confidential one-on-one setting. Attention needs to be given to these concerns, but the overall message needs to be consistent-we are all in this together.
As always, the primary tools for avoiding WMS implementation pitfalls are a sound budget, solid team, well-structured project management approach and an engaged executive steering committee. However, the unexpected can always happen, and every WMS implementation team needs to give some consideration to what can go wrong. This doesn’t mean that they need to obsess about all the potential pitfalls and develop elaborate contingency plans to deal with them, but some thought needs to be given about how to respond to adverse events. If they occur, the team needs to spring into action. If they are caught flat-footed, then the likelihood of turning things around is severely diminished.
Check out Part One of this series for four additional pitfalls that may be encountered when deploying a new WMS. Learn more about how to ensure a successful WMS implementation in the related articles below and be sure to visit our newsroom to stay up to date on our latest news.
