Four-Five Years
March 31, 2009
Within the tiny world of SaaS executives, there’s a little-known rule of thumb. I call it the Four-Five Years Rule. The rule is this. “When comparing the cost of SaaS offerings against an equivalent perpetual license offering, the break-even point comes in four-five years.” That is, when you add up the total cost of leasing a SaaS offering and the total cost of a perpetual license offering, the latter including hardware, the software license, and maintenance, and even the cost of money, the SaaS offering is cheaper for four years-plus; after five years, you’ve spent less on the perpetual license offering.
Did you know that? Bet you didn’t.
So is that an argument for SaaS, or is it an argument for perpetual license? After all, most installations last longer than 5 years. So maybe you should bite the bullet and pay up front, right?
No. You see, there’s a big, big difference between the two at the break-even point. With a perpetual license application, the application you’ll have is four-five years old. (You see, I’m not including the cost of upgrades.) But with a SaaS application, the application you’ll have is brand new and up-to-date.
It’s sort of an inversion of the old automobile lease-vs-buy conundrum. At the three-year breakeven point, if you buy you have a car, but if you lease, you have an empty parking space. With software, if you lease, your installation stays new. If you don’t, it gets old.
It’s also an inversion of the standard idea about SaaS, that it’s cheaper, but you get less. Not at all, after five years, it’s more expensive, but maybe worth it, because you’ve got a superior product, one that’s been kept up to date.
Not necessarily worth it, mind you. If you don’t need all the stuff they put in to keep the software new, or if you need to customize, you’re definitely better off with perpetual license. A lot of it depends on what you think the useful life of the old software will be.
One last argument for perpetual license, of course. If you do think the old software will have a long useful life, you can plan to save a boodle by going off maintenance sometime after those five years are out. If you do that, perpetual license can be way cheaper.
Only Thought Required
March 30, 2009
Some 10 years ago, a colleague at the small consulting firm where I worked “brought over” a sample requirements document and selection process from the large consulting firm where he had worked. They were pretty bad then, hopeless now, but the amazing thing is that they’re still being used. You can find copies (authors’ names removed) on the Internet.
You all know what they look like. You use them. If you’re just buying an application or replacing an application or maybe adding an extension, you score up the candidates based on a spreadsheet, giving due weight to the quality of service, the viability of the company, the price, and, of course, a long list of functional requirements. The company with the highest score wins.
Bunk, bunk, bunk, bunk, bunk.
First of all, the process overwhelmingly favors the large companies, like SAP and Oracle, because the companies are more “viable,” and the service organization is nominally bigger.
But it isn’t that that kills me. It’s the functionality requirements. You see–and this has been true for 20 years now–most of the functionality requirements don’t matter. The only things that matter are what you might call, “Derailers,” that is, bits of functionality without which your operations are derailed.
Let me give you a couple of examples. Years ago, Avon wanted to buy SSA and did. Avon, as you probably know, sends out a circular with a list of items and prices some 15 times a year. With every circular, the price changes. So unless you could vary the prices depending on which circular you ordered from, you had nothing. SSA couldn’t, and that’s what Avon bought. They put some astronomical amount of money into “customizing” the application, but it didn’t work. The project was derailed.
With any application purchase, those derailers are what matter. Sometimes there are 5; sometimes there are 10. But unless the app you’re buying can do all of them correctly, don’t even bother to buy them.
Unfortunately, the standard way of buying apps masks this simple fact completely. Most of the time, the requirements are long, but nowhere near detailed enough. So by the time a weary group is asking a vendor to demo what matters, they rarely get down to whether the functionality actually works the way it must. At Avon, for instance, all they asked about was “price lists;” they never asked whether the price lists could be attached to a circular.
Worse, even if you figure out that the derailer doesn’t work, the weighting methods that are always used can sometimes lead you to ignore the problem. The fact that the vendor does do 6 of 7 things or 25 of 26 things or 131 of 135 things makes you ignore the fact that IT DOESN’T DO WHAT MATTERS.
What is required instead of requirements documents? Thought. All you have to do is figure out what the derailers are. Then gauge the competitors only on that.
Try It!
March 18, 2009
Here’s a radical idea for you. Don’t buy it without trying it. I repeat. Don’t buy it without trying it.
It? What? A car or an iPod, right? No, I mean an enterprise-level application. If you can’t get a copy and set it up, don’t buy it. And I don’t mean a limited-functionality demo or a look-and-feel demo or maybe a video of the application. I mean try it and see if you like it.
I know. That’s impossible, right? Any vendor will tell you so. No human being can just get a copy of an app, install it, set up the data, and see whether it will work for them. It’s too difficult. It’s too complicated. It takes too long. It requires too much expertise. You need too much help. It would be a support nightmare. It’s completely impractical. It’s pointless.
I’ve heard all these things from the vendors. And they must be right, right?
Oh yes, I forgot all the things they don’t say. It would be too discouraging; the buyer hate the software. The buyer would screw up the implementation and then blame the vendor. The buyer would find problems and insist on their being fixed before he bought. The buyer might even compare capabilities with another vendor’s and use the comparison to drive down the price.
Or the biggest nightmare of all. The competitors get hold of the software, distort, exaggerate, and lie about what they found, and convince an all-too-gullible customer not to buy us and buy them again.
Such bad behavior. What vendor would even imagine this kind of thing?
All wrong. Every bit of it, at least from the customers’ point of view. It is possible to set up a company fairly quickly. And if you can’t, that’s a problem. If you don’t like it, that’s a problem. If something doesn’t work, that’s a problem. If it does something worse than some competitor, that’s a problem. It’s the kind of problem that you should find before you buy.
So try it. And if they won’t let you. Go somewhere else.
But oh, before you do, let me know who it was. And I’ll post the list here.
Should App Prices Go Down?
March 17, 2009
This is the first in a series on $AP* and the basic $AP* value proposition.
Or lack thereof.
The series is called, “Don’t Buy $AP,” because my thesis is that the value proposition just isn’t very compelling for new buyers.
This isn’t a new idea with me. I’ve felt for a long time that it’s hard to get your money’s worth from back-office apps. I’ve also felt that the claims the vendors made about the value of their products were, shall we say, optimistic.
But in an apps environment where almost everybody (IT, the vendors, the pundits) is pretty committed to believing in the value, I’ve chosen to ignore these feelings.
No more. I don’t owe the enterprise vendors anything, and I would like to help people buy smarter, so I’m going to try to figure out, in this series, whether there’s anything to these intuitions. If I dig down a little bit, maybe it will help customers buy smarter. And who knows, maybe I can get some intelligent reactions that will show me where I’ve gone wrong.
I can’t cover everything at once. So let me start with something that really puzzles me.
We all know that prices for a technology ought to go down as the technology gets older. But that doesn’t seem to be true with enterprise apps. SAP* has entered middle age, yet the prices for SAP* have stayed steady or gone up.
Think about it. The core, Unix-based SAP product on an open-systems platform that ran financials and kept track of inventory was developed around 1990, and the product pretty much stabilized at Version 4.6, in the late 1990s. The price then was about $2500-$3000/user with 17% maintenance, if I remember correctly, and today, it’s about $2500-$3000/user with 22% maintenance.
That doesn’t seem right to me. You see, part of the value of a complex product lies in one’s estimate of the useful life of the product. You pay more for a Mercedes partly because you know it will last longer and retain its resale value. So if you were buying SAP back in 1995, let’s say, you were buying a 5-year-old product with a fairly long useful life ahead of it. At the time, let’s say, people thought the average useful life of an ERP system was 7 years, but with SAP, you figured that there’d be a longer useful life and that would partially justify the premium price. So surely some percentage of what you paid was for that particular value.
Let’s say, for instance, that you were progressive beyond the norm and you thought the technology developed in 1990 would last another 20 years. It’s now 2009. You got a good deal. You’ve reached the twenty year mark, and the technology still works reasonably well.
Fine. But now, let’s say you’re in a different situation. You didn’t buy SAP* back then; you bought another system or you muddled along, or you just acquired a company, or whatever, and today, you’re looking at SAP. You surely wouldn’t want to pay roughly the same amount you paid back when the system was newer.
To see the point, let me pursue the analogy. Let’s say you want a new car, and somebody offered you an absolutely brand-new 1990 Mercedes. Never been driven; no wear and tear whatsoever. You wouldn’t want to pay the 2009 price for it. Sure, it’s a nice car, and sure it works pretty well. But there’s just a whole lot of stuff that has changed in the car world since then, and in the next 15 years, there will be a whole lot more. So, good as it is, that 1990 car isn’t worth what it was when it was new.
$AP* PR, before you start calling me, I know, I know, I know, I know. You think that the product has improved steadily and linearly in the last 14 years. So you don’t think the analogy holds. You think you’re offering the customer a product that now has 14 years of improvements in it, so that customers are actually getting a big bargain, a much better product at the same price. You think they’re getting the 2009 Mercedes.
Well, I don’t think so. I think that when you sit yourself down behind that nice, leather SAP* steering wheel and start that nice, purring motor, you can see immediately that what you have just isn’t all that new. But I’ve already tried your patience long enough. To see why I think so, you and I will have to wait for the next post.
* Or Oracle or any other back-office app designed twenty years ago.
The Applicator 