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.

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 below.

Tuesday's Videocast:

The Impact of Vendor Lead Times and Variability on Inventory Levels

Introducing the New Lead Time/Inventory Level Calculator!


Featuring Mark Krupnik of Retalon, Kevin Harris of Compliance Networks and SCDigest editor Dan Gilmore.

On Demand Videocast:

The Internet of Things: Where it's Headed, and Practical Strategies for Leveraging RFID Right Now

We are Entering a New Era of "Turbo Visibility" - Learn How Connected Assets and Data-Driven Analysis are and will Make Companies More Efficient

Featuring Tom O'Boyle, Director of RFID, Barcoding, Inc., McLeod Williamson of Zebra Technologies and SCDigest editor Dan Gilmore.

Now Available On Demand

On Demand Videocast:

Achieving Supply Chain "ESP" with Advanced Simulation Techniques

Enterprise Simulation Planning Enables Companies to See the Future of Their Supply Chain - Learn How

Featuring Toby Brzoznowski, executive vice president at LLamasoft and globally recognized authority on supply chain network design and SCDigest editor Dan Gilmore.