And While You Wait? What?
March 31, 2010
A few days ago, I argued that a company that wants to replace its old, limping systems with a brand, spanking new Oracle or SAP application should probably wait for the next generation of apps.
The post got a lot of approving comments, which surprised me. I think there are pretty good arguments for just hauling off and buying. Consider what one of these hypothetical companies might say in defense of a decision to buy now rather than later.
1. We’ve got the money now and we should spend it.
2. The product we’ll get will be much more reliable.
3. The cost of services surrounding the product will be lower.
4. We don’t know when the new products will be out (with the possible exception of Workday 10).
5. We don’t know what will be in the new product.
Imagine what idiots we’d look like, the buyer might say, if we waited for five years for a product that was no better than what we could buy today and far more incomplete and buggy.
I see the force of this, which is why I thought it was a close call. Ultimately, I did decide it’s better to wait for markedly better products that are coming, despite the risks and delays. But I saw why people would disagree.
So are my commenters intemperate or am I dithering? One test for this is to look at the case of somebody who is not considering a replacement, but is considering a fairly big investment in the existing platform. Maybe they’re considering an upgrade, or maybe they’re considering some extension products, or maybe they want to push their existing installation out to other geographies.
This is a very realistic case. Several companies I know fairly well are considering one or more of these options. One is upgrading to Oracle 11i; another wants to upgrade to Infor LN. Still another wants to extend its QAD implementation to another geography. Still another wants to buy a CRM system from its existing vendor.
For each of these companies, the details matter a lot, but on reflection, I think the same argument applies. It will be hard to get the return on this big new investment in the old platform, because the useful life of what is to you a new product is not long enough to justify the expense.
This raises two questions. First, how does one calculate “useful life.” Most of the companies I’m thinking of believe that the useful life is defined only by how long they’re willing to use it, and for some companies, that’s pretty long. (There are, after all, big SAP clients who are still using R/2.) I think this is wrong, but I’m going to have to hold off explaining why till a later blog.
The second question is, “Assuming that the commenters and I are right, what kinds of investments should companies who have decided to wait actually make?” I have no determinate answers to this, but I think there are some guidelines.
Start with Gavin’s comment on the previous post. Gavin points out that some investments in the Oracle infrastructure and in new Fusion-based products will actually take you toward the next Oracle generation. He is quite right; Oracle designed things this way, and partly because of the problem that I’m describing, they quite deliberately created some ways of investing in products from Oracle without locking yourself into an older technology.
There are many, many caveats, of course. Among other things, if you have an Oracle system now, you might not want Oracle in the future. The three main products I mentioned in the earlier post (Workday, Business by Design, and Fusion Applications) are all highly differentiated, each with its own flaws and virtues. A rational person would do well to look at all of them before deciding to stick with the vendor they have now. (This applies to SAP customers, too.)
Even if you are bent on Oracle, you still may want to take some time thinking through your infrastructure stack before investing in pieces of it. Even the examples Gavin gives like OpenID, which are likely to be pretty good, may not be right in the long run, and if they aren’t, that will be a lot of trouble and expense gone to waste.
You should note that Gavin’s argument almost certainly will apply to SAP, as well. SAP is also workng on “hybrid” intermediate solutions, and I’ll bet you dollars to donuts that they’re trying to figure out every way they can to ease the migration to the new system by asking you to make steady, rational investments in products that extend your current capabilities.
But what about customers for whom an infrastructure or extension investment isn’t right? Here, I think there are some interesting arguments, akin to Gavin’s, for small, light cloud-based apps, point solutions designed to solve highly specific problems. I’m not just talking about a CRM app or a call-center app or a recruiting app; I’m talking about things that are very, very specific to your industry, but really powerful, things like Tradestone in the apparel industry.
Another possibility is to spend some time and effort cleaning up your existing installation. This will improve its current effectiveness, extend its useful life, and very possibly lower the cost of the new system significantly. (A lot of the cost of any implementation is cleaning up after the mess left by a system that everybody has given up on.)
There’s a very smart analyst in Europe, Helmuth Gümbel, who has spent a lot of time thinking about this problem. He has a blog, and he also has a conference, Sapience, which goes into these questions at length. If you’re thinking about extending your current ERP to other geographies, a reasonable alternative might be to find lower-cost ERP systems to serve those geographies.
The basic theme running through these latter approaches is that while you’re waiting, you can focus on saving some money and preparing your current installation, thereby making the later transition to a newer technology faster and more affordable.
Brittle Applications
August 31, 2009
In a previous post, I said that MRP was a “brittle” application, and a commenter questioned me. What is a “brittle” application? Is this a technical term? What makes MRP brittle? All good questions.
A brittle application is one that doesn’t work at all unless a lot of disparate conditions are met. MRP, for instance, doesn’t work unless all the data is right, people know how to use the program, the demand for the products is stable, purchasing is also committed to minimizing inventory levels, etc., etc.
The notion applies to a lot of other programs besides MRP, though I’ve rarely heard the term used. But notice that it brittleness isn’t so much a feature of the program as it is the purpose to which the program is put.
Let’s take a simple example: a word processing program. For normal purposes, a word processing program in this day and age is not brittle. A rank novice can use it to type and print. But even today, if you want to use, say Microsoft Word, to put out a 16-page brochure, complete with illustrations, well, good luck, is all I can say. You try to get an illustration and have it float and change the size and put in a table, and–well, just try it, it’s a nightmare. So, to put a 16-page brochure together, Microsoft Word is brittle, but to print out a letter, it’s not.
The point about the MRP program that QAD wrote, which follows the APICS standard religiously, is that it’s brittle relative to the purposes for which it was intended. Pam and Karl and Evan (the founders of QAD) really believed that QAD’s could do supply chain management for manufacturing facilities very effectively. My point was that the program is too brittle. To get things right, you have to get all the data right and keep it right, etc., etc. And if you don’t, what you have is an overwrought and overcomplicated Kanban system, without Kanban’s virtues.
Are there other enterprise application systems that are brittle? Lots and lots of them, I think. Almost all the old, Siebel-style CRM systems were simply too brittle; they depended too much on the good-will of the salespeople, the accuracy of the sales model embedded in the system, the reliability of the sales cycle, etc., etc. You wouldn’t think that financial systems are brittle–after all, they have to work–but they often had components that were overly brittle: cash management systems, for instance, and fixed asset systems and budgeting systems.
What do most companies do when they have an overly brittle system? They use the system for lesser purposes. And they feel REALLY bad about it. So, the Microsoft Word user makes a brochure that is far less fancy, but more manageable, and the QAD MRP user uses the product for tracking inventory. And both of them keep on saying, “Well, one of these days, I’ll get around to really making this product sing.”
They shouldn’t. Brittle applications are brittle for a reason. A lot of the time, it’s because they’re really a special-purpose product, but yours is not that purpose. Some of the time, they’re brittle because they’re badly designed. Some of the time, the model they’re using (MRP is a good example) just doesn’t fit the situation you’re in. In any of the cases, the fact is that they really can sing for the right user, but that doesn’t mean it’s your fault if they don’t sing for you.
What do you do if you have a brittle app that isn’t singing? Give up on it. It won’t work for you. Get another app, one that works. Or change the process. Or just accept the fact that it will never work the way you thought it would.
In any case, good luck.
Is Supply Chain Knowledge Key for ERP Implementations?
August 22, 2009
I used to work at QAD, a small manufacturing software vendor. I subscribe to a QAD chat group, and occasionally people ask questions like the one in the title.
It sounds as if the person asking is peddling something–who knows–but it’s an interesting question nonetheless. What kinds of knowledge are necessary (key) for an ERP implementation? If you run a manufacturing company, is APICS (that is, supply chain) knowledge particularly important?
Certainly, QAD used to think so. When I was an employee, you got a bonus for becoming APICS certified. (APICS is the American Production and Inventory Control Society; to get certified, you had to learn how MRP worked and how inventory should be managed.) And certainly, when the product was designed, the focus was on matching supply and demand. The product was built originally for Karl Lopker’s sandal manufacturing business, and the idea was always to have simple, usable product that managed inventory well.
So you would think that the answer, at least for QAD users, is, “Of course APICS knowledge is key. Duh.” But I don’t think so.
You see, while I was at QAD and then for some years afterward, I looked at a fair number of installations. And what I saw was disheartening, at least if you believed in good supply chain practices. The systems weren’t really using good supply chain practices, at least as APICS defined them.
Let me give you an example, which APICS-trained people will understand immediately. One of the ideas of these systems is to reduce the amount of inventory you have on hand at any one time. To do this inside the system, there are two parameters that you have to set, lead time (which is the amount of time it takes for an order to be fulfilled) and safety stock (the amount you want to have on hand at all times). The longer the lead time or the higher the amount of the safety stock, the greater your inventory expense.
So what would you say if discovered that in not one or even two installations, but many, the safety stock and lead time numbers for most of the inventory were set once, en masse, and then never set again? Well, I’ll tell you what to think. These figures, which are key to making the system work, are not being used.
Now this was not just true of QAD Software; it was equally true wherever I went, no matter what software was installed.
So doesn’t this say that supply chain knowledge is key, after all? If they had supply chain knowledge, wouldn’t they have paid more attention? At first, I thought so. But then after a while, I realized that more supply chain knowledge would have made very little difference.
You see, that’s not why they were using the software. All these companies, it turns out, didn’t really care about getting supply chain stuff right. They managed the supply chain fairly sloppily–tolerated a lot of inaccuracy and suboptimal behavior–and they got along (in their minds) just fine doing that. They didn’t want to put in the kind of care and rigor that is the sine qua non for doing with these systems what they were designed to do.
What were they using the software for? Well, mostly to manage the paperwork virtually. Please don’t cringe, Pam, if you happen to be reading this. This is not a hack on you. The plain fact is that the companies needed to keep track of their commitments (orders), their inventory, and their money, and that’s what they used the system for. They needed a piece of paper that told people what inventory to move that day and where to move it to. And the system gave it to them.
To do this, though, you didn’t need much APICS knowledge or, if you didn’t believe in APICS’s recipes for inventory management, other supply chain knowledge. All you really needed was to be able to count, which most of the users could do without being APICS-certified.
So is supply chain knowledge key for an ERP implementation? Not at all. You can have perfectly happy users who have got exactly the nice simple implementation they need without much supply chain knowledge at all.
This answer, of course, raises lots of questions. What is key? Why do these companies tolerate sloppy supply chain practices? Wouldn’t they be better off if they cleaned up their act. Herewith, brief answers.
What is key? At a rudimentary level, the financials. You have to get the basics right, here, or you’ll never close your books. In a system studied recently by a grad student at Harvard Business School, 65% of the inventory records were inaccurate. Can you imagine the upset if 65% of your account balances were incorrect?
Why do they tolerate sloppy supply chain practices? I think it’s largely because more finely tuned systems are much more brittle. They take a large amount of care and feeding and their ability to take hard, rude, unexpected shocks is limited.
And wouldn’t they do much better using the systems? In many cases, no. You see, at most of the companies I’ve run into, the MRP/APICS model that QAD (and every other software vendor) provided is not actually all that accurate. To make a really significant difference, you need more sophisticated tools that are better suited to the specifics of your supply chain.
Comments welcome.
Don’t Pay Maintenance–and Use the Money For?
June 29, 2009
Top 10 things to use the money for, once you stop paying maintenance.
10. Reducing the backlog at internal support. This doesn’t take much money, of course, since you’re already saving the hours your people had been on hold waiting for the software company to answer.
9. First-Aid. You know all those open, raw spots in your current installation, the ones you hoped would be fixed by the latest version, if you could ever get it installed? Take charge and fix them, ’cause now your former supplier ain’t gonna do it. You’d be surprised what rudimentary first-aid tools can do: a few user exits, a virtual machine for low-profile Java apps that the exits talk to, a little user training, a few reports. You’ll get people back to the front in no time.
8. Raises. You know life just got easier. But that doesn’t mean that you shouldn’t use some of the money to reward your staff for all the effort they put out over the years dealing deal with your former supplier.
7. Shutting down the patch testing environment. Of course, once you do that, you have even more money, so…
6. Buy something you couldn’t afford. Go on, live a little. Here are some suggestions…
5. Invest in mobile. Every one of your executives wants cool stuff on their iPhone (or an iPhone if they don’t have it). Make yourself a star. Give it to them. They’ll go to their graves believing that IT support improved on the day you stopped paying maintenance.
4. Invest in the cloud. Face it. With the end of enterprise support, you don’t have an excuse not to do development that you can’t afford to do. So start by reducing the cost of development. With EC2 or Force.com or Rackspace, you can suddenly start doing it right, that is light and cheap.
3. Don’t invest in social networking. But do take the shackles off. Spend a little, tiny bit of money encouraging people to figure out what they ought to be doing with these new tools (if anything). And maybe use some of the tools to help everybody keep track of the efforts.
2. Return some of the money to the CFO. He or she has been walking around the halls looking for some spare change. Now you can reach in your pocket, pull something out, and feel good for the rest of the afternoon.
1. Hold a check-burning party. Write out 10 of those big checks made out to whoever it is, go out to the parking lot, and reduce them to their constituent elements. Hint: bring some beer.
Got your own suggestions about what to do with the money? Add some comments here.
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.
Only Thought Required
March 30, 2009
Some 10 years ago, a colleague at the small consulting firm where I worked “brought over” a sample requirements document and selection process from the large consulting firm where he had worked. They were pretty bad then, hopeless now, but the amazing thing is that they’re still being used. You can find copies (authors’ names removed) on the Internet.
You all know what they look like. You use them. If you’re just buying an application or replacing an application or maybe adding an extension, you score up the candidates based on a spreadsheet, giving due weight to the quality of service, the viability of the company, the price, and, of course, a long list of functional requirements. The company with the highest score wins.
Bunk, bunk, bunk, bunk, bunk.
First of all, the process overwhelmingly favors the large companies, like SAP and Oracle, because the companies are more “viable,” and the service organization is nominally bigger.
But it isn’t that that kills me. It’s the functionality requirements. You see–and this has been true for 20 years now–most of the functionality requirements don’t matter. The only things that matter are what you might call, “Derailers,” that is, bits of functionality without which your operations are derailed.
Let me give you a couple of examples. Years ago, Avon wanted to buy SSA and did. Avon, as you probably know, sends out a circular with a list of items and prices some 15 times a year. With every circular, the price changes. So unless you could vary the prices depending on which circular you ordered from, you had nothing. SSA couldn’t, and that’s what Avon bought. They put some astronomical amount of money into “customizing” the application, but it didn’t work. The project was derailed.
With any application purchase, those derailers are what matter. Sometimes there are 5; sometimes there are 10. But unless the app you’re buying can do all of them correctly, don’t even bother to buy them.
Unfortunately, the standard way of buying apps masks this simple fact completely. Most of the time, the requirements are long, but nowhere near detailed enough. So by the time a weary group is asking a vendor to demo what matters, they rarely get down to whether the functionality actually works the way it must. At Avon, for instance, all they asked about was “price lists;” they never asked whether the price lists could be attached to a circular.
Worse, even if you figure out that the derailer doesn’t work, the weighting methods that are always used can sometimes lead you to ignore the problem. The fact that the vendor does do 6 of 7 things or 25 of 26 things or 131 of 135 things makes you ignore the fact that IT DOESN’T DO WHAT MATTERS.
What is required instead of requirements documents? Thought. All you have to do is figure out what the derailers are. Then gauge the competitors only on that.
Should App Prices Go Down?
March 17, 2009
This is the first in a series on $AP* and the basic $AP* value proposition.
Or lack thereof.
The series is called, “Don’t Buy $AP,” because my thesis is that the value proposition just isn’t very compelling for new buyers.
This isn’t a new idea with me. I’ve felt for a long time that it’s hard to get your money’s worth from back-office apps. I’ve also felt that the claims the vendors made about the value of their products were, shall we say, optimistic.
But in an apps environment where almost everybody (IT, the vendors, the pundits) is pretty committed to believing in the value, I’ve chosen to ignore these feelings.
No more. I don’t owe the enterprise vendors anything, and I would like to help people buy smarter, so I’m going to try to figure out, in this series, whether there’s anything to these intuitions. If I dig down a little bit, maybe it will help customers buy smarter. And who knows, maybe I can get some intelligent reactions that will show me where I’ve gone wrong.
I can’t cover everything at once. So let me start with something that really puzzles me.
We all know that prices for a technology ought to go down as the technology gets older. But that doesn’t seem to be true with enterprise apps. SAP* has entered middle age, yet the prices for SAP* have stayed steady or gone up.
Think about it. The core, Unix-based SAP product on an open-systems platform that ran financials and kept track of inventory was developed around 1990, and the product pretty much stabilized at Version 4.6, in the late 1990s. The price then was about $2500-$3000/user with 17% maintenance, if I remember correctly, and today, it’s about $2500-$3000/user with 22% maintenance.
That doesn’t seem right to me. You see, part of the value of a complex product lies in one’s estimate of the useful life of the product. You pay more for a Mercedes partly because you know it will last longer and retain its resale value. So if you were buying SAP back in 1995, let’s say, you were buying a 5-year-old product with a fairly long useful life ahead of it. At the time, let’s say, people thought the average useful life of an ERP system was 7 years, but with SAP, you figured that there’d be a longer useful life and that would partially justify the premium price. So surely some percentage of what you paid was for that particular value.
Let’s say, for instance, that you were progressive beyond the norm and you thought the technology developed in 1990 would last another 20 years. It’s now 2009. You got a good deal. You’ve reached the twenty year mark, and the technology still works reasonably well.
Fine. But now, let’s say you’re in a different situation. You didn’t buy SAP* back then; you bought another system or you muddled along, or you just acquired a company, or whatever, and today, you’re looking at SAP. You surely wouldn’t want to pay roughly the same amount you paid back when the system was newer.
To see the point, let me pursue the analogy. Let’s say you want a new car, and somebody offered you an absolutely brand-new 1990 Mercedes. Never been driven; no wear and tear whatsoever. You wouldn’t want to pay the 2009 price for it. Sure, it’s a nice car, and sure it works pretty well. But there’s just a whole lot of stuff that has changed in the car world since then, and in the next 15 years, there will be a whole lot more. So, good as it is, that 1990 car isn’t worth what it was when it was new.
$AP* PR, before you start calling me, I know, I know, I know, I know. You think that the product has improved steadily and linearly in the last 14 years. So you don’t think the analogy holds. You think you’re offering the customer a product that now has 14 years of improvements in it, so that customers are actually getting a big bargain, a much better product at the same price. You think they’re getting the 2009 Mercedes.
Well, I don’t think so. I think that when you sit yourself down behind that nice, leather SAP* steering wheel and start that nice, purring motor, you can see immediately that what you have just isn’t all that new. But I’ve already tried your patience long enough. To see why I think so, you and I will have to wait for the next post.
* Or Oracle or any other back-office app designed twenty years ago.
The Applicator 