Adopting a Continuous Upgrade Schedule for WMS
Management decrees that it’s time to finally “get around to it” and update the antiquated system to the latest and greatest, so they can take advantage of the newest features and benefits of a modern WMS upgrade. You ask your boss what resources will be made available and how many people will be hired to support what you know to be a monumental effort. After the raucous laughter subsides, you are told that you and your colleagues will now be handling retraining on the newest version AND testing—without support—in addition to the daily workload. In the lead-up to this major software upgrade, nerves will be frayed, best practices will be stretched thin, and production time will likely be lost. It’s a familiar scenario—and one that a continuous upgrade schedule aims to prevent.
Meanwhile, on the provider end…
Your customer, who had previously responded to repeated upgrade pleas with “we’ll get around to it,” decides it’s finally time to do it. Their existing version is so dated that it was initially installed via a notched floppy disk. The customer wasn’t doing continuous or even occasional upgrades, and now the program upgrade and data migration is such a huge effort that your support staff inevitably becomes inundated with tickets, and in turn, the development teams scramble to handle the mountain of bug reports and other upgrade-related headaches.
These are, of course, worst-case scenarios presented to make a case with a light dusting of comedic exaggeration, but I’ve personally been involved in an upgrade where the customer waited roughly 15 years to do an update of their enterprise resource planning (ERP) software, which was not far off from the above situations. The interface had changed from DOS to a modern Windows GUI, the database backbone was drastically different which of course makes data migration tricky, the related serial devices owned by the customer were from the Dark Ages of the early 90s and no longer supported, the format for the tons of configuration files that were proprietary to that particular operation were unusable, and roughly half of the previous SOP process paths through the software had changed. Rather than simply an upgrade, this undertaking was basically a fresh implementation to a company that didn’t expect that level of effort for an “upgrade.”
When I refer to making the case for a “continuous upgrade,” I am not being picky on which release methodology is used, whether it is “continuous delivery” where the release is manual or “continuous deployment” where everything is automated. I’m also not specifically advocating that every available update, patch, or hotfix be immediately applied without question. A tight incremental update schedule where the increments aren’t far apart, while arguably not seamlessly continuous or considered conducting “rolling releases,” should still reap most if not all of the benefits listed below.
In the warehouse management software (WMS) world where customer demand requirements of supply chain and distribution channels can be uniquely challenging, unforgiving, and rigid, continuous upgrade schedules paired with automated testing can prove to be especially beneficial by providing agility and freedom to safely mitigate risk by measuring the repercussions of system changes before going live. Matthew Butler, the Director of Industry Strategy at Blue Yonder, an industry-leading WMS solution provider, said: “At Blue Yonder, our customers yearn for a frictionless upgrade experience, one which can remove the overhead associated with cumbersome technology cycles while allowing rapid adoption of innovations entering the fold through our own development as well as our partner communities. Automated testing is the key to that frictionless experience.”
Advantages of Adopting a Continuous Upgrade Schedule
- Decrease the time-to-value, and reap the advantages of the newest feature additions, performance tweaks, and bug fixes
- The system provider gets more timely feedback, which ultimately helps make a better, more feature-rich product
- Frequent, focused, smaller updates and/or hotfixes are easier to manage than the rare gargantuan upgrade
- Faults related to updates are more easily isolated and in turn easier to troubleshoot for both provider and customer
- Feature additions are easier for users to learn when they are served in bite-sized chunks, as opposed to delivered via a gargantuan suite of new features and UI changes
- There is an ongoing and formal buildup of QA knowledge, as testing is performed regularly in a standardized fashion, while forced, it’s a good thing
- Test cases are easier to maintain when the repository is gradually tweaked, rather than a tidal wave of changes that comes out of a giant upgrade scramble
- The customer in some cases may have to still tediously perform all of the small fixes and patches in the leadup to the giant update depending on the system provider’s program update and data migration scheme, as many will focus their testing on version A to B and not version A to Z, and in this case the customer is essentially doing a continuous upgrade anyway but in a short hectic time-frame
- It is more likely to have subject matter experts and actual users involved with testing rather than a hastily assembled QA team that is seeing the standard operating procedures for the first time as part of a huge undertaking
- There should be no need to temporarily shut down operations, which would be more likely to happen using the occasional, giant upgrade methodology
- It’s the future. Don’t fight the future.
Best Practices
- Dedicated QA staff focused on the latest updates
- A dedicated testing environment where the incremental change is tested before it hits the production environment
- Change management staff needs to be on the ball, prepared for UI changes, new data fields, and eager to take full advantage of the latest features
- The frequency of backups becomes especially critical in the event of an upgrade gone wrong
- Buy-in at all levels, as testing would now be built into the SOP
- Unsuspecting interns to blame in the event that something goes horribly wrong
Are you interested in learning more about implementing test automation in your warehouse management system? Check out our success stories, more of our blogs, or learn more about the Cycle platform.
This post was written by:
James Prior
Sales Engineer
How can change management move from something organizations avoid at all costs to something they embrace? Similarly, how does testing turn from an afterthought into an essential part of reducing risk?
In this free white paper, you will learn:
1. How and why WMS implementations have shifted
2. The problem with putting change management and testing on the back burner
3. How organizations can embrace innovation through testing solutions
