Wait for the Next Gen? Yes!
March 26, 2010
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.
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?
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.
Why Develop Brittle (High-Risk) Apps?
September 25, 2009
“Brittle” design isn’t limited to enterprise application software. You can find brittle design in cars, bridges, buildings, TVs, or even the vegetable bin. (What are those 1/2-pint boxes of $5.00 raspberries, 3/4 of which are moldy, but examples of brittle design?)
What do brittle designs have in common? The designer chose to accentuate high performance at the expense of other reasonable design parameters, like cost, reliability, usability, etc. A Ferrari goes very, very fast, and it feels good when it goes fast, and that’s a design choice. And it’s part of the design choice that the car requires a technician or two to keep it going fast for longer than an afternoon.
So why are most enterprise applications brittle? You can see this coming a mile away. It was a design choice. The enterprise applications in question were designed to be the Ferraris of their particular class of application. They were designed to do the most, have the most functionality, be the most strategic, appeal to the most advanced early adopters, be the most highly differentiated, etc.
To get Ferrari-like performance, they had to make the same design choices Ferrari did. They had to assume the application was perfectly tuned every time the key was turned, and they had to assume that the technicians were there to perform the tuning.
Enterprise applications, you see, were intended to run on the best, the highest-end machines (for their class). They were intended to be set up by experts. They were intended to be maintained by people who had the resources to do what was necessary. They were intended to satisfy the demands of good early-adopter customers who put a lot of pressure on them, with complex pricing schemes or intricate accounting, even if later on, it made setting the thing up complex, increased the chance that there were bugs, and made later upgrades expensive.
This wasn’t bad design; it was good design, especially from the marketing point of view. The applications that put the most pressure on every other design parameter got the highest ratings, attracted the earliest early adopters, recruited the most capable (and highest-cost) implementers, etc., etc. So they won in the marketplace and beat out other applications in their class that made different design choices.
I lived through this when I worked at QAD. At QAD, the founder (Pam Lopker) made different design choices. She built a simple app, one that was pretty easy to understand and pretty easy to set up and did the basics. And for about two years, shortly after I got there, she had the leading application in the marketplace. And then SAP and JDE and PeopleSoft came in and cleaned our clock with applications that promised to do more.
Now, none of the people who actually bought SAP instead of QAD back then or chose (later) to try to replace QAD with SAP did this because they really wanted high performance, per se. They wanted “value” and “flexibility” and “return on investment” and “marketable skills.” They literally didn’t realize that the value and flexibility came at a cost, that the cost was that the application was brittle and that therefore, the value or flexibility or whatever was only achievable if you did everything right.
If they had realized this, would they have made different choices?
I don’t know. I remember a company that made kilns in Pittsburgh that had been using QAD for many years. The company had been taken over by a European company that used SAP, and the CIO had been sent over from Germany to replace the QAD system with the one that was (admittedly) more powerful. He called me in (years after I had worked at QAD) to help him justify the project.
I looked at it pretty carefully, and I shook my head. Admittedly, the QAD product didn’t do what he wanted. But I didn’t like the fit with SAP. I was worried that the product designed for German kiln production just wasn’t going to work. I didn’t want to be right, and I was disappointed to find out that two years later, despite very disciplined and careful efforts, he was back in Germany and QAD was still running the company.
I’m glossing over a lot, of course. There are secondary effects. Very often, the first user of an application dominates its development, so the app will be tuned to the users strengths and weaknesses. It will turn out to be brittle for other users because they don’t have the same strengths. Stuff that was easy for the first user then turns out to be hard for others.
Two final points need to be made. First, when a brittle application works, it’s GREAT. It can make a huge difference to the user. Brian Sommer frequently points out that the first users of an application adopt it for the strategic benefit, but later users don’t. He thinks it’s because the benefit gets commoditized. But I think it’s at least partially because the first users are often the best equipped to get the strategic benefit, whereas later users are not. I think you see something of the same issue, too, in many of Vinnie Mirchandani’s comments about the value that vendors deliver (or don’t deliver).
Second, as to the cause of failure. Michael Krigsman often correctly says that projects are a three-legged stool and that the vendors are often blamed for errors that could just as easily be blamed on the customers. Dennis Moore often voices similar thoughts. With brittle systems, of course, they’re quite right; the failure point can come anywhere. But when they say this, I think they may be overlooking how much the underlying design has contributed.
It may be the technician’s fault that he dropped the beaker of nitrogycerin. But whose brilliant idea was it to move nitroglycerin around in a beaker?
Spend Less Money on the Buying
July 22, 2009
This is one of a series of posts on the high cost of buying enterprise applications and the high cost of selling the products. This high cost, I’ve been arguing, is just plain bad for both sides and almost certainly unsustainable. So the question for the analyst is, “What can be done about it?”
In the background, I’ve had a lot of discussion with industry pundits and the Twitterati: Vinnie Mirchandani, of course, and Jason Busch and @dahowlett and Brian Sommer and Dennis Moore and many others who don’t regularly comment over the airwaves. What accounts for the high cost, I’ve been asking? Two answers seem to emerge.
1. Too many cooks.
2. Too little trust.
If you’ve ever been involved in buying applications, you’ve seen the first one happen over and over again. Too many people get involved with the decision, each with their own agendas, each more or less connected to one of the contenders, and getting all these parties to agree requires too much head-banging. It’s Congress trying to pass health care, writ small, and it’s just as pathetic.
The lack of trust. Well, I get why people don’t trust, and I get why they erect structures that are supposed to control the vendor. But in my experience, it’s always been a losing game. Buyers are nowhere near as devious, oops, I mean sophisticated, as sellers–how could they be, the sellers do it for a living? So if you go into a deal, it’s natural to feel skittish, but giving in to the feeling doesn’t really protect you and does slow you down.
So what’s to be done? In the long run, you can’t do much about either problem without cooperation from the other side. If you’re going to have lots of cooks, the cost of sales for the vendor is just plain going to be astronomical, and the cost of buying will rise accordingly. If the vendor behaves in what has become the normal fashion, alas, defensive (and expensive) buying will be only too appropriate.
Granting that, you have to start somewhere, and here are some suggestions for the buyer, suggestions that should save money. All of these will really help, even though the second sounds completely ridiculous.
1. Limit the scope of what you’re buying as much as possible. Look only at what you clearly need; prefer things that you’ll use immediately; go for immediate results; and don’t buy anything else. You can always buy the rest later. (This reduces the number of cooks.)
2. Use a tape recorder and a camcorder. Keep track of what the vendor says, in full, precisely. Look the transcripts over. If you have questions or don’t understand, follow up. In the long run, it saves a lot of time. (This can help you to get more trust–kind of trust, but verify.)
3. Prototype, prototype, prototype. Get a small team to set it up and try it out, rather than assembling a large team to review demos that were set up by the vendor. If you have to pay the vendor to help you with the prototype, do it. You’ll save in the long run. (This, too, reduces the number of cooks.)
Enough from me. Suggestions from the readership are welcome.
Lower the Cost of Sales!
July 3, 2009
In many previous posts, I have complained, bitterly, about the sales tactics that every enterprise application vendor uses, mostly to defend aging, poorly designed products. It’s one thing to put lipstick on the pig, I’ve essentially said, but it’s outrageous to charge admission, just to see the pig.
This is, of course, what happens in most sales situations. Companies big and small buy the software through a highly-paid salesperson, part psychologist and part snake-oil salesman, who listens to you, discusses your pain with you, and then arranges a long, long process that you and your team will go through: functionality requirements and demos and business cases and who knows what all.
Let me fill you in on a little secret. It’s mostly a waste of time. And money. Not just your time and your money. But also the software company’s. You are both driving up the cost of software, simply by accepting and perpetuating a system where rigmarole is the rule of the day.
In a time of economic growth, maybe both companies could afford it. So what if you use up a lot of IT hours compiling functionality lists and sleeping through demos. (Who could stay awake in them?) The IT guys like it well enough, and they like to be asked for input. So what if the software company wastes a lot of, er, resources flying in executives or taking the team out after all their hard work to a place where attractive women perform. (Happens, believe me.)
In a time of economic frailty and, not coincidentally, a time of doubt about the value and merits of enterprise software, no one can afford it any more. Not you, who has better things to do with your resources. Not the software companies, whose sales resources are being spread thin by companies that are insisting that the salesperson do more and more for them.
Wouldn’t it be better to use some of the resources squandered on these endless sales cycles for something else a little more worthwhile? LIke getting both parties to the right solution faster?
Don’t Buy Unless You Try
July 2, 2009
A product manager at an up-and-coming software company was talking about his experiences at Siebel, where he cut his teeth in that job.
“At Siebel, we would never, ever, ever let a customer take a look at the software. No way. Not ever.”
At his new company, by contrast, they give out free personal copies.
Now, which would you pay more for, software that you know works, because you tried it, or software that you can’t prise out of the company’s hands unless you fork over, big time?
Not sure what the answer is? Well, what if I told you that the success rate for the second kind of software was roughly 50%. So 50% of the time, forking over is just like sending money to that friendly Nigerian guy who seems to need some help.
Still not sure? Well, what if I told you that the software company made you sign a non-disclosure agreement about the software that you had just forked over for, which said, essentially, that no matter what you find after you forked over, you can’t tell anybody about it. Wouldn’t you think that maybe, just maybe, that was eau de rat that you were sniffing?
Well, if after all of those warning signals, you went ahead and bought, don’t think I’d call you a fool. You’d only be doing exactly what everybody who ever bought from Siebel did. And nobody would ever call those people fools.
Would they?
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,
An Automated Replenishment System
May 8, 2009
There’s an assumption, these days, that systems whose basic design principles and strategies have been around for twenty years are, by this time, working pretty well. If you think that, consider the following.
A person I know well was asked to evaluate the effectiveness of some automated replenishment software at a retailer of his acquaintance. The automated replenishment system had been built to optimize inventory levels, so it automatically asked for replenishment when inventory was low.
What he found was that the store managers were systematically ignoring the replenishment requests and overriding them. Hah. We all know about this, right? Stupid, willfull store managers ignoring the mathematically sophisticated system that was calculating real supply and demand. The real trouble with business is people, right?
Not at all. It turns out that the best way to optimize inventory levels is to delay orders. (First day, Supply Chain 101). The peak days for the stores were Thursday, Friday, and Saturday. Since the stores got daily deliveries, taht meant that the peak replenishment days were…Thursday, Friday, and Saturday. Unfortunately, the store managers didn’t want deliveries on those days. They didn’t have the staff for it. They wanted deliveries on slow days, when the staff would be available for it. So every week, they were going into the system and moving the replenishment requests forward to Monday and Tuesday. Every single week. For thousands of SKUs.
Now there’s a good use for managers’ time.
My friend is a skeptical sort, though very helpful. So before throwing up his hands, he tried to decide whether they were doing the right thing. He wrote an optimization algorithm that optimized deliveries based on inventory levels AND labor costs. Guess what. The store managers were doing exactly the right thing. His algorithm slightly outperformed the managers, probably because they had to do all that changing by hand. But the outcomes (the actual outcomes by the store managers and his theoretically optimal outcomes calculated by his algorithm) were very close.
And yes, he did leave the algorithm behind him, so now the managers don’t have to do it by hand any more.
So here’s what we know. Basically, the people who wrote the automated replenishment system had done a bad job. They had written an “advanced,” “automated,” replenishment system that optimized decision-making, but they had optimized on the wrong thing. So instead of providing a system that did optimal, automated ordering, they created a system that generated thousands of orders, each of which had to be corrected by the highest paid person at the store.
And until my friend came along, nobody seemed to know about it.
Now, I’m not saying who is responsible for this, whether it is a commercial replenishment system or a custom-built replenishment system. But what I can say is that all the commercial replenishment systems that I know about do it in exactly the same way; they optimize around inventory levels.
Why do they do that? Well, for one thing, the system is self-contained. They have the inventory information available in the same system, so adding in an optimization doesn’t require any integration.
For another, the people who are building systems like this do not think like retailers (even though their customers are retailers). If they did, they would realize that the orders need to be staggered.
And for another, neither they nor their bosses nor the people who bought the system never, ever followed up on what they did. If they had followed up, they would realize that the system they built was not doing the job that it should.
What it should have done is generate the right orders automatically. But all it was actually doing was generating template orders all of which had to be inspected and corrected by hand. It wasn’t a complete wash. It did generate orders with roughly the right amounts (over a week). And, because of the way the system worked, some of the corrections were relatively rapid. (Sometimes, if you moved two orders forward, subsequent orders would automatically self-correct, because the system would reduce subsequent orders by the amount that had already been ordered.)
So is this some isolated instance? I don’t think so. As you probably know, the basic operation and design of these systems has been around for twenty years. All the commercial systems, so far as I know, optimize around inventory, without taking labor availability into account. If this particular system works very poorly because of a design error, there’s every reason to believe that others don’t work either.
If that’s the case, it’s a little scary. There have been a lot of automated replenishment systems put in over the past twenty years, and almost all of them have been justified by the claim that they kept inventory levels down to optimum levels. If that claim is wrong (because keeping inventory low necessarily entails excess labor costs), then there are a lot of systems out there that were sold and installed under false pretences and are now being used incorrectly.
The ironic thing about this is, of course, is that only a very little attention to how these systems are being used would not only show you the problem, but also show you the solution. To correct the system, you don’t need to integrate with a labor availability system (that would be hard and isn’t what my friend did). All you’d need to do is write a small program that corrected the timing, using the corrections that the humans were doing already as a guide.
The Applicator 