Top 10 things to use the money for, once you stop paying maintenance.

10. Reducing the backlog at internal support. This doesn’t take much money, of course, since you’re already saving the hours your people had been on hold waiting for the software company to answer.

9. First-Aid. You know all those open, raw spots in your current installation, the ones you hoped would be fixed by the latest version, if you could ever get it installed? Take charge and fix them, ’cause now your former supplier ain’t gonna do it. You’d be surprised what rudimentary first-aid tools can do: a few user exits, a virtual machine for low-profile Java apps that the exits talk to, a little user training, a few reports. You’ll get people back to the front in no time.

8. Raises. You know life just got easier. But that doesn’t mean that you shouldn’t use some of the money to reward your staff for all the effort they put out over the years dealing deal with your former supplier.

7. Shutting down the patch testing environment. Of course, once you do that, you have even more money, so…

6. Buy something you couldn’t afford. Go on, live a little. Here are some suggestions…

5. Invest in mobile. Every one of your executives wants cool stuff on their iPhone (or an iPhone if they don’t have it). Make yourself a star. Give it to them. They’ll go to their graves believing that IT support improved on the day you stopped paying maintenance.

4. Invest in the cloud. Face it. With the end of enterprise support, you don’t have an excuse not to do development that you can’t afford to do. So start by reducing the cost of development. With EC2 or Force.com or Rackspace, you can suddenly start doing it right, that is light and cheap.

3. Don’t invest in social networking. But do take the shackles off. Spend a little, tiny bit of money encouraging people to figure out what they ought to be doing with these new tools (if anything). And maybe use some of the tools to help everybody keep track of the efforts.

2. Return some of the money to the CFO. He or she has been walking around the halls looking for some spare change. Now you can reach in your pocket, pull something out, and feel good for the rest of the afternoon.

1. Hold a check-burning party. Write out 10 of those big checks made out to whoever it is, go out to the parking lot, and reduce them to their constituent elements. Hint: bring some beer.

Got your own suggestions about what to do with the money? Add some comments here.

The Oracle Quarter

June 23, 2009

I was following some Oracle deals, as their quarter closed last month, and what struck me most about some of these deals is that Oracle competitors are trying to out-Oracle Oracle–and failing.

Let me give you an example. One of the most common, best-known plays in the ERP salesperson’s playbook–the equivalent of post-right in football–is called elevating the deal.

When you elevate the deal, you try to take it out of the hands of the “team” that has been assembled to evaluate your product and put it in the hands of busy executives, preferably several levels up, who are in a position to override the team. When you’re put in front of these executives, you pitch business benefits, instead of functional capabilities, and fill their soft little heads with visions of flexibility and agility, competitive differentiators, and money dropping like rain to the bottom line. At this level, of course, you just assume that your software actually has the functionality that will allow you to gain those benefits, which is of course what that low-level team was taking all this time trying to assess.

Both Oracle and SAP are past masters of this particular play; when they run it, it’s Tom Brady to Randy Moss, man.

So this quarter, I heard about two situations where one ERP vendor tried to elevate the deal, at the express instructions of the coach, er, head of sales. In either case, was it Oracle? No, it was the other guy. And did it work? Not a bit. The only thing the competitor succeeded in doing was ticking off the selection team.

It’s a pretty small sample size, of course. But it made me wonder. I know that the applications themselves showing their age. Is it possible that the tactics that go along with those apps are beginning to fray, too? I have been saying for some time, now, that they’ve outlived their usefulness to the customer (if there ever was any). See my blog post, “Lawson’s New Office,” for instance. But now, I’m wondering, have the old sales tactics stopped working for the vendors, too?

I’d be curious to get comments on this; as I said, my sample size is too small. But assuming I’m right, there’s one other question to ask. Why has Oracle figured this out and other companies haven’t?

If so,

Designed for Stability

June 22, 2009

I was just talking recently to a specialty chemical company whose specialty product is used primary by an industry that is now under water. They have a lot of middle-aged systems, and they’re looking for something, anything that they can do in the systems area that can help them out.

We’re talking about a company that needs to contract by, say, 50% until their market comes back.

So what can they do? Well, nothing. But the reason they can do nothing is well worth paying attention to and pondering.

You see, the systems they have–I won’t tell you which one is preponderant, but it’s one of the $AP family, that is, SAP, Oracle, PeopleSoft, JD Edwards, etc.–are all designed for stability. They work well only when things change very little. Change a manufacturing line, get a new big customer, add a new product or two, and these systems can deal; it only takes a few man years of work.

But change the business in some fundamental way and everything breaks. Move a line from one factory to another, and it might actually be easier to move the physical line than it would be to move the data in the old ERP system into the new one.

Chrysler faced this a while back, when Cerberus bought it; now, both GM and Chrysler are having to deal with it. I ran into the problem at an electronics company that was deciding to outsource and at a company that was trying to shift a lot of its business onto the web. Their systems wouldn’t let them change.

Well, it’s a good thing if the company that’s setting up the system is stable, has a product that doesn’t change too much, has reliable customers and a business model that will work for the next twenty years.

Know any companies like that?

It’s a bad thing, though, if your company wants to or needs to change fast. Then your systems will get in the way.

Do people ever think about this simple fact when they’re buying the systems in the first place? I’ve never seen any company that did. Do they think about it when they’re buying a company? I’ve only seen a few. When they’re figuring out whether to consolidate systems, that is, do they consider the tradeoff between the money they’ll save by consolidating systems and the money they’ll lose if they have to disentangle the newly consolidated entities? I’ve never run into anybody who did.

It makes sense, of course. Everybody thinks that things will stay more or less the same. Companies, their employees, the people who sell them systems, the people who design the systems. So that’s what they plan for, build for, and buy for.

The only problem is that much of the time, it isn’t true.

Not only the systems, my dear, but the entire mode of doing business with the vendor.

They come to the conversation talking to me about consolidation; they want to use fewer systems, servers, support personnel, etc.

I don’t think this is going to work; in fact, I think they’re going in exactly the wrong direction.

A few weeks ago, I made some people at Lawson unhappy, because I criticized their inscrutable demo of a new interface and search tool. (See the post, below.) I have to admit that my irritation level with what they were doing was pretty high, since they had not invited me to their conference, and their virtual sessions for analysts were abysmal.

The basic point of the piece, though, had nothing to do with my irritation. Basically, Lawson had demoed something that purported to make a big difference to customers. But you couldn’t actually tell whether it would make a difference or not. I argued that these days, for middle-aged apps, the burden of proof is on the vendor. They can’t just show us something that you can’t even make out and then expect us to stand up and cheer. They have to make what they’re doing persuasive.

Now this point applies to every vendor of middle-aged apps, not just Lawson. Whether you are Oracle, SAP, Infor, Epicor, Dynamics, or Lawson, you can’t just wave your hands, announce that you’ve created something awesome, and leave the audience befuddled about whether what you’ve got is worth anything at all. If you have something great, prove it.

Isn’t this just common sense? When there really was a lot of new stuff you could do with these apps, just showing it off really did garner some deserved oohs and ahhs. But those days are over. These are commodity products; for the most part, their technology is well behind the curve. To get an ooh and an ahh, you have to show that something about what you’ve been doing for ten or fifteen years has really changed.

I happened to pick Lawson to make this point, but it could just as easily have been SAP. It’s just
that their user conference came later.

So now, turnabout’s fair play. Let me show you how this argument applies to SAP.

First, some context. For the past three months, SAP has been making a BIG deal over the release of Business Suite 7, its “new” software package which for the first time gave all the latest software at SAP the same version number. (Until the announcement, the main part of the suite was called ECC 6.0, and the version that was relabeled 7.0 was ECC 6.0 EhP 4, which stood for enhancement pack 4.)

Now I admit, I’m not exactly being fair. That wasn’t quite all there was to Business Suite 7. Business Suite 7, SAP told us, changed the model for delivering software, because in Business Suite 7, you would be able to add SAP software to your current installation at a click of a button. No more sending for disks or downloads or whatever. If you needed any piece of software, you could look at the menu in your administration panel, select what you needed, and there it would be.

In an earlier age, that would have been “something amazing,” as Auden put it. These days, however, the idea is pretty familiar. The SaaS vendors do this routinely, more or less, and so do most consumer apps. So you kind of want to see just what this big, big, big advance really amounts to.

At the original announcement, to which I was also not invited, you couldn’t tell anything about what they were providing. (The broadcast was even worse than Lawson’s.) At Sapphire, though, we got a chance to see it. The inimitable Ian Kimbell, a man I greatly admire (though I must confess I can well imagine him playing Uriah Heep in some amateur theatricals in the Midlands, without a change of costume), gave us a demo.

The context was the Jim Hagemann Snabe/Bill McDermott keynote, which was devoted to product news. In the demo, which you can view yourself here

Lawson’s New Office

April 22, 2009

If you read this blog at all, you know that I hammer over and over again at a single theme: the middle-aged application. What is a middle-aged application? It’s one whose basic mode of interacting with data was invented almost 20 years ago. It stores data in tables; you interact with it by pushing data into those tables or taking the data out. It was a great model, 20 years ago. Today, in my view, it’s fading.

What do you do if you’re a vendor, and you have an app that was built on a paradigm invented 20 years ago? Well, one thing you can try is a new interface. That way, even though you’re still basically storing data in tables, you’re doing it in a way that’s brighter, more colorful, and possibly more useful.

Unfortunately, this is kind of an obvious idea, and the landscape of ERP systems is littered with “new” interfaces that turned out to be not so new after all. According to the vendor, every single one of these modernized the application completely. But all they really did was put lipstick on a pig–and not much lipstick on an exceptionally hairy pig.

The latest such attempt (and surely one of the most creditable) is an interface demo’ed by Lawson at its recent CUE conference. I got a chance to take a look at it (if not a look into it), and I would have liked nothing more than to say that it changes something important about the application.

Unfortunately, that’s not possible, but not for the reason you’d expect. It isn’t that I looked at it and saw, “Oh, it’s just like all the others.” It’s that Lawson made it impossible for me to tell one way or the other. This is not a good thing, of course; if Lawson really has something great, they should show it to people. But it does say something important about the software industry.

First, let me tell you what I know. Lawson told us at the conference that they’re offering two new things that might change the way users work with the application. The first is a search function, which allows you to search for records via their contents, rather than getting at them through the menu system. The idea of this is really good; if you had to name just one thing that makes the old ERP apps middle-aged, it’s the fact that you can’t Google through them in any way, shape, or form. The second is something called Smart Office, which puts a Microsoft Office-like skin on Lawson and lets you interact with Lawson through Microsoft Office products, like Excel and Outlook.

The search function is particularly exciting, because the problems with search are built into the way 20-year-old ERP systems work. ERP systems store their records in a database; to get the records out, you have to use the tools the database provides. Search isn’t one of those tools. (It is too slow.) Lawson gets around this problem by manages pushing all the records in the database out to an appliance, a separate virtual machine, and then using a tool that wouldn’t work on a database, the open source search-engine, Lucene.

From what I could tell, there are some really thoughtful things in the way they’ve implemented the search. Particularly impressive was the fact that you can search back on all the work you’ve done, which makes it easier for you to stop in the middle now, go back to something when somebody asks you about it, or correct mistakes.

Smart Office, alas, seems to be a little more ho-hum. Some of what SmartOffice does was actually built into PeopleSoft more than 10 years ago; much also looks like a knock-off of Duet, the much-vaunted SAP attempt to integrate with Microsoft Office. Still, when you take a quick look at it, it doesn’t seem too bad.

If either product had been introduced ten years ago, I think I would have left my reporting at that. Lawson had come up with something new in the interface and demo’ed it. It wasn’t really very clear exactly what. But who cares. One needed to give them the benefit of the doubt. Surely it was better than a green screen.

Ten years later, though, I don’t think that’s right (even though that’s what most of the analysts did). Ten years later, there’s been a lot of experience with “major” interface improvements, and, as I said above, it’s been a disappointing experience. Most of these improvements have been at best, an injection of Botox, doing nothing about the basic problems with an aging interface, and possibly making things worse.

What this means for Lawson is that the burden of proof has changed. If they’re going to come up with a change in the way users get at data and claim that it’s a compelling, potentially transformative difference, they’re going to have to prove it, some way or another.

Certainly, if the language of the demos is any guide, Lawson does think that they have a compelling and transformative innovation. To listen to Dean Hager, their inimitable and endlessly enthusiastic spokesman for the product, Smart Office and Enterprise Search are, at the very least, what people were offered in the movie, “Seconds,” a brand new body and hence a second life.

So did they prove it? Nope. Yes, there were a few things in the demo which were encouraging. Some of the examples of how to use Search, for instance, were pretty insightful. And while the SmartOffice demo couldn’t be made out by those of us watching on the web, some of the claims sounded good, and the customers who were video’ed were enthusiastic.

But there were also a few things that were discouraging. Since I couldn’t actually see the demos (Lawson doesn’t invite me to their user conferences, even though I don’t ask them to pay my way), I can’t point to anything concrete. But I can say that I found the fact that Smart Office is a client technology (not a thin browser technology) provided by Microsoft less than heartening. (Anybody who doesn’t understand why that’s a problem should take about a ten-second look at a phone that runs Windows Mobile, then take a 10-second look at an iPhone.) Also not so heartening was the fact that Lawson’s broadcast of the event for “remote analysts,” that is, people they don’t think are very important, was incredibly web unsavvy. (Unless you use Microsoft products, you basically can’t even get a feed.)

Add up the discouraging and encouraging, though, and do you get proof? Certainly not. Both the positives and the negatives are way too vague.

And that’s precisely the trouble. It’s 2009. People have been working on these products for 20 years. There’s a great deal known about them. And today, there’s a presumption, born of bitter history, that when a vendor announces something fabulous, but most of what the vendor says is hand-waving, that what they’ve got isn’t really that fabulous.

So what would it take for me (or any rational person) to be convinced that the latest Lawson innovation is one that matters?

Well, let me tell you, it’s not easy. Even if I had full access to this application, something that there’s not a snowball’s proverbial chance that Lawson would give me, it would probably take me a day or two–I’m not kidding–to figure out how much of an improvement it is. To see why this is, let’s just take search as an example.

Lawson says they’ve made search of an application’s records as easy as Google search and that they’ve done this, as I said above, by putting the records on a separate appliance and using an open-source search engine. Certainly, doing this solves the problem of speed, which has been a serious problem.

But the trouble is that solving the speed problem does not make the record search as easy as Google. To make it as easy as Google, there are a lot of other problems you have to solve, too.

Here are some examples. You need some way of ranking what is sent to you in a way that makes sense for your uses; otherwise, as with Google, you’ll get tens of thousands of records when you make a search, and you’ll have to page through them. And you need to solve the ontology problem, the fact that you want to include synonyms in what you found, as well as exact matches. (Sometimes, these “synonyms” are nothing more than making sure that IBM, I.B.M., and International Business Machines are all included in the search results.) You need some way to use metadata descriptions. (Can you easily–and I mean easily, easily–restrict the search to sensible populations, like AR records, or sales orders from two years ago.) And above all, you need to deal with the problem of bad data. Many of the records you’ll grab in any search are records that shouldn’t be in the system. You need some way of filtering them out.

(Enterprise applications that have been in use for any time at all have this big, smelly layer of refuse in them, just the way lakes do. On the whole, I think, the bottoms of lakes smell better. Unless carefully managed, search has a way of stirring up all that stuff on the bottom, not something you want to do.)

If an enterprise application search product doesn’t deal with those problems, well, it isn’t much good. You can say it’s as easy as Google. But when the customer uses it, they just won’t have that experience.

There are still other problems, and one of them’s a real biggie: it’s what I call the transition problem.

You see, if the search (or Smart Office) is really going to change the way people interact with this 20-year-old app, people have to use it. So, in addition to providing a brand-new very hot, ultra-cool search capability (or Smart Office capability), Lawson has to make it possible for its existing customer base to take this capability up and take it up in a way that prevents the costs from overwhelming the benefits.

This transition problem is a thorny one for all the providers of middle-aged enterprise apps; I’ve seen versions of it at SAP, Oracle, and Infor, as well as Lawson. The provider figures out some way of getting an app to sit up and sing, “Rule Brittania,” as the old phrase goes. But then they tell the users that they’ll have to go through a massive upgrade and retrain all their users in order to make the trick happen. Then they’re surprised when most users opt to dispense with any stirring displays of patriotism.

To prove that Enterprise Search or Smart Office actually does something important, it seems to me that Lawson has to tell people (you, me, the customer, etc.) in a clear, simple way just exactly what it has done to deal with all these problems, and then it needs to provide us (you, me, the customer) with enough access so that we can genuinely see for ourselves.

Has Lawson done that? Well no, of course it hasn’t. I’m sure the thought of doing something like that never even entered Dean Hager’s head.

Not only is this unfortunate, it also says something important about the enterprise application industry and about the ability of Lawson (or any of the other middle-aged app companies) to modernize. The fact that Lawson (or SAP or Oracle or any other apps company that does this) doesn’t even realize that the burden of proof is now on them shows how far behind they really are. In a way, it’s puzzling. In the era of the iPhone and FaceBook and the collapse of GM, shouldn’t any company like Lawson be worried? But the answer seems to be, “No.”

Why don’t they think so? I”m not sure. What it comes down to, I guess, is that middle-aged apps and middle-aged apps companies are a lot like middle-aged people; it seems obvious to them that they’re still young, and so they don’t realize it when people start laughing at them. They think that they can give a cute demo at a user conference, have a lot of salespeople go out and tell their customers that it’s the latest, greatest thing, and then the IT staff will put it into the plans. That’s how it was ten years ago, and that’s how it is today. After all, the customers are paying maintenance, and Lawson is taking the maintenance money and working on things that keep the product up to date. What more is wanted?

Well, what is wanted is evidence. Without that evidence, the presumption has to be that applications like Salesforce (enterprise search three or four years ago) or Workday, which uses Flash, not Microsoft, and doesn’t use a 4GL, are now carrying the innovation banner.

Of course, the middle-aged apps vendors are unconvinced, just as all middle-aged employees are. We have the experience, they say; we have the know-how; we have the functionality; see, we can still dance a jig.

They say it, but in my view, they are wrong. Viewed by anybody who uses an iPhone every day, these apps just don’t work all that well any more, relative to how much they cost. They badly need to be brought up to speed. Ten years ago, we could assume that the companies were trying to keep up and we could accept mere assurance. But ten years later, that is no longer enough.

Yes, it may take the customers longer to figure this out than it does the analysts. But eventually, even the most ardent fan realizes that Elizabeth Taylor weighs a little more than she used to.

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.

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.