Since cloud-based or SaaS WMS (Warehouse Management Systems) first appeared around seven years ago, there have been no shortage of opinions proffered on the pros and cons of the SaaS (Software-as-a-Service) model for WMS. Commonwealth has had a busy year with WMS projects – we’re currently conducting WMS selections for three companies, each of which is in a different industry with different needs. It’s given us a good chance to take a real look under the hood of SaaS WMS and evaluate its strengths and weaknesses. Here are some of our findings:
1. SaaS WMS costs less on average in the initial few years of ownership. One of the major advantages touted by cloud-based WMS providers is the cost compared to the perpetual license model. In all of our WMS selections this year, SaaS WMS was, on average, less expensive to own in the first year than traditional providers, sometimes by a very wide margin. Figure 1 below shows the relative difference in cost between Saas-based WMS for software and professional services (we averaged all of the prices together and removed the data labels from the axis to protect the confidentiality of individual bidders).
2. In certain select instances, lower-tier WMS providers can cost less than SaaS WMS providers. In three out of the fifteen price-points we had for comparison, the perpetual license model was less expensive than the SaaS model, but all three instances involved tier-2 or tier-3 providers.
3. The cost advantage of SaaS WMS drops off as operational complexity increases. In basic, simple operations where the WMS doesn’t require a lot of configuration, cloud-based WMS can cost about one-third of the price of its traditional counterparts. However, in even moderately complex operations, this cost differential narrows by about half, as the SaaS-WMS providers have to build in configuration time and cost to their up-front cost.
4. SaaS WMS is still cheaper in the long run in simple operations: When we calculated the five-year cost of ownership with both models, a simple operation that selects a SaaS WMS still enjoys savings of 50% or more over a perpetual license model (Figure 2). Remember, a perpetual license model still requires users to pay 18 – 22% of the software cost each year in ongoing maintenance and support. This cost adds up and helps maintain the wide price differential even over time.
5. For more complex operations, the cost savings with SaaS WMS almost vanish by the 5-year mark. In the projects we studied, the SaaS WMS providers’ ongoing costs were significantly higher than the maintenance and support on a traditional WMS, which erode most of the savings by year 5. Companies with complex operations will need to weigh the cash-flow benefits of SaaS against the higher long-term overall costs.
Figure 1: Year 1 WMS Cost Comparison
Figure 2: Year 5 WMS Cost Comparison
In general, we were impressed with the level of service offered by SaaS WMS providers compared to their traditional counterparts. Space does not permit a detailed review of comparison points, but a few areas where some SaaS WMS systems still lag behind their counterparts include:
- Task interleaving
- Complex bin-to-bin replenishment
- Cube-based put-away
- Event management
- Wave management
Customization and Upgrade-ability
Some interesting facts emerged about how customization works in the world of the cloud. In many cases, we were impressed with the ability that the SaaS WMS providers claimed they had to configure their software with switches and standard rules-based logic, without requiring source-code changes. By and large, we expect that upgrading to a newer version of the software with these configuration-level changes should be relatively painless. However, the situation is not as cut-and-dry when it comes to actual source-code modifications. In our experience, most projects with a moderate level of complexity require at least some true source-code mods, even with top-tier providers. This becomes more challenging in the SaaS world, when all of the users are theoretically operating on the same code-base. If a SaaS WMS user requires source-code customization, then the SaaS WMS provider must change the code for all users, not just one. While the SaaS providers we spoke to all claimed that they were willing to modify their code as often and in as many ways as their users required, it seems reasonable that there must be some limits to this. When we pushed some of the providers on this point, it seemed that there was the potential for the user having to negotiate with the provider to get these source-code changes made, and to make them on a timetable that met the user’s needs. Once the changes are made, then the other users must upgrade to the newest release, which could involve significant new sections of code, depending on how many users required customizations during a given period of time. Upgrades are not as easy as simply coming in to work one morning and discovering a bunch of new features on your software system, as can sometimes occur with less complex SaaS applications like CRM. The upgrade is usually an IT “event” involving testing and cut-over which involves resources at the user company.
Furthermore, in order to keep all users on the same code base, the SaaS WMS providers usually mandate that these upgrades take place at certainly intervals, such as yearly. While it would seem that most providers offer some generous leeway on the timetable for upgrading, users are generally required to do these upgrades, whether they require newer functionality or not. Companies that are experiencing major reorganizations (such as going through a merger or acquisition) will need to discuss this situation with their SaaS WMS provider up front to ensure that their integration timetable is not constrained by the SaaS developers’ schedule.
Before stating Commonwealth’s conclusions, we should point out that this information is based on a limited number of projects (3), and did not involve input from every SaaS WMS provider in the marketplace. Additionally, the information is based on quotations and sales-related statements, some of which may not be borne out by facts during implementation. But, even given these caveats, we felt that some interesting conclusions emerged which are worth sharing.
It seems clear that implementing a SaaS WMS in a low-complexity operation is a very different proposition than trying the same thing in a high-complexity DC. When complexity is low, there will be minimal instances where the user-company will have to negotiate with the SaaS WMS provider to get new functionality added to the code base. Additionally, when it’s time for the required upgrade, testing the new release and rolling it out is also less likely to be problematic. As the cost analysis shows, for these users, a SaaS WMS will probably cost less money to own, both in the short term and the long term.
However, for users with a higher level of operational complexity, it may prove difficult to utilize a highly customized instance of the software, and to perform forced upgrades annually. The initial cost savings with a SaaS WMS may be offset quickly by the internal cost of continually rolling out new versions of the software. It should be pointed out, of course, that this rigorous upgrade schedule does force the user to always have a current version of the software with a modern technology platform. Many companies have fallen into the trap of postponing their upgrade for so long that they are left with an unsupportable version of software that costs as much to upgrade as to replace. So, a happy medium must be found when it comes to upgrading. The user-company should not feel compelled to conduct a complex IT event at a time when other larger enterprise projects don’t make this feasible, but should still have a defined upgrade plan for their supply chain applications at a reasonable interval to remain current.
Commonwealth will continue to monitor the situation with SaaS WMS and report these to our readers.
Are you a user of a SaaS WMS? Please share your insights below.