A few days ago, I argued that a company that wants to replace its old, limping systems with a brand, spanking new Oracle or SAP application should probably wait for the next generation of apps.

The post got a lot of approving comments, which surprised me. I think there are pretty good arguments for just hauling off and buying. Consider what one of these hypothetical companies might say in defense of a decision to buy now rather than later.

1. We’ve got the money now and we should spend it.

2. The product we’ll get will be much more reliable.

3. The cost of services surrounding the product will be lower.

4. We don’t know when the new products will be out (with the possible exception of Workday 10).

5. We don’t know what will be in the new product.

Imagine what idiots we’d look like, the buyer might say, if we waited for five years for a product that was no better than what we could buy today and far more incomplete and buggy.

I see the force of this, which is why I thought it was a close call. Ultimately, I did decide it’s better to wait for markedly better products that are coming, despite the risks and delays. But I saw why people would disagree.

So are my commenters intemperate or am I dithering? One test for this is to look at the case of somebody who is not considering a replacement, but is considering a fairly big investment in the existing platform. Maybe they’re considering an upgrade, or maybe they’re considering some extension products, or maybe they want to push their existing installation out to other geographies.

This is a very realistic case. Several companies I know fairly well are considering one or more of these options. One is upgrading to Oracle 11i; another wants to upgrade to Infor LN. Still another wants to extend its QAD implementation to another geography. Still another wants to buy a CRM system from its existing vendor.

For each of these companies, the details matter a lot, but on reflection, I think the same argument applies. It will be hard to get the return on this big new investment in the old platform, because the useful life of what is to you a new product is not long enough to justify the expense.

This raises two questions. First, how does one calculate “useful life.” Most of the companies I’m thinking of believe that the useful life is defined only by how long they’re willing to use it, and for some companies, that’s pretty long. (There are, after all, big SAP clients who are still using R/2.) I think this is wrong, but I’m going to have to hold off explaining why till a later blog.

The second question is, “Assuming that the commenters and I are right, what kinds of investments should companies who have decided to wait actually make?” I have no determinate answers to this, but I think there are some guidelines.

Start with Gavin’s comment on the previous post. Gavin points out that some investments in the Oracle infrastructure and in new Fusion-based products will actually take you toward the next Oracle generation. He is quite right; Oracle designed things this way, and partly because of the problem that I’m describing, they quite deliberately created some ways of investing in products from Oracle without locking yourself into an older technology.

There are many, many caveats, of course. Among other things, if you have an Oracle system now, you might not want Oracle in the future. The three main products I mentioned in the earlier post (Workday, Business by Design, and Fusion Applications) are all highly differentiated, each with its own flaws and virtues. A rational person would do well to look at all of them before deciding to stick with the vendor they have now. (This applies to SAP customers, too.)

Even if you are bent on Oracle, you still may want to take some time thinking through your infrastructure stack before investing in pieces of it. Even the examples Gavin gives like OpenID, which are likely to be pretty good, may not be right in the long run, and if they aren’t, that will be a lot of trouble and expense gone to waste.

You should note that Gavin’s argument almost certainly will apply to SAP, as well. SAP is also workng on “hybrid” intermediate solutions, and I’ll bet you dollars to donuts that they’re trying to figure out every way they can to ease the migration to the new system by asking you to make steady, rational investments in products that extend your current capabilities.

But what about customers for whom an infrastructure or extension investment isn’t right? Here, I think there are some interesting arguments, akin to Gavin’s, for small, light cloud-based apps, point solutions designed to solve highly specific problems. I’m not just talking about a CRM app or a call-center app or a recruiting app; I’m talking about things that are very, very specific to your industry, but really powerful, things like Tradestone in the apparel industry.

Another possibility is to spend some time and effort cleaning up your existing installation. This will improve its current effectiveness, extend its useful life, and very possibly lower the cost of the new system significantly. (A lot of the cost of any implementation is cleaning up after the mess left by a system that everybody has given up on.)

There’s a very smart analyst in Europe, Helmuth Gümbel, who has spent a lot of time thinking about this problem. He has a blog, and he also has a conference, Sapience, which goes into these questions at length. If you’re thinking about extending your current ERP to other geographies, a reasonable alternative might be to find lower-cost ERP systems to serve those geographies.

The basic theme running through these latter approaches is that while you’re waiting, you can focus on saving some money and preparing your current installation, thereby making the later transition to a newer technology faster and more affordable.


Is it time to wait? If it isn’t now, then when?

Wait, that is, for the next gen of applications–Workday HR and Financials, SAP Business by Design, or Oracle Fusion Application Suite–rather than go with what’s out there now: PeopleSoft 9, Oracle EBS 11, or SAP Business Suite–all quite good products, but limited in many ways.

My gut says, “Wait.”

Of course, unless you happen to be my gastroenterologist, you shouldn’t care much about what my gut says. So here’s the reasoning behind it, which I think you can adapt to your own purposes.

PeopleSoft, EBS, and BS were all designed in the early ’90s and are now mature. (There will be no fundamental improvements made to any of them.) So they’re roughly 20 years old. Let’s assume that this takes them halfway through their useful life.

Now let’s do some algebra. Assume that the new products have a similar useful life and offer a 30% improvement in overall effectiveness.
Say the net benefit of buying a this-gen system is 1. In that case, the net benefit of a system that’s 30% better and lasts twice as long is 2.6. Now assume that the net cost of not replacing your old system -.1/yr, which makes it very, very expensive to keep your old system. Even if you have to wait four years for the next-gen system, you’re twice as well off (2.2 vs. 1) waiting. Even if the next-gen system costs significantly more than the old one (fairly likely, depending on the vendor), it’s still a big win.

If you e-mail me, I can give you a spreadsheet, and you can run the numbers yourself.

You don’t need the spreadsheet, though, to see that the argument is a function of four factors: the relative benefit of adopting next-gen apps (over the life of both apps), the cost of implementing them, the risk of implementing them, and the cost of waiting.

A friend who reviewing this argument offered the following analogy. Let’s say you live in an older house whose roof is leaking, pipes are rusty, electrical way out of date. Sure, it’s time to move. But what if there were a big tax break coming fairly soon which would allow you to buy a much better house. As long as the break was big enough, my friend says, the best bet for most people is to wait, because it’s a house, houses last a long time, and being in the better house makes a big difference for a long time.

Even if things are pretty bad in the old house, he goes on to say, your best bet is just to fix the immediate problems: repair the roof, add some new wiring, etc.

Clearly, the biggest and most important factor is how much better that house will be. For a conservative company, this may seem to be a big unknown. But really, it’s not. If you look at any of the new-gen apps, the improvements they’re offering are fairly clear. None of them are killer or transformational; they won’t let you fly when you had been walking. They’re just the sort of things that anybody would add now that they have 20 years of perspective on the old designs.

What are those things? Well, better and faster access to data, what the other pundits call “embedded analytics.” The ability to do some level of search, without having to print out reports and trek down hierarchical menus to get to a record. The ability to bring other people into a discussion of a record, by e-mailing it or asking them to approve it or whatever. All of these things can be done in the old system. But it takes longer, is often a pain in the you-know, and is often not done. Systems that will have all these things built in will be systems where each of your employees wastes somewhat less time each day wrestling with a system that was never designed to have the flexibility and accessibility that the web era has taught us to expect from any application we deal with.

None of these is earth-shattering; indeed, I usually call the next-gen apps Version 1.3 because they’re really not that big an advance over the 20-year-old ERP applications that are Version 1.0. (Is a 2.0 coming? I think so.)

But taken in aggregate, I think they’ll make a material difference in your operational efficiency. Enough of a difference to be worth waiting for.

Does this really apply to your situation? What about that risk? What are the chances that you will get the gains that would justify waiting? What about the fact that your company is ready to move now and for you, such a move comes at the right time in your career? All good questions. And in some cases, it may be right to jump. But for most people, the best thing to do is to take steps to reduce the risk and time to benefit.

Who’s to blame when IT projects fail? Michael Krigsman argues that blame should generally be shared among the three major culprits (software company, consulting company, customer), and a recent torrid discussion among the Enterprise Irregulars largely supported him. If anything, several pundits have told me in private, blame the customers. “If a customer’s going to be stupid, we can’t stop him,” said one.

I’m not comfortable with this argument, because I don’t think it’s sufficiently rigorous. In any unfortunate chain of events, many people have a hand. But it’s simply wrong to blame them all. Some, because of their role or their power or their ability to influence events are principally responsible, while others are merely incidentally involved or are even victims. To get the blame right, you have to dig down and figure out where the power lies.

To see what I mean, let me use an example used by philosophers in the area. You all probably know that World War I began after Gavrilo Princip assassinated the Archduke Ferdinand in Sarajevo. The problem is, who do you blame? Princip (who, it happened was so indecisive and incompetent that he was walking away from the spot he’d picked), the Archduke, who went to Sarajevo only because he wanted to have an outing with his mistress, or the political situation in Europe? Hard to say. But the one thing you don’t want to do is blame the coachman, who, as it turns out, turned down the wrong street and thereby brought the Archduke right to Princip.

In my view, the closer you are to setting the parameters for a project, the more likely it is that you’re setting the course of future events. So if I want a culprit, I look at the person who’s holding the gun, because it’s his decision whether to fire or not. For that reason, I tend to think that the software vendors are presumptively responsible. They’re the ones who decide what can and can’t be done with the tool they sell, and if they create a situation where dominos like misuse, misunderstanding, careerism, stupidity, etc., fall into each other one after the other, like the great countries of Europe, they are responsible, because they could have and often should have anticipated this and done what they can to prevent it.

This isn’t just because they set the conditions and they are responsible if they design conditions that don’t work. It’s also because they give the people the idea that that’s what they’re doing. We tend to give these mandarins the benefit of the doubt, believing that these products are fully tested, that they accord with best practices, that the most experienced people are working on them, etc., etc., etc. And once they realize that this is the expectation, that people do expect them to be good engineers, etc., etc., they take on extra responsibility. It may be fooish, yes, and If the customers believe that tommy-rot, perhaps their foolishness is contributing to the problem. But it still seems to me that the people who accept the power given them by this false belief need to take the responsibility that goes with it.

And that’s why they are presumptively responsible.

I was reminded, forcibly, of this by a recent event at the local library, which just re-opened in a brand new facility with brand new automatic checkout machines. I’m a good citizen, so when I went in the other day with my seven-year-old red-headed daughter, I renewed a book she hadn’t finished. Thirty minutes later, we checked out a couple of new items that she had found.

In the meantime, somebody had checked out seven videos on my account. I still don’t exactly know how, but let’s just assume for the sake of argument that when I finished renewing, I walked away from the terminal, leaving my session “live,” and somebody later walked up to the terminals and just added a few videos to what “I” was doing.

The sessions do time out, and the first thing you’re supposed to do is scan your card, so there’s at least some possibility that this was done with malice aforethought. Somebody had realized that you can steal the Cambridge Public Library blind, if you just hang around the terminals and act quickly after somebody walks away from them. It’s kind of a public-spirited stealing actually, because the person who gets stuck with the bill is not the taxpayer, but the person who used the terminal. The books appear on their account, and as the supervisor told me later, it’s the library policy to make people take responsibility for the books on their account.

“If you use plastic,” he said, “There are tradeoffs, and you just have to accept that fact, my friend.”

You see, as soon as I found these spurious borrowings on my account, I had immediately gone and found said supervisor and told him. My feeling was, “This is a new system, and it’s flawed. If one person has figured out how to do this, others will, too, and pretty soon, it will be open season on the pitifully few books in the aforementioned library. Somebody had better get cracking and fix this.”

Well, that was my feeling, until I talked to the supervisor, who corrected me. “What you say is impossible. We have never had a case like this. You are responsible for the books. Case closed.” I didn’t take this quietly, so eventually, he took down my name and the list of spuriously borrowed videos, and after I left, he shoved the list in his drawer.

The only reason I know even this much is that three days later, I came in to borrow another book, and the videos were still on my account. “I called the assistant director, but he/she is out of town,” he said. I think if he honestly believed that one could steal lots of books with impunity from the library, he would not have reacted this way. But he didn’t. He just thought I was a liar.

Here is where the aforementioned presumption comes in. This guy simply couldn’t believe that the computer system that he had been given could have a flaw. Rather than believe that, he preferred to believe that I, standing there with my seven-year-old daughter, had checked out the videos (seven of them), secreted them somewhere in the library, gone up to him and tried to get them off my account. After I succeeded, I guess he was thinking, I would then go back to the hidden cache, put the seven videos under my arm and walk out right in front of him.

Now I ask you, which of these scenarios is more implausible. One, the designers of the checkout system did so imperfectly, leaving a security hole, which somebody found, possibly inadvertently. Two, this white-haired father of a seven-year-old was trying to steal from the Cambridge Public Library by claiming that he had not checked out videos that the system said he had just checked out (even though the videos were nowhere about his person).

Implausible as it is, this well-educated person who by his choice of profession shows that he has dedicated himself to the life of the mind simply found it impossible to believe that there was anything wrong with the system. He believed this so firmly and so thoroughly that he couldn’t even be bothered to notify anybody about the problem, even though, if there were a problem, it would be a good idea to fix it as quickly as possible, before the library shelves were emptied. So far as I can tell, he still believes it.

The thing is, I almost fell into the trap, too. I’d had my probity questioned, so you know who I was blaming? That supervisor. I really had to sit down and think before I realized who was really at fault. That’s right, it was the vendor. To see why, think about what happens in an analogous situation, at the bank machine. When you take money out of these machines, you simply can’t leave the machine open for the next guy to use. You have to get your card back, and if you try to leave without doing so, you are alerted, loudly. Clearly, best practice in the area is to make it really hard for somebody else to pirate a session. And the vendor didn’t follow this best practice.

I should have known this from the beginning, because I should have remembered that the vendor is presumptively responsible. But as long as I don’t remember it or the supervisor doesn’t know it, the vendor is off the hook. Instead of blaming Princip (or maybe the Archduke or the political situation in Europe), that supervisor is doing the natural thing and blaming the coachman, the guy who made the last and most visible mistake. And until he can be taught that this is a mistake, books will continue to be stolen from the Cambridge Public Library.