ThinkEquity Partners, an investment analyst firm, hosted the conference call with Chou. He presented more material than I can cover in this post, but I'll summarize what I consider the major insights.
What is software on-demand?
First, by way of review, the concept behind software on-demand is simple. Instead of a software vendor selling you a software license that you then implement and maintain on your own computers in your own data center, the software vendor hosts the system on its own computers in its own data center and sells you access to the system on a subscription basis. In a nutshell, software on-demand turns software from a license sale to a subscription service.
There are variations in the on-demand model. The vendor may host a separate system for each customer (the "single tenant" model). Or, the vendor may host multiple customers on the same instance of the system (the "multi-tenant" model). It is a relatively simple matter for most software vendors to deploy software on-demand in a single tenant model. But only vendors that have specifically designed their systems from the ground up to host multiple clients on a single instance can host the multi-tenant model.
Oracle's on-demand offering is a single tenant model. Oracle has to build a separate instance of its E-Business Suite for each customer. Salesforce.com, on the other hand, is a multi-tenant system: many customers are sharing the same single instance of the system hosted in a Salesforce.com data center.
In response to my question, Chou agreed that software on-demand is really the return to a very old concept in business systems: the service bureau model of timesharing. However, he pointed out that in the old days, timesharing was a way to address the high cost of hardware, specifically mainframe computers. Today, the problem is not the high cost of hardware but the high cost of software, and especially the management of software. This is the problem that the software on-demand model solves.
Changing the cost structure for providers and customers
Chou's main argument is that the traditional cost model for software is broken. He says,
On the side of the customer, IT guys are spending 75% of their budgets managing installed systems, and the percentage is growing. At the end of the day, if we as an industry do not solve this problem it will be the end of software, because there won’t be any money left for customers to buy new software.On the customer side, the total cost of ownership of business systems is heavily weighted toward on-going support. Customers often worry about the cost of software licenses. But the license cost is dwarfed by the support cost.
The rule of thumb is that a customer is going to spend four times the purchase price of the software per year to manage the software. For example, Oracle's E-Business Suite costs about $4,000 per user. Therefore, the support cost is $16,000 per user per year, or $1,300 per user per month!. Gartner reports similar numbers for SAP. This ratio is even true for applications such as e-mail. This is why IT department budgets are dominated by the costs to maintain existing software systems.If the cost structure for customers is unworkable, it is no better for vendors. Chou says,
But if I can come in and say, it’s not $1300 per user per month, but $100, why would a customer not take my offer? Particularly if I can argue that I can do it better than he can.
On the producer side in the software industry today, we are seeing massive top line pressure. The days of million dollar software deals are over, there is increasing competition, and there is increasing pressure from the open source community. If a vendor cannot significantly alter the cost structure of the software business, there will be no margin left.Chou breaks down the cost structure of a software vendor into three main categories and shows how the on-demand model addresses each of them.
- The cost of R&D, which is typically 15-20% of the cost in a software company. However, much of a vendor’s R&D investment is swallowed up by work other than developing new functionality. For example, developers have to test against various configurations of operating systems and accommodate back-levels of various infrastructure components. Chou estimates that less than 5% of the R&D cost is actually spent on innovation.
- The cost of support. This includes the vendor’s help desk and second level customer support to answer customer questions about how to set up and operate the application. Chou claims that prior to the PeopleSoft acquisition, there were over 4,000 support staff at Oracle, and "none of them are involved in building new stuff."
- The cost of sales and marketing. In a traditional software company, the sales force spends much of its time answering questions from the prospect's technical staff regarding hardware sizing, infrastructure requirements, and other support issues. Chou also points out that when you are selling multi-million dollar software licenses, sales cycles tend to lengthen because a lot of money is at stake up front.
The on-demand vendor also has lower costs of support, because many technical support calls are eliminated. Software on-demand addresses this cost by taking over the support function from the customer and handling it with the vendor’s own staff.
Finally, the cost of sales for an on-demand vendor is lower. Although software on-demand still needs to be marketed and sold, most of these issues become moot inasmuch as the customer will not be hosting the system. In addition, because the up-front commitment is less, sales cycles are generally shorter.
Obstacles to software on-demand
Chou says that many of the early objections to software on-demand, such as security, have been largely overcome. Furthermore, CIOs these days seem to have less of a need to be "server huggers," as he calls them—CIOs that want to be able to see the computer sitting in the corporate data center.
However, there is one objection against software on-demand that still arises--the fact that software hosted by the vendor does not easily accommodate modifications. Chou’s response is that the on-demand software providers today are doing a better job of allowing customers to make configuration changes without having to actually modify the software. But he also points out that CIOs really want fewer customizations. CIOs know how expensive modifications can be, and how much trouble modifications to packaged software can introduce. Ultimately, modification of packaged software is an economic decision.
Making the transition
Chou believes that most of the major traditional software vendors have not embraced the on-demand model because it requires changes to nearly every aspect their business. It is not just a matter of rewriting the application but of changing how software is developed, marketed, sold, paid for, and supported. He says,
This change touches every aspect of a software company, from sales, finance, R&D, distribution, and service. It’s not a simple shift, such as rewriting everything in Java. One of the challenges that the traditional guys have is not technical but organizational. The traditional guys have got to make the crossing, or they are finished. Many of them, including Oracle, have made a great effort, but they have to. The challenges are not insignificant.In conclusion, Chou is not optimistic about the future of many traditional software vendors, many of who will probably not be able to make the transition to the on-demand model. Therefore, the future of software requires new players. The economics of the on-demand model are inexorable. Providers, such as Salesforce.com, Webex, and Rightnow, are showing that the on-demand model is not only viable but also thriving.
Some vendors fear that software on-demand will just turn software into a commodity. But, as Chou says, "It's not bad to be a commodity--it's just bad to be in second place."
For more development of these ideas, check out Chou's book on the subject, entitled, The End of Software.
Related posts
On demand computing: the rebirth of service bureaus
ASPs making a quiet comeback
Mid-market may be sweet for CRM ASPs
3 comments:
The problem I have with Chou's perspective is that it is so heavily based on the presumption that enterprise software is inherently costly to maintain.
At one time, no so long ago, it was presumed that you needed a DBA to look after a high powered database, until someone came along and made easy administration a core goal of their database software.
Software can be developed that is easy to maintain, even enterprise class ERP software. It just has to be made one the the software's goals. The problem is that when buying software, companies don't know how to ask the right questions about administration issues and they do not know what should and should not be considered acceptable. Vendors do not put out lists of "easy admin" features to simplify side by side comparisons.
And therefore, because the customer does not ask, the vendor does not put a high priority on it.
The belief that centralizing the administration of the complex applications will reduce the costs is in my opinion incorrect. Ironically, what it will do is make the support costs a direct cost to the vendor and therefore provide the incentive to make the application easier to maintain!
Moving to a hosted model is not reducing costs, it is just moving them. We need to start demanding that enterprise applications are simple to install, upgrade, maintain, optimize, integrate with and archive. The tools are available to do it, we just need to make it a priority. 400% support costs are insane and should be addresses at the root of the problem.
First of all, I think this is an excellent article. Thanks for writing it.
What's not clear to me after reading it, though, is how much software on demand can actually reduce the support costs of enterprise software. Chou mentions reductions in R&D, support, and sales costs. Here are my concerns:
1. R&D costs - Are we relying on streamlining the development process to one infrastructure stack to cut costs? Wouldn't this naturally occur over time, due to consolidations in the operating system and database environments and the advance of platform independent languages?
2. Support costs - How much of these are costs of maintaining the data centers, and how much of these costs are for helping users set up and use the software? If the former, a centralized service model should reduce the costs. But if it's the latter, then wouldn't just involve a lateral move of the help desk from one company to another?
3. Sales and marketing costs - While you can save the trouble of answering hardware and compatibility questions, could this really be that big a component of a sales and marketing budget? What about the costs of advertising, sending people to see clients, trade shows, etc.?
In the end, I'm not sure these savings add up to a lot. Take a look at Oracle's own financials, and you'll see that R&D is about 12% of sales and SG&A about 27% (FY 2004.) So does that mean that we can potentially lower support costs by 10% to 15% here? That's a pittance compared to the high cost of support mentioned in the article.
How much of these support costs are simply due to the "lock-in" effect, which will always be there whether you are using it at your site or "on demand"?
Finally, could some of the switch to ASPs/on demand be motivated by a desire of customers to move software expenses from capital to operating budgets? Or, conversely, by vendors who need to cut their pricing anyway? Is "on demand" just a subtle way to cut licensing costs by offering an alternative option?
Si Chen asks many good questions, more than I can respond to in comments. But I will comment on his last question, "Could some of the switch to ASPs/on demand be motivated by a desire of customers to move software expenses from capital to operating budgets?"
Customers already have the option to move software expense to the operating budget, by structuring the deal as an operating lease. This has been going on for years. In fact, many vendors offer this as a way to overcome the objection that there is no money in the capital budget for software. So, the desired financial effect can be met without having to move to an on demand model.
Post a Comment