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.

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.