SAP and Oracle Explore Customer (In)elasticity of Demand

Recently, both SAP and Oracle announced significant (20%) price increases in their offerings: SAP on maintenance fees, and Oracle on license fees. The numbers are significant: Oracle now charges $47,500 per processor for a database license. These increases fly in the face of what is happening to pricing in other digital goods, viz music, telephone calls, etc. In those markets, digitization and digital distribution have caused end user prices to plummet, to the point of industry disruption and a dramatic change in how the goods are paid for — some companies now allow you to pay with your time, in the form of listening or watching advertising, instead of your money.

So the general trend is that digital goods, in this Internet age, are getting vastly cheaper. Yet SAP and Oracle sail into the wind of digital disruption and blithely raise their prices.

Why are they immune to digital price deflation?

In a word, you.

These companies have you over a barrel, or as industry pundits put it, you are suffering vendor lock-in. Having selected one of them a number of years ago and undergone a long, expensive, and frustrating implementation, you are extremely unwilling to change anything, now that you’ve finally got it working right. And so, since you are unable to do anything about whatever the vendor does, you suffer their very rational response to that situation. Oh, you might complain about it, and commiserate with your fellow attendees at the next vendor conference, but you’ll just send the invoice over to AP, and find somewhere else in your budget to trim so that you can cover the price increases. An economist would say you have very low elasticity of demand, meaning you do not respond to changed prices. If I were in that situation, I’d do the same as Oracle and SAP: treat you as a rich resource to be plundered.

Nevertheless, there is danger here for both the vendors and for you.

For the vendors, they appear to have determined that exploring price elasticity is unwelcome, which is to say, they’re not convinced that lowering their prices would bring them significantly more business. As Thomas Wailgum of CIO put in a recent post, one of the complaints customers have about these products is the huge implementation costs of putting them in. Said a different way, they’re so complex that very few companies can afford to take on the cost of getting them installed and working. Consequently, reducing prices on the software probably wouldn’t grow the customer base, because most companies can’t afford the total cost of owning them.

That doesn’t mean that other companies don’t need this kind of functionality, just that they need it in a cheaper and more easily consumable form, e.g., SaaS. Both Oracle and SAP pay lip service to SaaS, but their actions belie their words. They recognize SaaS for what it is: a dagger pointed straight at the heart of how they do business.

Since they’re not going to grow their user base, what other strategies are there to increase revenues? Well, buying other companies that have similar business offerings comes to mind. Both SAP and Oracle, particularly the latter, have pursued this and thereby increased revenues . There aren’t that many big companies left to buy, though, so what’s a growth-oriented company to do? Well, increase prices. They’ve both just done that, and this won’t be the last time, so get used to it. It’s going to be like the cable company — yearly increases above the rate of inflation.

The problem for Oracle and SAP is that, having done the two obvious things to demonstrate revenue growth, there aren’t any other tricks left in the bag. There are only so many Fortune 2000 companies to sell eyewateringly expensive software to (around 2000, by my calculation). Consequently, from a vendor perspective, these companies have painted themselves into a corner. They’ve created products that appeal to a tiny percentage of the market and face the prospect of limited growth. That’s dangerous if your stock price is based on being perceived as a growth stock and your business depends on that.

But so what? Vendors can take care of themselves. This situation is a danger to you, too, and that’s something you should be concerned about.

Why does it threaten you?

Think of it this way. While you’ve tied your career and performance measurement to this unbelievably complex arrangement, a revolution is going on in IT. I don’t just mean SaaS. I mean that computing is oozing into every business offering your company delivers. Meanwhile, you’re stuck devoting an ever-increasing part of your budget to this legacy arrangement, forcing innovative offerings to subsist on the marginal crumbs of leftover budgets.

But just because most of your budget is tied up feeding legacy vendors doesn’t mean that the rest of your company isn’t going to pursue new IT-enabled offerings, it just means they’re not going to look to you to deliver them. You’re the folks stuck in the big vendor hairball. The other parts of the company will find money to do new things; it just won’t go into your budget.

You can hope that the big vendors will deliver products and functionality to get you out of the box, but that won’t solve the problem. First, that paces your business offerings according to the vendor’s innovation vision and delivery schedule, not to mention forcing you to share that innovation with all other customers, hardly a method to achieve differentiation; more critically, vendors will only deliver innovation on their terms, i.e., expensive, complex, and locked-in. In other words, more of the same approach that is already causing you problems.

More threatening is what this means to your company. While IT is apparently willing to live with big vendor decisions, the rest of the company can’t afford to, because it threatens their ability to compete. Shadow IT doesn’t happen because other parts of the company don’t know about the official IT organization, it happens because they know about the official IT organization. A stability-focused, risk-averse stance based upon big vendor dependence forces non-IT organizations to look elsewhere for innovation.

Being wedded to these big vendors and viewing IT’s job as keeping big systems up and running reminds me of the post-WWII dilemma of train companies. They completely missed the revolution of travel by car and plane, devoting their time to making sure the existing train system ran efficiently. The common assessment of why train companies faded into obsolescence is that they viewed their industry as trains, not transportation. Of course, train companies have reinvented themselves more recently as freight haulers, having renounced their passenger business. Perhaps IT’s role will come to be providing data freight, allowing non-IT sourced apps to draw upon the IT basic “freight” resources for connectivity, security, identity, and so on. For sure, the future won’t be like the past.