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.
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.
Delivering Sourcing Optimization
August 6, 2009
It’s a plain fact that there are certain kinds of math problems that even bright people don’t solve very well and computers solve better than we do. Some of these look surprisingly simple. If you’re a retailer, when should you mark down product and by how much? Or if you’ve got to make six deliveries, should you use one truck and make six stops, two trucks with three each, etc.
Entrepeneurs in the world of enterprise software have recognized this fact for a long, long time and have seen an opportunity there. They develop so-called optimization software, which solves an essentially mathematical problem and then provide it in various forms to the market. A few have provided only the engine itself, most of them ending up in I-Log, and many more that provide optimization solutions that address specific problems, like supply chain optimization, markdown optimization, or the subject of this post, sourcing optimization.
Now if there’s one thing that’s completely clear about optimization software, it is that the track record has been disappointing. I’m not just talking about the overpromising and underdelivering that afflicted the big-name supply chain optimization vendors. (No names, but you know who you are.) I’m talking about really wonderful products, like Joe Shamir’s ToolsGroup, which have struggled to put their tools in the hands of people who need it.
Sourcing is no exception to the general rule. In sourcing, optimization came to the fore when companies like FreeMarkets or Digital Freight wanted to set up sourcing “events,” where possibly hundreds of bidders could bid on thousands of line items, offering discounts for bundles of selected lines. What if A bids X for lines 1, 2, and 3, and B bids Y for lines 2, 3, and 4, etc.? This is one of those math problems that linear programming solutions solve better than human beings do.
A number of vendors still in the market place (you know who you are) proceeded to develop solutions for setting up and managing these events, which of course did a lot more than just figuring out which bids to accept. And to some extent, they worked; they did change the way many companies do business, and sourcing events are now fairly normal, with several large companies being big proponents.
But in my (admittedly somewhat limited) view, the optimization piece has been relatively unimportant. Certainly some companies have developed some good optimization algorithms, and they are used, but in the events I’ve seen or heard about, it’s not clear to me that the solutions they offered were actually all that optimal, and the reaction of buyers that I know to the solutions they offered have been tepid, shall we say.
I’m not surprised, as I say, because I’ve seen similar reactions from users of other optimization software.
Now I have a degree in math, and I’ve taken a course in linear programming. I know that the solutions they give you are better than what people can come up with by themselves. So are the people who don’t like these solutions just grousing? That’s certainly what most vendors think.
Well, the other day, I got a glimmer of the answer from some terrific research done by Vishal Gaur of Cornell University. (See my earlier post, “An Automated Replenishment System.”) He found in his case study that a solution produced by optimization software had a highly suboptimal operational effect because it was optimizing around the wrong things. The math was done perfectly, but the problem had been set up incorrectly.
This is always a problem in principle when you set optimization software chugging away. The software draws a box around the problem and finds the point inside the box with the best available solution. If you draw a different box (usually a larger one), the solution will be different, and will take longer to find.
In Professor Gaur’s case, the software developer had drawn the wrong box around the problem. Now what’s interesting here is that the software developer never knew that he’d done anything wrong. He delivered the software, and the IT people who were using it expressed satisfaction. And you might think, “Well, so what, even if it drew slightly the wrong box, it got roughly the right answer.” But in fact, when you change the box, you change the answer completely. So in this case, the users had to replace (manually) all the solutions the software offered (manually) with better and completely different solutions.
If you have optimization software, in other words, you have to draw the right box, or the answers that it gives you are not better than what you can provide, they are worse, often much, much worse.
Now look at how this applies to sourcing optimization. Let’s say that you set up the problem in one way. (You only allow bids from certain vendors, for instance, and you require that they offer discounts of a certain percentage.) If you draw the box differently, you will come up with quite different answers.
I was discussing this problem with Garry Mansell, president of TradeExtensions, a small sourcing optimization vendor. He argues that the only way of solving this problem is to provide a lot of services, along with the software. The experts that he provides (it just so happens, of course, that he’s in the business of providing this pairing) can keep the sourcing on track and make sure the right box is drawn.
Now I react to most honeyed words from vendors the way I react to offers of honey for my tea. (Hint: “No, thank you.”) But this struck me as roughly right. The problems that I’ve seen with implementations of myriad kinds of optimization software wouldn’t be solved, then, by fixing the software. It would be solved by helping people to make sure that they’re drawing the right box around the problem.
So who knows. Maybe Mansell is right. (Or maybe he’s just selling software. Or both.) But it seems to me to be a useful thing to keep in mind. If you’re looking at sourcing optimization software (or, more generally, any optimization software), don’t buy it and don’t use it, unless you have some serious experts, who can help you make sure that you drew the right box.
Designed for Stability
June 22, 2009
I was just talking recently to a specialty chemical company whose specialty product is used primary by an industry that is now under water. They have a lot of middle-aged systems, and they’re looking for something, anything that they can do in the systems area that can help them out.
We’re talking about a company that needs to contract by, say, 50% until their market comes back.
So what can they do? Well, nothing. But the reason they can do nothing is well worth paying attention to and pondering.
You see, the systems they have–I won’t tell you which one is preponderant, but it’s one of the $AP family, that is, SAP, Oracle, PeopleSoft, JD Edwards, etc.–are all designed for stability. They work well only when things change very little. Change a manufacturing line, get a new big customer, add a new product or two, and these systems can deal; it only takes a few man years of work.
But change the business in some fundamental way and everything breaks. Move a line from one factory to another, and it might actually be easier to move the physical line than it would be to move the data in the old ERP system into the new one.
Chrysler faced this a while back, when Cerberus bought it; now, both GM and Chrysler are having to deal with it. I ran into the problem at an electronics company that was deciding to outsource and at a company that was trying to shift a lot of its business onto the web. Their systems wouldn’t let them change.
Well, it’s a good thing if the company that’s setting up the system is stable, has a product that doesn’t change too much, has reliable customers and a business model that will work for the next twenty years.
Know any companies like that?
It’s a bad thing, though, if your company wants to or needs to change fast. Then your systems will get in the way.
Do people ever think about this simple fact when they’re buying the systems in the first place? I’ve never seen any company that did. Do they think about it when they’re buying a company? I’ve only seen a few. When they’re figuring out whether to consolidate systems, that is, do they consider the tradeoff between the money they’ll save by consolidating systems and the money they’ll lose if they have to disentangle the newly consolidated entities? I’ve never run into anybody who did.
It makes sense, of course. Everybody thinks that things will stay more or less the same. Companies, their employees, the people who sell them systems, the people who design the systems. So that’s what they plan for, build for, and buy for.
The only problem is that much of the time, it isn’t true.
Not only the systems, my dear, but the entire mode of doing business with the vendor.
They come to the conversation talking to me about consolidation; they want to use fewer systems, servers, support personnel, etc.
I don’t think this is going to work; in fact, I think they’re going in exactly the wrong direction.
The Applicator 