First Thoughts
  By Dan Gilmore - Editor-in-Chief  
     
   
  - Oct. 24, 2014 -  
     
 

Calculating the Costs of On-Demand vs Traditional Supply Chain Software

 
 

On-demand or Cloud-based software is coming on fast, and I continue to believe as I predicted several years ago that it will dominate the supply chain market very soon. I predicted that would occur by 2015 - that may be a year or two too soon, but it's coming.

Gilmore Says:

If you were looking at both options from a single vendor, the pricing should be such that the present value of those costs is the same, right?


Click Here to See
Reader Feedback


There are a variety on terms of course, with the original term "hosted" also still out there in some cases, and "Software as a Service" (SaaS) still pretty popular along with on-demand and Cloud. Each of these terms has its own nuance, but I have found supply chain managers use them rather interchangeably to mean the same thing.

What they generally mean is a supply chain software application that is indeed hosted by the vendor or its third party (Amazon S3 is becoming increasingly popular), and that rather than the traditional model of an often large upfront license fee, the company pays based on some subscription/transaction fee arrangement with the provider.

But the reality is that there are two or even three dimensions to this, as I have noted for many years: (1) the deployment model - hosted in some fashion or traditional "on-premise" (on your server); (2) the pricing model - subscription or traditional upfront license fee; and (3) the management model - in some supply chain areas, notably transportation management systems, there could also be a vendor (software company or 3PL) pitching to run all or part of the application for you.

This is summarized in the graphic below.

That is an intro to what to me is actually one of the most fun columns I have written in awhile, on the subject of how we should think about costs for traditional versus on-demand supply chain software. This will be the type of column I just don't think anyone besides Supply Chain Digest ever writes.


Now, keep in mind, as per the graphic above, you can mix and match what you want on these dimensions. For example, and most commonly, you could have the application hosted, but pay for it with a traditional upfront license model.

This in fact is how JDA initially positioned its hosted offerings, when it made a big commitment to Cloud delivery at its 2012 user conference. In fact, I had to work hard to get then CEO Hamish Brewer to be more clear about that at a media/analyst meeting after that announcement.

There are two points to that approach: (1) as a then public company, JDA as with others would take a short term financial hit to its revenues/profits from a switch to subscription from license, and perhaps see its stock get clobbered, rightly or wrongly. In my interview earlier this year with interim JDA CEO Bal Dail, now under private company status, he was clearly much more open to the subscription approach than Brewer had been. This has been a factor holding Cloud software back, but this is changing.

(2) Brewer said the subscription model was more costly for the customer than the traditional approach over the long run, even if less expensive upfront.

That belief is very popular in the industry. I may have said it myself on occasion. It stems from the fact that you keep paying that subscription fee every year, versus paying the license once and being through with it. But is it true?

Well of course, it depends. Let's walk through it.

To that end, we have created a revised calculator to compare the costs of on-demand versus traditional software pricing. It is a revised version of one we created several years ago to do the same exercise more specific to TMS. This calculator is now generic and we fixed a couple of minor issues. You will find it here, as an Excel spreadsheet: SCDigest On-Demand vs Traditional Cost Calculator.

The calculator asks you to enter costs under a variety of buckets for a full five years. It then calculates the "present value" of those costs, because a dollar spent today in effect is worth more than a dollar spent five years from now. To do that, you need to have a "discount rate," which is often considered to be a company's weighted cost of capital.

After all the costs across five years for both options and a discount rate have been entered, the calculator takes the first years costs and adds it to the present value of the next four years for a total present value cost.

Got it? That was meant as a kind of joke, but happy to explain anything via the Feedback button below.

The calculator looks at costs only. In that respect, it assumes the operational savings from the two solutions are the same. That may of course not be true. In the next version, we will add that savings component for a more comprehensive total return analysis.

But we did include one thing in that regard in this version. Because it is often possible to implement on-demand software faster, you could perhaps start achieving those saving earlier (more rapid time to value). So you can enter a one-time number for reaching savings faster that is then subtracted from the total cost of on-demand.

So, there are some interesting dynamics. For example, while you have no subscription fee for traditional, you do have annual maintenance, often 18% of the license. That takes away from its advantage over time. Second, traditional usually requires at least part time support from an IT person that must also be considered.

Now, I will make a bold statement that I have not heard elsewhere: if you were looking at both options from a single vendor, the pricing should be such that the present value of those costs is the same, right? The cost of the solution in current dollars should be pricing model independent. You could even think about it that way across different vendors, from a negotiations standpoint.

There is a wrinkle to this though. One view is that the payments to the vendor are pricing model independent over some period. The other is that you want your total costs to be the same at a present value level across pricing models, meaning factoring in costs like internal support that aren't going to the vendor. In case 1, the vendor is the same either way. In case 2, you are the same either way.

These last two paragraphs have actually said quite a bit, so it may be worth pondering them again to see if it makes sense to you.

What was fun about this column was that I used the calculator to test these relationships and results. In scenario 1, I used a $300,000 license price, and then $54,000 in maintenance each year starting year 2. For on-demand, I used a base subscription of $50,000 and then $20,000 more annually in transaction fees, bumped to $25,000 in year 3.

I also added about $100,000 in additional deployment costs to traditional, and $50,000 annually for half of an IT person to support the application. On-demand had a $25,000 initial set up fee (common). There were a few other minor costs, but this was about it. I used a discount rate of 10%.

The result: traditional had five-year present value cost of a little over $1 million, on-demand $489,000.

These of course are just made up numbers - meaningless without real inputs, but still interesting to use, as I am thinking they are not that far off in some software areas.

In this low interest rate environment, I then tried reducing the discount rate to 5%. It had little impact.

So I tried to narrow the gap. I reduced the license cost to $250,000, and thus the annual maintenance to $45,000. I also upped the subscription/transaction fees quite a bit, to about $120,000 annually. That sure made a difference: traditional dropped a bit to somewhat under $1 million, but on-demand jumped to $696,000 in present value costs.

These are also just made up numbers, but again I am not sure they are far from the reality. Regardless, it shows you what you can do with this tool. Take a look. I will also note we did not include upgrade costs in this version, though it would be easy enough to add, assuming you would upgrade at least once with traditional in 5 years, whereas you get sort of automatic upgrades in some case with on-demand (thought there is still work to do and cost).

Some takeaways from my playing around with this tool: (1) it is hard to make general statements about the relative costs of traditional versus on-demand, but much higher initial costs are hard to overcome over 5 years; (2) Nothing is fixed - it all depends on what you can negotiate; (3) there is some real power in the notion that the two discounted cash costs should be the same, with the wrinkle that does that means total costs or just costs that go to the vendor?

Hope you enjoy the calculator - you should find it useful.

Happy for Feedback on improvements/additions, on top of what I described above we are already planning.

What do you think of this analysis of on-demand vs traditional supply chain software costs? Any feedback on the calculator? Let us know your thoughts at the Feedback button (email) or section (web form) below.

 
 
 
     

Recent Feedback

Re : "discount rate" which is often considered to be a company's weighted cost of capital I wonder whether we are not facing the same problem we did when discussing the inventory carrying costs. If we are just taking into account the company's weighted cost of capital, we don't imagine what we could do with the amount that has been "immobilized" (sunk). If, instead of purchasing a license, we purchase equipment that will pay for itself in lets say 18 months, we are missing an opportunity corresponding to a rate of return of more than 60% (66% without compound interest).

That's why I recommended using the "opportunity cost" instead of the weighted cost of capital. Of course, in the process industry, the opportunity cost will be quite lower than in hi-techs but even then it will definitely be higher than the weighted cost of capital. I have not checked it, but I imagine that intuitively these Hi-Tech companies will prefer SaaS or an equivalent to a too often huge investment. Better being proactive and looking ahead than relying on the figures of our bean counters.


Michel GAVAUD
Director
IDELOG
Oct, 29 2014

A very good summary of the various opportunities for both Business and IT to gain benefit from potentially non-traditional ownership of solutions. Whether it's true SaaS, Managed Services, Infrastructure in the 'Cloud', all offer tangible benefits to an organization if/when either technology or processes are not their core competencies. My company is a mix of traditional, SaaS and 'Infrastructure in the Cloud'. Our TMS is SaaS and we are currently deploying our supply chain planning solutions to a hybrid SaaS/Infrastructure in the Cloud solution. While both functions are core, both solutions take the capital out of implementation/upgrade and the costs of hardware and offer a layer of functional expertise that can be gleaned by both IT and the Functional teams. Just like outsourcing your transportation to dedicated fleets, or warehousing/distribution to 3PL's....moving software solutions to where they're better suited, maintained and allowing you to focus on your core business definitely makes sense, but they may not be for everyone....or every technology component that drives your business. I think your calculator may help to add a level of 'quick look' to add to the conversations and rationale needed to make a sound decision.


John Dean
Director IT/Supply Chain
Not Provided
Nov, 17 2014

True SaaS should be multi-tenant SaaS, right?  Below is my explanation of true SaaS:

 ·  Hosted in the cloud, but don’t use term “hosted” because to me that means that each customer has their own instance/version which is not multi-tenant SaaS.

·         - All customers share the same code base so support is swift and economical.

·         - Multi-tenant SaaS: All customers are on the same code base.  Single-tenant SaaS: Each customer has their own instance of the software and can take updates on our own schedule.  Single-tenant SaaS is not as economical and has less benefits.

·        -  Databases and data are not shared. Each customer should have its own database environment.

·         - All of a vendor’s customers get regularly scheduled updates to the system, sometimes these arrive “turned off” and customers can turn them on as needed. Thus, SaaS customers enjoy the latest and greatest at all times and do not have to wait for costly upgrades.

·         SaaS products are highly configurable and do not allow for customization of code.  Workflows, invoices, forms, etc. are configurable and do not require changes to base code for these changes.

·         Customers and carriers benefit from everyone sharing the same version because once an interface is created for a carrier or 3rd party interface, it is made available to everyone.  Also, customers can share reports and configuration, allowing for less “recreating the wheel.” 

There are many HR and Finance applications that are true multi-tenant SaaS (Workday, Ultimate Software, Cornerstone OnDemand, SuccessFactors, Jobvite, etc.).  These are less expensive than traditional systems because vendors can save money on economies of scale since they only support one version – all customers are on the current version.  They are also written with SOA architecture which speeds development of new features and supports agile practices. 

 I am very new to the supply chain world, but have lots of experience in Enterprise applications.  It seems to me that SaaS is very new in the WMS market. Gartner says the number of true SaaS WMS vendors is small and lists them in 3 categories as below.  They also caution that most of the true SaaS WMS solutions are targeted for less complex warehouse environments, which need significantly less functionality than a Tier 1 WMS. Also, Gartner says that a true SaaS, multi-tenant environment may not allow enough configuration to ensure customization is not needed for customers requiring Tier 1 functionality.  I wonder if this will end up being true, however.  If these new SaaS systems are SOA, they may allow for customizations to be bolt-on by customers instead of altering core-code.  This would be less invasive and have less TCO than traditional customization.  

 

True SaaS

·         3PL Central

·         Apptricity

·         Davanti Group

·         Deposco

·         eBizNET Solutions

·         LogFire

·         Synergy Logistics, Snap

·         SideUp Reply

 

Both single and multi-tenant SaaS, do not get advantages of vendor savings since vendor is supporting multiple versions

·         Accellos

Cloud but Single Tenant so do not get all the advantages

·         Generix Group

·         HighJump Software

·         Infor

·         JDA Software

·         Manhattan Associates

·         Softeon

·         Tecsys


Kelly L. Davis-Orr
Director, Enterprise Systems and Applications
Highlights for Children
Nov, 26 2014

Great column Dan!


Kevin McCarthy
Director Consulting Services
C. H. Robinson Worldwide, Inc.
Nov, 26 2014

Typically, on-premise software is expensive to upgrade. This means that release cycles are naturally much longer on on-prem solutions than in the cloud. It is difficult to get a quick learning feedback loop on on-prem solutions, since the release cycles are too long. A cloud solution can evolve, since release cycles can be shorten to as little as 2 weeks. In the long run, the quality of the cloud solution is going to be higher than the on-prem solution.

The release cycle should be included in your calculator. Note that the cloud solution is continuously evolving. From the cusotmer's perspective it means that release cycles are shortened from years to as little as 2 weeks. This reduces risk in the same way as risk is reduced for retailers when they go from ordering cycles of 3 months to 2 weeks.


Mikael
Head of Research
Apptus Technologies
Feb, 26 2015
.