Chains of Command | The Open Sky Blog

Should I upgrade my Warehouse Management System software?

Do I need to upgrade my WMS now?  Like many questions in business, there are many considerations to work through before arriving at an answer. A common rule of thumb for keeping a software system is seven to twelve years – and, of course, whether it is seven or twelve depends on many factors that are not always in your control, such as platform and layered technology changes. The question of upgrading can get a little complicated because sometimes the differences between an old and a new version of software are so huge that an upgrade becomes more like a new software system implementation. So, how do you know when or even if you should upgrade your supply chain software, such as Warehouse Management Systems (WMS) or Labor Management Systems (LMS)?

First you have to ask yourself, “Why the upgrade?” and “Why now – can it wait?” This will help you develop a list of reasons for upgrading. Here are some additional questions to help you dig a little deeper:

  • What useful new functionality does the new version provide that the current one does not that would make an upgrade compelling? (Common reasons include new supported processes or vendor compliance requirements)
  • What are your key complaints about the current version?  (These commonly fall into lack of performance, functionality or compatibility)
  • How soon will a third party render your current software obsolete?  (i.e., The GUI client is incompatible with Windows 7 and Microsoft has announced the End of Life for Windows XP to be 2012.  To maintain support availability on your workstations, you may need to coincide a WMS/LMS upgrade with your Windows 7 deployment)
  • Does your corporate IT vision include significant changes in the future that make your current software configuration outdated or out of sync with executive plans? (Common IT vision elements include third party hosting, moving to the cloud, virtualization, operating system standardizations, hardware standardizations and DBMS standardizations)

After you’ve gotten a solid list of reasons pulled together, the next step is to estimate costs, effort and savings to know what you’re actually getting with this upgrade.  This is a really important part of the project and what is developed in this step becomes the basis for judging the project a success (or not). Particularly in the tighter economy we’ve had lately, it can be tough or impossible to get approval for projects where you haven’t spent time outlining the return. In order to have something considered a success you’ve got to define what that means.

When you’ve got your list of reasons and the associated costs, savings and effort estimates, your team will be in a good position to make the decision to upgrade (or not).

If you determine an upgrade is the right thing for your organization, we have a word of caution for the planning portion. One of the most frequent mistakes we’ve observed is poor organization and execution for the implementation of the upgrade.  This almost always stems from lack of definition around project roles, and, more specifically, over-reliance on a software vendor to implement the project. That’s not a negative comment about software vendors – it’s a realistic statement about what they commonly provide vs. what the purchaser of the software is expected to provide (in general, a software vendor will provide 25% of the tasks required for a successful implementation, which leaves the purchaser to provide the remaining 75%). It can be a good idea to hire some outside help to make sure you get the expertise you may not have internally. And, sometimes it’s not even a question of having the capabilities on staff; it’s a matter of having the right kinds of time to devote to an extra project outside of the daily responsibilities.

If it turns out that an upgrade isn’t justifiable, you still do have some alternatives of course. There are many systems that have the facility for customer created enhancements to bring the needed functionality that may be faster and less expensive than an upgrade to your software system. Another possibility to consider is that maybe it’s time for a different system altogether? This of course can be as daunting a process as an upgrade but like a car you’ve had for many years, at some point it doesn’t pay to keep sinking money into it if it’s not meeting your requirements for reliable transportation.

If you are a RedPrairie software user, we’ve written a guide to help you examine this issue further. And, we’re giving away our RedPrairie Software Upgrade Guide this month to those who subscribe to our eNews mailing list. Simply complete the sign-up form below, hit submit, and your RedPrairie Software Upgrade Guide will be available instantly.

Fill out my online form.

And, if you haven’t seen this already, here’s a take on this topic from Steve Banker, a very well-respected ARC analyst, in a post on Logistics Viewpoint.

Comments are closed.