WMS Implementation Paradigm – Let’s Challenge it!
published originally on Supply Chain Quarterly
Warehouse management systems have come a long way from the 1980s and 1990s. So why are so many companies still asking for customizations? Here’s the case for no modifications to challenge the WMS implementation paradigm.
The warehouse management system (WMS) market in the United States is fairly mature, with many companies on their second, third, or fourth system. The software has come a long way from the custom-written systems developed in the 1980s and ’90s that often took well over a year to get up and running, were prone to bugs, and caused integration nightmares. Much sleep was lost by information technology (IT) and operations staff when a go-live was imminent, worried that the cut-over might cause bottlenecks in their shipments or, even worse, shut down their distribution center entirely.
It only makes sense that these complex, robust systems would evolve over time. Many of the “best of breed” providers now offer WMS software that, while still able to handle complex operations, are easier to use and often are web-based and mobile-friendly. Features that were once custom-developed to meet the need of a specific client or industry are now part of the standard software and accessible to all users as part of the base system. Even so, many companies have not recognized these changes and instead are still trying to implement WMS in the same way that they have for years. It’s more than time to challenge the WMS implementation paradigm.
Implementations—the old-fashioned way
Historically, the complex nature of WMS software meant that a lot of technical expertise was needed just to implement the software successfully—let alone make any customizations that might be necessary to fit a company’s functional requirements. Implementations were often long, expensive, and painful. They would be measured in years rather than in months. Furthermore, the systems were not user-friendly, consisting of green screens and basic commands that were not intuitive. As a result, the software required extensive training that was often tedious and time-consuming. Finally, to meet the individual needs of a distribution operation, the software was usually heavily modified and custom-coded.
Even at that time, it was recognized that customization wasn’t always a good idea. The software was typically customized to meet the existing processes, but the processes it was automating were not always the most efficient way to do things. Companies expected software to be a magic wand that would instantly make them more productive, efficient, and profitable. But in hindsight, managers often realized they should have fine-tuned their processes to align with best practices first before they customized the software. Furthermore, highly modified WMS software required even more training and led to even longer implementation timeframes.
Still, having a WMS was a far cry from handling operations with paper. Once a system was configured and working properly, it provided a great deal of information to aid in decision making, helped end users increase efficiency and productivity, and reduced costs.
New approach to implementation: no modification
WMS software and implementation processes have come a long way in the past couple of decades. Warehouse management systems now include best practice processes for most industries and functional requirements. In fact, they’ve gotten so good that if your process requires a modification, you really need to spend the time to dig deep and ask yourself if your way is truly better and necessary, or if you would benefit from changing your process. Software is also written differently and is more configurable, which means features can be turned on or off within the system based on a company’s industry and requirements.
Still, many companies today continue to choose to write modifications to the software rather than change their processes to match the software’s built-in best practices approach. Perhaps this is because of a “this is the way we’ve always done it” mentality or because the company hasn’t taken the time to research the benefits of changing processes to match best practices. And sometimes consulting companies even encourage modifications because it means more billable work for them. However, many problems arise when you modify the code of software, including higher total cost of ownership, longer implementation time frames, integration integrity issues, increased fees for support and maintenance, and limited ability to upgrade and adopt new features as new versions of the software are released.
While implementing a WMS with no modifications would have been out of the question 10 years ago, it is a very real option for most companies today. In fact, it should be the expectation and starting point, rather than assuming from the beginning that there must be system modifications. For example, most of our clients who are upgrading to a new WMS are now choosing to reduce their modifications by 80 to 100 percent and have seen many benefits to this no-modification approach. The upgrades on average cost only 25 percent of their original implementation, and they are saving an average of 30 percent on maintenance costs.
Additionally, a no-modification WMS implementation can be up and running in three to nine months, versus one-year and longer for more modified systems. To understand why, let’s look at a simple modification that might take five to 10 days of development and unit testing, plus another week or two of acceptance testing and rework. This modification would also require time and resources to update documentation, training materials, and standard operating procedures. And if that piece of functionality needs to share information with other systems, such as an enterprise resource planning (ERP), transportation management system (TMS), or labor management solution, then you need to modify the integration with those systems, potentially impacting the integrity of those systems. Additionally, any modifications can have an impact on the existing adjacent code within the WMS. All this adds up quickly to significant cost, time, and integrity issues, and this example is based on only one straight-forward modification. And the increased costs continue—most WMS vendors charge an extra 15 percent of the cost of the modification annually for maintenance costs.
Getting started
If you are interested in challenging the WMS implementation paradigm and implementing a WMS with the goal of no modifications, start by analyzing your current operations and processes with a partner who has distribution expertise and deep knowledge of the WMS features, functions, and capabilities. Together you will explore each functional need you have alongside the WMS standard functionality and discuss how the software and processes meet and how processes might be tweaked to match the WMS best practices. For some companies, modifying WMS software may make sense but only if the costs associated with modification are less than the long-term cost savings for such modification.
Based on our experience, we believe that for the vast majority of companies, the no-modification approach advocated here is most beneficial. It is easier to install, can be up and running faster, costs less, and provides a smoother upgrade path so you can more easily take advantage of new features as they are released. No modifications also mean that you are raising the standard of your operational processes to be in line with best practices; the ones that the software is based on at the start. This alone will provide efficiencies for your operations that may not have been previously realized.
