Stealing from the Cambridge Public Library
March 5, 2010
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.
The Crocodile in the Room
February 12, 2010
Several years ago, the top, top people at SAP were offered a gigantic bonus if they could “double the stock price by 2010.” Not too soon after, a friend of mine who was in line for the bonus left the company for a start-up. “Why,” I asked, incredulous.
The answer was pretty simple. “It’s not possible,” my friend said.
Not possible, one might have wondered at the time. Then why are all these intelligent people pretending that it is possible. Don’t they see the crocodile in the room?
Somewhat later, I talked to another friend, who had gotten a REALLY good deal if he signed an SAP contract now, before the end of what looked to be a tight quarter. “But all they’re doing is pulling revenue forward,” I said. “That’s right,” said my friend. “They’re taking a huge hit and for no particular reason.” So, I wondered, why are all these intelligent people trying so hard to hit that quarter. Don’t they see the crocodile in the room?
Still later, I talked to an investor who was pretty pleased about SAP’s new margin targets. Henning, you’ll remember, had told the investor community that they’d finished a long, expensive project to upgrade the product, and now they could afford to put the money back into margin. “But the investment didn’t produce the results they wanted,” I said. “So now, if they increase margin by reducing R&D, they’ll be taking away from investment they have to make.” Didn’t the people at SAP see that? Didn’t they see the crocodile in the room?
It seems to me that with this week’s changes at SAP, it’s possible that somebody (Hasso?) actually sees the crocodile. You can be the most forceful, sensible, and astute manager in the world, but if you try to make a technology company more valuable without generating value, eventually, that crocodile will get hungry. You can’t do it by giving out bonuses and hoping. You can’t do it by pulling revenue forward. You can’t do it by saving when you need to invest.
The only way you can do it is to bite the bullet and start using the maintenance that people pay you to make modern products that work well, products that will actually justify the maintenance they spend AND appeal to many other people who don’t yet have relationships with SAP. And if that takes a while, it takes a while. You can’t just say 2010 or else. You have to figure out how to do it, first. And sometimes it takes a while.
Now I’m not saying that the new management can find crocodiles any better than the old management. We’ll see. But if they do see the same crocodiles that I do, and they want a recommendation from little old me, here it is. Come clean. Right now, most investors are disappointed, because they think that SAP is backing off the old CEOs promises, and they don’t know why. If you tell them about the crocodile, admittedly, many of them will run away. But others will realize that it’s a crocodile that can be tamed, and since you trusted them, they will trust you to do the right thing.
PS. If this post makes it sound as if I’m blaming Léo for lack of realism, I apologize, to you and to him. Léo was using all the levers at his disposal to do what he was being asked to do, and he was using them in an insightful way. SAP did need to reduce its workforce, improve its support, and improve its operations, and under Léo, all these things were addressed. My only point is that what Léo was doing could not address the underlying problem. But that’s not what he was charged to do.
The SUGEN Numbers
January 20, 2010
I argued in the previous post that SAP’s new, “two-tier” pricing system for maintenance offers customers less choice than meets the eye, and commentators like Dennis Howlett agree.
So why did they bother? If one offering is “good support for a fair and reliable price” and the other offering is “less good support for roughly the same price (only no one will really know for six years)” why would anyone pick the latter? And why would SAP risk a public relations nightmare when the people who pick the apparently lower-cost alternative find that they’ve been snookered?
Is it just that SAP needs to offer the enterprise application version of “small coffee,” the coffee size that nobody ever orders, but you need on the menu, so people will order medium?
The question is particularly salient because SAP has data that, one could at least argue, shows that Enterprise Support really is better.
This data comes out of a program embarked on last summer, sponsored by SUGEN (SAP User Group Executive Network) and SAP. In this program, companies were put on Enteprise Support, and the benefits thereof were measured in 11 benchmarks and the sum of those benefits added into something called the SUGEN KPI Benchmark Index. SAP had vowed not to raise the cost of Enterprise Support until this program showed that a gain in the Index that gained justified the increased cost of Enterprise Suppory.
SAP reported the results at the Influencer Summit last December, which I attended. According to the numbers they showed me, the SUGEN KPI benchmarks had indeed been achieved.
These numbers were disclosed to me on the condition that I not repeat them until the full results were published, and while I’ve been given informal permission to speak about them, I will try to respect this request.
I think, though, that I can convey a fairly accurate idea of what is going on without actually citing the numbers.
Before I can get to this, though, I need to explain something about the program and the expectations that people had for it. When SAP first announced a new, improved class of support at an increased price, which all customers were required to use, many customers thought that this was just price-gouging. They didn’t believe that SAP’s across-the-board price increase for maintenance would be accompanied by any benefits. When SAP started hearing from these customers, they were clearly taken aback, since the executives in charge of this new support program clearly did (and do) believe in its benefits.
So SAP (and SUGEN, the customers’ self-appointed representatives) agreed to put the question to an empirical test.
Now anybody reading the press release about this program or anybody attending the journalist session at last May’s Sapphire (as I did) would believe that this test would be done along traditional social science lines. A representative sample of the SAP customer base would be given the opportunity to take advantage of Enterprise Support, and the benefits would be measured.
After attending that session, I told my client base (people who are professionally interested in tracking what SAP does) that it was impossible for this program to show so much benefit that it would justify the across-the-board increase. The reason was simple. To get the available benefit from Enterprise Support, a customer must get and install a software product called the Solution Manager and must then do a lot of process documentation and process modification. A representative sample of SAP customers simply wouldn’t include very many customers who had done all this installation, documentation, and change, because the total amount of work was considerable, and most customers weren’t going to do it, at least not any time soon.
Isn’t it sort of squirrelly, expecting Enterprise Support customers to get software, install it, and then do a fair amount of work before they get the benefit that SAP promised them? Well, yes, but it isn’t quite as squirrelly as it sounds.
At the Influencer Summit, Uwe Hommel, the person behind this idea, expressed it roughly this way. A lot of customers don’t really run support as well as they could. The Solution Manager provides them with a framework for the practices that they should be using, plus it enables SAP support personnel to give better, more accurate, and faster help, because the Solution Manager gives them better information about what was going on at a customer site. It would be nice if SAP could wave a magic wand and improve support without any effort from the customers. But that just can’t happen. All we can do is provide a framework.
As far as Hommel is concerned, what SAP is saying is roughly what the trainer at the gym offers. “We’ll make you better, bigger, stronger, and leaner, but of course you have to do your share.”
Fair enough, of course. But that’s not actually what SAP said. SAP actually said something more like, “You need to do support better, and to do it better, you’ll need a trainer and you’ll have to put in some effort, but oh, by the way, you have to pay for the trainer whether or not you actually get around to going to the gym.”
Perhaps the oddest thing about the test that SUGEN and SAP ran is that both parties pretended that SAP had said the first thing and not the second.
You see this, for instance, in the way they [SUGEN according to Myers, below] chose the subjects for the test. Rather than choosing the representative sample of the customer base that I was told they would choose, they asked for volunteers to apply for the program. 140 customers did apply; of those, only 56 were chosen for testing. This, of course, simply guaranteed that the test would not prove what SAP wanted it to prove, that the price increase was justified. At best, it would prove that those customers who decided to go to this metaphorical trainer would get some benefit from it.
So, did they get some benefit?
Well, um, uh, sort of.
As I said above, SAP and SUGEN agreed before the test that there were 11 areas where benefit might be provided. The areas ranged from the obvious things–fewer outages, faster problem resolution, and fewer problems–to the less obvious, but still important things, like more efficient CPU utilization and better use of disk storage.
In the actual test, the benefits of Enterprise Support was measured in only 6 of these 11 areas. The areas chosen had to do with total cost of operations (use of CPU and storage), the cost/effectiveness of managing patches, and the extent to which customers used SAP’s current software effectively. Clearly, this made things harder for SAP, since they were trying to prove benefit, but the benefit was actually measured in less than half the areas where benefit might be available.
Nevertheless, SAP thinks that it succeeded, and technically they did. They measured benefit by giving the SUGEN Index an arbitrary value of 100. The way I understood it at the session, the aim was to show that the increased benefits at least offset the roughly 7.6% price increase in 2009. [According to Myers, below, the actual aim was 4%].
Both aims (what I thought was the aim and what Myers said was the aim) were actually achieved. The benchmark index dropped by 6.89 percentage points. Even though only 6 benchmark areas were measured, the benefit achieved did offset the 7.6% increase (at least within 1 percentage point).
There is, however, a little, tiny, “but.”
All the benefit was achieved by massive improvements in only two out of the six areas: storage utilization and number of failed changes. (A “failed change,” is an attempt to install a patch which fails.) In all the other areas that were measured, the average improvement was very small.
Both of these measure appear to me to be one-time-only improvements. Take, for instance, storage utilization. If you have one of those awful Windows machines, and your disk is sluggish, you can run a utility that compacts your disk and frees up disk space. You’ll show massive improvement in storage utilization. But running this utility once is not the sort of thing that justifies a permanent yearly increase in maintenance costs. Yes, you can do it next year, but it won’t show the same level of improvement, because you gained most of the benefit the first time you did it. The same thing goes for reducing failed changes. Changes in process (and use of the Solution Manager, or Sol Man) can reduce this number a lot. But once you’ve made the changes, further reductions aren’t really available.
I certainly hope that somebody from SAP is reading this; if you are, you’re probably upset, because you’re saying to yourself, “Well, the benefit is permanent; for the rest of time, people will have fewer failed changes and use less disk space.” [Myers does in fact argue this. See below.] You are, of course, right. But you’ll have overlooked the larger question: does helping people to a one-time improvement justify a permanent, yearly price increase. That is hard for me to see. If Enterprise Support promised to bring these kinds of improvements in regularly, then it would be OK to pay more for it regularly. But this test doesn’t show that these regular improvements will be forthcoming.
In any case, it’s all moot now. SAP has scrapped the SUGEN benchmark process. In a way, it’s a shame. This is one of the few times that any enterprise application company has ever tried to run a systematic test of whether its software and services work as advertised. And the results of this test are very interesting. In some areas, the software and services don’t seem to work; the benefits are minimal. In other areas, though, they work very well indeed; the benefits are startling. Who woulda thunk it?
At the very least, shouldn’t SAP keep going with this, so it can go back and fine-tune its software, figure out why some benefits aren’t forthcoming and do something about it?
Apparently not.
SAP’s “U-Turn” on Maintenance
January 15, 2010
SAP announced yesterday that it was creating a two-tier support system, effectively reinstating its old Standard Support offering at a slightly increased price. (The new price is 18% of net versus the old 17% of net.)
This has been hailed as a U-Turn by press and analysts, all of which proves something to me: most writers can’t do math.
SAP begins its press release as follows (emphasis mine):
In a demonstration of its commitment to customer satisfaction, SAP AG (NYSE: SAP) today announced a new, comprehensive tiered support model that is being offered to customers worldwide. This support offering includes SAP Enterprise Support services and the SAP® Standard Support option and will enable all customers to choose the option that best meets their requirements.
So let’s look at the choice that’s being offered to customers; after you look at it, you can judge how much satisfaction it’s going to generate.
The cost of Enterprise Support this year is 18.36% of a base number, a number that usually stems from (but may not be identical to) the net amount paid for the SAP licenses that are being supported. So, this year, assuming that the base for a company was $100,000, the total cost of Enterprise Support is $18,360 and the total cost of Standard Support is $18,000.
Next year, the cost of Enterprise Support goes up to 18.9%, increasing to 22% by 2016. That means that in 2011, it is $18,900, and in 2016, it is $22,000. Those of you who are writers, I apologize for all these numbers, I know they do get confusing.
Now to Standard Support. With Standard Support, the percentage is fixed. But the base is not. It is subject to cost of living increases. We don’t know what COLA (cost of living adjustment) SAP will impose. But let’s just say for the sake of argument that it is 3.00%/year. In 2011, the cost will be $18,540.00, and in 2016, it will be $21,493.00.
All this is in a spreadsheet which you are welcome to look at and play with. (In the spreadsheet, I rounded 18.36% down, so the Enterprise Support costs are slightly low.) Assuming you’re not a writer and you want to play with the numbers, here’s what you’ll see. If the COLA is 3%/year, the costs of either kind of support will be very close for a long time to come. If the COLA is 1%, Standard Support will be quite a bit cheaper. And if it is 5%, Standard Support will be quite a bit more expensive.
It’s confusing, I know, but it’s true. If the COLA is 5%, then “18%” support will cost more than “22%” support. If the COLA is 3%, then “18%” support will cost about 2% less than “22%” support. And if the COLA is 1%, then the lower tier of support will cost about 10% less than the upper tier.
So what will it be. 5%? 3%? 1%? 0%? At the press conference, SAP didn’t say. There is no commitment to impose these increases and there is no commitment not to impose them. SAP, according to Léo Apotheker, “[has] the liberty of linking Standard Support [] to the cost of living index.” (Thanks Information Week.) Whatever their decision, the imposition of COLA will not be uniform. The cost of living index is the index for the country whose currency is the master currency for the contract, and the actual linkage to this actual index depends on the contract language, which varies.
So what are we to think? Whatever SAP is doing, it is not a U-Turn, and it is not a rescission of the price increase. It is offering customers a new choice, which I’ll characterize as follows:
1. Return to Standard Support and get less support than you got with Enterprise Support (though how much less is unclear) and price increases in the form of COLA (though how much increase is unclear).
2. Stay with/sign up for Enterprise Support and get more support (how much more is unclear, but I’ve been posting on this and will post more) and definite, clear price increases in the form of increases in the maintenance percentage.
It’s a choice. But is it really the sort of choice customers want?
And is offering this choice really an example of a commitment to customer satisfaction?
How the Independents Help Gartner
November 14, 2009
Over the past few years, a cadre of “independent” analysts have set up shop and started to speak frankly about the enterprise application vendors, in their blogs and tweets. You know who I’m talking about: Vinnie, of course, and Dennis, and the Enterprise Irregulars, and Brian , and many, many others. These people were really good analysts to begin with–I’ve known them for years–and they have found their more-or-less independent status freeing, so they write the best stuff that is out there.
So if they’ve got a better mousetrap, why is it that the big guys, Forrester and Gartner, just seem to roll on and on, happily enough? Why haven’t they folded, the way the portable CD player did when the iPod came out? In the free market, after all, shouldn’t consumers pick the best quality at the lowest prices?
I got an interesting answer, yesterday, when I attended a talk at Harvard by Marc Flandreau, who is at the Graduate Institute of Development and International Studies, Geneva. Marc is an expert on bad-mouthing, or as we like to say in English, “blackmail.” And he has a fascinating historical explanation of how pay-to-play can emerge in information markets.
Marc’s focus is the wild and woolly bond market in Paris pre-World War I, a market that was deeply affected by the emergence of a free (or at least libel-free) press in France, post 1880. At the time, it was so easy to start and print a newspaper cheaply that a new kind of blackmail emerged. It was, essentially, “Pay us, or we’ll say bad things about you.” The very relaxed libel laws at this time made this a genuine threat, and people (Marc shows) really did make money doing it.
In the financial markets, the threat took the form, “Mr. Russian Government, pay us, or we’ll publish an article saying that you’re losing the then-active Russo-Japanese war.” And, as it turns out, the Russian Government paid up. The records, which were published in the 1930s, show that the government’s expenditure on publicité went up by a factor of two or more during that period, over what would “normally” be expected.
The interesting thing, though, is where the money went. Essentially, a set of what we would now call unscrupulous PR men (possibly, a redundancy, I admit) who took the blackmail money and distributed it among the press.
Now, here is the rub. Most of the money apparently went to the most reputable, most stable, and most expensive financial journals, not to the blackmailers. What these people tried to do with the bribe money was to make blackmail expensive, by “supporting” an alternate, established, reputable forum, which people would look to for authoritative information, and the existence of this forum brought the threat of blackmail from the cheap-sheet vendors down to acceptable levels.
Flandreau demonstrates fairly convincingly that while some money did go to throw-away (sometimes one-issue) newspapers, most of the money went to those journals and was a significant source of income for them.
“So if I may paraphrase,” a Harvard professor said, after hearing this, “The National Enquirer is one of the things that keeps The New York Times alive.” Marc replied in the affirmative.
Marc’s broad conclusion is that a pay-to-play industry will emerge whenever there is a significant threat from “badmouthing.” (He cites Moody’s as a modern-day example of the same phenomenon.) In all these cases (I think movie stars of the 1920s are another example), the best strategy for coping with badmouthing is to support cooperative, but reputable mouthpieces who will then be a permanent counter to whatever bad things are said by the smaller, less reputable people. In his analysis, the accuracy of what these smaller, less reputable people say is irrelevant; it could be true, it could be false. What matters is that you can exert some control over the best people in the industry.
Anybody who has ever taken a PR class already knows this, of course. But what Flandreau contributes are two simple, but odd facts. The premiums are in fact very large, and MOST of the money goes to the larger, more reputable firms.
So what does this mean for Dennis and Vinnie and Brian and Michael Krigsman and Helmuth Gümbel? Well, pretty much it means that their efforts are enriching Gartner and Forrester far more than it enriches them.
Dennis says in a recent tweet, “Pay to play doesn’t cut it.” Sorry Dennis, in this case you’re just wrong. If Marc is right (and I have no reason to think he isn’t), what you’re really doing is supporting the pay-to-play industry.
Two Cheers for Léo
November 2, 2009
The German Financial Times today took a bead on Léo Apotheker, SAP’s CEO, saying that on his watch, SAP had lost touch with its roots [verlorene Wurzeln]. No longer, as in the days of Hasso Plattner and Dietmar Hopp, is SAP customer-focused, the article says, and as a consequence, customers no longer think the software is worth the money. (The article cites the current customer unhappiness about increased maintenance prices as evidence for this.)
Helmuth Gümbel, no stranger to this blog, is cited frequently in the article; clearly, he was persuasive about the current state of affairs between SAP and its customers. Clearly, too, one disagrees with Helmuth at one’s peril.
Still, I wonder whether it’s really fair to hang all these problems on Léo. Take the infinitely hashed-over introduction and semi-withdrawal of Business By Design. Léo tends to get the blame for this because he was there on the podium claiming that SAP would get $1 billion in revenue from this product by, what is it, next year? But he had nothing to do with the original product. He was working in sales when Peter Zencke was put in charge of Project Vienna, and he was still in sales when Nimish Mehta’s team was developing T-Rex (a great product, no question), and he was still in sales when Hasso was insisting that T-Rex be incorporated into Business by Design, and so on.
Certainly, it was injudicious for him to promise that his organization could sell the heck out of a product that wasn’t ready for prime time. But why does this make him responsible for SAP’s lost roots? If anybody lost their roots, it was the development organization, which somehow or other couldn’t build the product it thought it would be able to build.
Don’t blame Léo for problems that were not of his making.
Now, I have my own issues with Léo, as my readers know. But frankly, when he came in, I think he was right about SAP. Too much time and money was being spent on stuff that wasn’t what the customer needed (or wouldn’t sell), and this had to stop. Hence the acquisition of Business Objects, the downsizing, the restructuring in the development organization. All of these things deserve at least one cheer, and I hereby give it. Hip, hip, hoorah.
Where I criticize Léo–and I’ve told him this to his face–is in his view of SAP’s role vis a vis the customer. He thinks what SAP has always thunk, that it’s up to SAP to make the best possible tools and it’s up to the customer (aided by the SI community) to figure out what to do with them. I think this view is wrong; SAP has to take more responsibility for making sure that the stuff works.
Ten years ago, when the heroes of the FT Deutschland article were fully in charge of the SAP business, I agree, SAP didn’t need to do that. SAP knew about businesses and about software, and they could figure out what they should do next without fretting about the problems customers were then having. (Believe me, there were a lot of them.) Today, though, with so much development time and development effort squandered, they can no longer believe that they can just build the right tools and count on the customers to get the benefit. Instead, they need to find out what went wrong with the tools they’ve been building and what needs to be done in the future. And the only way they can do that is to figure out EXACTLY what is preventing customers from getting the value they think they ought to get.
You can see why this problem is so important if you look at the SAP Solution Manager. This product ought to be what justifies the maintenance price increase. But as Dennis Howlett and Helmuth himself have both said, the product itself does not yet do what SAP needs it to do. If SAP really wants to justify this price increase, it needs to figure out why customers aren’t getting the value that SAP needs them to get. And they need to do it fast.
This is not easy; indeed, when I said this to Hasso late one night at an analyst party, he said, roughly, “We don’t know how to do that.” But let me just say, of all the executives I know at SAP, the one who is most likely to figure it out is Léo.
If he can figure it out, he will be able to get his customer base back again; indeed, I think they’ll be cheering, and when we’re convinced, so will I and so will Dennis and maybe even Helmuth. So, just in case this actually happens, let me give my cheer now, before it is actually deserved, as a way of saying, “I think you can do the right thing.”
Hip, hip, hoorah.
SAP, Siemens, and Maintenance Discounts
October 27, 2009
If you were one of SAP’s biggest customers and you found out that SAP was giving big discounts to another big customer, pretty much because they asked for it, what would you do?
Assuming you have at least a room-temperature IQ, that is.
Wait a minute. Let’s be democratic. If you were one of Oracle’s biggest customers and you found out that SAP was discounting maintenance for the asking, what would you do? I mean, you’re an Oracle customer, you definitely have a room temperature IQ.
Still not sure what to do? Here’s a hint. The phone number at SAP headquarters is 49/6227/7-47474. At Oracle, it’s +1.650.506.7000.
“Wait a minute, wait a minute, wait a minute,” I hear you saying. “SAP didn’t start handing out discounts, did they? They raised maintenance prices; they didn’t lower them?”
Perhaps. But let’s try to apply that IQ of yours.
As I’m sure you know, it’s been an bruited about in the media that Siemens was seriously considering the possibility of dropping its maintenance contract with SAP, starting January 1 of this year. Their plan was to have a third party provide maintenance, possibly either IBM or Rimini Street. (For a representative summary of the situation, as reported in the press, see this Market Watch report.)
So what happened? As all of you big SAP customers realize, Siemens had to make a decision September 30. Well, here’s what we know. About a week ago, SAP issued a press release, saying that Siemens had in fact re-upped its maintenance contract for three years.
Case closed, right? SAP doesn’t ordinarily announce maintenance renewals, but the underlying tone was, “Well, we’ve read the stuff in the press, too, so let’s deal with those scurrilous rumors, and issue a press release. After all, Siemens didn’t just come back. They bought more.” End of story?
Maybe. But you’ll notice that the press release doesn’t actually say anything about how much they paid for the maintenance. Indeed, there’s a funny little line about, “based on SAP’s maintenance standards for large customers,” which seems to demand some explanation.
So, let’s pursue it a little further. Is there any further information anywhere about what Siemens actually paid? About the same time as the press release, a post appeared on the Sapience blog. The post said that Siemens had been paying 30 million euros, pre-deal and was now paying 18 million euros, plus some other concessions. If you value the concessions at zero, this is a roughly 40% discount.
Sapience is written by Helmuth Gümbel, an industry analyst who has been following SAP for longer than I’ve been in the business. Helmuth is not an uninterested party here; he offers consulting on how to pay less in maintenance. But he’s also a well-respected figure, a person who doesn’t just say whatever he feels like saying, true or not.
[Full disclosure: Helmut is also a person I regard as my friend, someone whom I see socially on the rare occasions when he's in town.]
So what is one supposed to believe? On the one hand, you can say, “Why believe an isolated blogger, especially when he has an axe to grind?” Then, you assume that the press release is giving you basically the right idea about what happened. On the other hand, you can say, “Where there’s smoke, there’s fire,” and assume that Helmuth (and the Enterprise Advocates, a group that discussed the Siemens situation in its recent webcast, have to have roughly the right version of the truth.
Helmuth isn’t the only source of smoke, here. Kash Rangan, an investment analyst at Bank of America/Merrill, estimated, recently, that 20-25% of customers get discounts on their maintenance payments. (The relevant figures are reproduced in the dealarchitectt blog.
No full disclosure required here. I have only a nodding acquaintance with Kash.
Of course, all this can be pretty muddy. American accounting rules tend to make it difficult for companies to give direct discounts on maintenance; basically, if a maintenance agreement is part of the initial license contract and the stated price of maintenance isn’t supported by objective evidence, companies are supposed to recognize the license revenue ratably, not all at once. If you give discounts, then your ability to demonstrate that the stated price is supported by objective evidence, is called into question. So, contra Kash and Helmuth, you could argue that SAP can’t be giving out discounts, because it would screw up their reporting.
But of course there are ways of discounting maintenance without actually charging less than the stated price. There is, for instance, a long, long history in the software business of handing out free seats, instead of cash, when customers are unhappy. (Both Helmuth and a cynical reading of the press release suggest that something of the sort may be going on here.) If pressed, vendors have also been known to reduce the basis for the maintenance charge and also to fiddle around with start and stop dates. I’m not saying that’s going on here–I don’t know–but I’ve been told by reliable sources that it has been done, at least by some companies.
If that were the case here, then Helmuth’s way of characterizing it is really the only sensible way to figure out what’s going on. You look at your outflow before. Then you look at your outflow afterward. The difference gives you a gauge of what the discount is.
So did Siemens get a discount? The plain fact is that we don’t know for sure, even with all that IQ, and won’t know unless SAP and Siemens agree to tell us, and even then we won’t know, because the one thing we can be sure of is that SAP will present the case in a way most favorable to them.
So, if we don’t know for sure, and yet it seems possible that in fact SAP is giving discounts, what should you do? Well, I have a suggestion. It’s 49/6227/7-47474. See what they say.
But don’t hide it. Post what they say right here. If SAP really is holding the line on disounts, well and good. But if they’re giving them out, don’t you think it’s time for you to get in line?
SAP Maintenance and the Sol Man (I)
October 22, 2009
With Siemens asking for and apparently getting a huge break on SAP maintenance costs, it is time to take a look once again to take a look at the whole issue. Understandably, there is a lot of emotion and name-calling and confusion around this; it’s not quite the health-care debate here in the United States, but the real issues have been buried under rhetoric in a strikingly similar way.
SAP Charges for Improved Support
Let me first state SAP’s position as sympathetically as possible. SAP believes (quite correctly) that the customer’s TCO (total cost of ownership) ought to go down, as software and hardware gets better and cheaper. It also believes that if it does something that would help TCO go down, it should get a share of the benefits.
Who would disagree with either point?
Roughly two years ago, therefore, it introduced a series of software and support improvements that it believed would indeed reduce TCO. These improvements largely revolved around a newly improved version of the Solution Manager, a piece of software that is supposed to do what its name implies.
The Solution Manager (or Sol Man, as it is called familiarly) was actually introduced roughly ten years ago. In its original version, it was a separate piece of software (one that ran on its own Windows box) that one used to communicate with SAP support (filing bug reports, etc.) and to monitor the performance of your SAP installation.
In the version introduced two years ago, the Sol Man EE (or enterprise edition), it did considerably more: it allowed you to do more extensive monitoring, test and manage upgrades, and even document your business processes. This new edition also beefed up the connectivity with SAP Support, so that support could use it to troubleshoot your installation more rapidly and effectively.
When SAP introduced its new, higher-priced Enterprise Edition support package, it placed the Solution Manager EE front and center. In every speech and every press release, it wasn’t, “We’re raising prices because Oracle got away with it.” It was, “We’ve developed new tools and support services based on those tools, and we’re increasing the cost of maintenance, because the maintenance has improved.”
The tools it was referring to were the various components of the Sol Man EE, and the improved support services were made possible by and delivered through the Sol Man.
To sum up, SAP’s position is that it is improving enterprise support by providing customers with new and better support tools. It is in the software business. So it is only reasonable for it to charge for those tools. That it charges via a maintenance price increase rather than by charging for the product itself is reasonable, presumably, because many of the benefits involve improved services, which are provided through the maintenance contract.
The Customer Reaction
It’s just a plain fact, of course, that nobody paid much attention to this. It took me, for instance, almost a year (until John Krakowski’s excellent presentation at ASUG last May) to figure out what SAP was getting at when it talked about new tools. (Before that, I wrongly, but honestly believed that the talk about tools was pure hand-waving.)
Other commentators on this, like Vinnie Mirchandani or Ray Wang or Dennis Howlett , may have gotten to a proper understanding of the argument faster than I did, but for the most part, they didn’t try to address its merits.
Today, for instance, the Enterprise Advocates, gave a webinar on Reducing SAP Maintenance Costs. (The Enterprise Advocates include the aforementioned three, plus Frank Scavo and Oliver Marks.) Not once during the main body of the talk did they even mention SAP’s recommendation for reducing maintenance support costs, which is to implement the Solution Manager and use it.
I don’t blame the advocates for this; it’s not their job. But I do blame SAP. If the Sol Man is what justifies the price increase, then SAP need to explain this in clear language.
Once SAP fails to do this, the Advocates and the SAP customer base are entitled to believe what you and I would believe when somebody offers an unclear explanation for something that seems to require some explanation: they dismiss the explanation that’s offered.
At some point, though, it does seem that someone should give SAP the benefit of the doubt and ask the question that SAP wants you to ask, namely, “Can the Sol Man EE deliver so much benefit that it justifies the maintenance price increase?”
If the answer is, “Yes,” that would of course be the best thing all around. Customers would have a clear path to reducing maintenance costs. SAP would have a product that keeps its customers paying maintenance. Total cost of ownership would go down.
And the Answer Is…?
Over the past four months, I’ve spent a fair amount of time finding out what I could about the Sol Man. I don’t have access to the documentation (all 1000 pages of it), but I do have the more public documents that SAP has issued, and I have talked to a number of Sol Man users and consultants.
What I found out is so complicated, and this blog is already too long. So I’ll delay a full report to another post. But here’s the answer in a nutshell:
1. To get the benefits of the Sol Man absolutely requires significant investment on the part of the customer.
2. It does not appear to be the case that the Sol Man was designed with the goal that SAP now has for it top of mind. It appears to be a product that was designed to be one thing that is now being turned to a different purpose.
3. The areas of benefit that the Sol Man promises are indeed important, and it is at least possible that customers can get significant benefit from it, if they put in the work.
4. At the end of the day, though, it appears to this humble observer that SAP needs to put more skin in the game.
Hope all this whets your appetite for the next post on the subject.
Home Depot and Twitter
October 20, 2009
Some thoughts on how (at least one) corporation is reacting to the promise of social networking, in particularly Twitter.
The story begins at Home Depot late one rainy night. I am standing in the only manned checkout line, waiting and waiting for a teller who is checking and rechecking and rechecking. I can see the many self-service checkout lines, but I know better than that, and as all the other customers try those lines and #fail, I smile a little secret smile, as the line behind me gets longer and longer.
I am buying some containers and a cheap hedge trimmer, for my little, tiny hedge. The teller very carefully, painfully carefully checks the containers and then says to me, “ZASDFn avaerpih, awern p[i oubioub esters?” I have literally no idea what he’s saying. I say, “Pardon,” and I get another stream of syllables in some language I don’t know. “I don’t understand what you’re saying.” Again. “Just ring it up.” Again. “No, no, no, just ring it up.” Again. “I do NOT understand what you’re saying.” Again. “No, yes, whatever.” The word, “Yes,” works like magic. Up goes the hedge clipper and, as it turns out, up goes a warranty charge on my bill.
I can’t say at that point that I was the model of decorum and common sense that I try to be in my blogs. It is very late; the only reason I was there was that a neighbor had persuaded me to give him a ride to Home Depot. I will draw the curtain of charity, as Mark Twain says, over the rest of the scene, except for one moment. After I get in my last comment, the teller straightens up and says, “Thank you very much, sir; we appreciate your business,” in English that has only a trace of an accent.
This sounds unbelievable; I wouldn’t believe it if it hadn’t happened to me. I can only assume that tellers got a bonus for each unnecessary warranty they sold and that he had figured out an unbeatable technique.
So, the next day, I Twitter about it. I can’t tell the whole story in 140 characters; it was more a, “You can get ambushed anywhere” sort of tweet.
I don’t think Home Depot is listening, but in seconds, there was the response. “We’re so sorry we failed you; how can we help?”
A happy ending, an apologetic store manager, an upgrade offered on my hedge clipper? Of course not. You see, Home Depot wasn’t actually geared up to deal with my experience, weird and truly troubling as it was. It was only geared up to respond quickly when somebody twittered a complaint.
Now I understand this. I know that Home Depot is going through a tough time, that it is a troubled company anyway, and that thinking about the opportunities that Twitter suddenly offers is the last thing on their minds. I bet they’re patting themselves on the back just having somebody on staff who can read tweets and respond to them, and who knows, at this stage, maybe they should be.
All I’m saying is that they missed an opportunity. Obviously, they have a problem in their store operation, a pretty extreme problem. Obviously, it’s the sort of problem that might take a long time to ferret out. Here was somebody who had found a way to tell them at least that the problem existed and who would have been willing to explain. But all they did was view this tweet the way some politician’s handler would view it, as potentially bad publicity, which needs to be countered right away.
They could have done better.
Selling Brittle Applications
October 7, 2009
Has it ever occurred to you that software salespeople get a bad rap? In the popular imagination, they have blood dripping from their fangs. But in my experience, that’s not what they’re like at all. don’t. The ones I know are pretty decent folk, live in the suburbs, maybe even coach soccer. Not one of them would actually throw their mothers under a bus in order to get the deal. At least, I don’t think they would.
So what accounts for this reputation? Well, in the course of writing this series of blogs on brittle apps, I think I’ve come up with an answer of sorts.
Start with a fact that you should know, but maybe haven’t paid much attention to. Good software salespeople don’t sell software. They sell benefits. They don’t try to confuse you with features or functions or architecture; they try to make you understand what those things will do for you.
This is what they should be doing. After all, the buyers of software don’t really know about or understand what the features do, and they don’t have the patience to figure out exactly how the features produce the benefits. You’re a CEO or CFO, you want to get to the point. What is the value that these products deliver?
Software salespeople have developed this reputation, I think, because people have discovered or heard or found that the benefits aren’t available. And they think the salesperson knew this all along and, like some snake-oil salesman was promising a cure for cancer in order to wrest the last dollar out of some old lady’s handbag.
But in my experience, that’s not what’s going on at all. The salespeople actually have a fairly rational, if optimistic view of their product. They know that the products are designed to achieve certain benefits; they can see themselves how the design could work; and they probably know of customers who have achieved the benefits they should achieve. At worst, they’re like a Ferrari or a Jaguar salesman, who focuses on the riding experience and doesn’t feel it is incumbent upon him to bring up the repair records.
People like Dennis Moore would go even further in the software salesman’s defense, and perhaps they’re right. They would say that the salesperson is more like a good physical trainer, who can genuinely promise to get you in better shape if you’ll work out. If after you buy, you don’t want to put in what it takes to get the benefits, that’s your problem not theirs.
So is Dennis right (assuming he would agree with the words I’m putting in his mouth); when somebody buys software and underutilizes or puts it on the shelf, is it entirely their problem. Well, no. I think it would be if they realized how brittle these applications really are. But in my experience, they rarely do. They buy this Ferrari, go out on a Sunday afternoon, and only when they find themselves riding back next to the tow truck driver, do they find out what they’ve bought.
So whose problem is it? Well, I’ve already gone on too long. You’ll have to wait until the next post.
