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.
March 27, 2009 at 1:51 am
My opinion also the same. I agree, writing ERP programs is tough, but definitely not as tough as writing databases, operating systems or creating new programming languages. SAP prices are simply more than 100 times high of norms. There is something wrong in ERP development area..