Chiseling On-Demand

June 15, 2009

You know the old joke, “How can you tell whether a software salesperson is lying?”

What about when it’s a “No-software salesperson?”

The question came up the other day when one of the people in the office went off to Intuit’s road show for its on-demand database. (Intuit is putting Quickbase on line, promoting it as the cloud’s answer to Access, and the road show was for people who might develop on it, using a Flex-based front end.)

This person came back less than wowed, of course; what do you expect, it’s Intuit. But the quality of the product seemed to me to be beside the point. No matter how good or bad it is, I argued, you would have to be absolutely cracked to have anything to do with it.

Why? Because the way Intuit behaves itself in the on-premise world makes them a non-starter in the on-demand world.

Believe me, I know whereof I speak. I am a heavy user of Intuit products: TurboTax for 10 years or so, QuickBooks for four, Quicken, now, for two. I have thus had more exposure than I would ever, ever like to have to Intuit’s chiseling ways: the design that plumps unerringly for the cheap and stupid way of doing things, the support that has at times left me screaming at the telephone, the innumerable ways they have made my life harder because they only want to deliver the absolute minimum, the endlessly inventive efforts to extract an extra $5.00 or $20.00 from me.

I use the products, despite all this. But only because, over the years, I have figured out how to keep the chiseling costs down to what I think is an acceptable minimum.

Mind you, sometimes they nail me, even so. This year, it happened twice. This year, for instance, they decided de-support QuickBooks 2006 Professional Edition. “Desupport, I thought? I don’t get any support from them anyway.” Turns out, of course, it was a way to get me to plunk down another $300 for the latest edition. Didn’t work; I finally figured out that there was no reason to pay another $300 for software that I already owned. But it did cost me more than a few hours to figure that out. And it burned me when I figured out that what they were doing, in order to make me want to upgrade, was taking away their QuickBooks e-mail invoicing service. $100/year to send out invoices? Give me a break.

But they weren’t through with me of course. This year, I saw the most inventive piece of chicanery I’ve seen in a long, long line. Instead of sending me a check for the TurboTax rebate, they sent me a debit card with a $10 credit. This turned out to be much more fiendish than you might think. First of all, even though it says debit card on the card, it’s actually a credit card, so if you say, “Debit,” to the cashier, it’s refused, something I find embarrassing. Second of all, even after you get on to that dodge, it’s a lot of work just to use it. Either you have to come up with an item that costs exactly $10, or you have to split the bill between two credit cards–also embarrassing. So what did I do? I finally bought a $7 item, and I guess I’m going to let them have the remaining $3.

So what does this have to do with cloud computing? Well, let’s put it simply. If you have enterprise application software, and you’ve bought a perpetual license, you have a defense against at least some of the chicanery and chiseling that seems to be built into relationships with software vendors. You can stop dealing with them and still use the software. But with a cloud computing vendor, you don’t have that defense. So you’re much, much more vulnerable.

My supplier of enterprise application software happens to be Intuit, and with Intuit, I simply don’t allow myself to become that vulnerable. I never use the Intuit Quickbase product or the On-Demand version of Quicken or QuickBooks; I don’t even use the on-demand TurboTax backups. Why? I have been victimized by Intuit’s sharp practices many times, and I don’t want to give them an even bigger and more vulnerable target.

Now I don’t blame Intuit. They invented a business model that really worked for them and apparently works for millions of customers–a kind of RyanAir for software, where you provide the maximum amount of irritation and inconvenience possible in return for a rock-bottom price. But this is not a business model, I think, that consumers should accept when it comes to cloud-based applications. There’s just too much risk that a Ryan Air-like application company will ask you in mid-flight to chip in a little bit more so they can get you back down on the ground.

If it were just Intuit, of course, I wouldn’t burden you with my ranting. But it seems to me that Intuit is not the only company that came of age in an era when you delivered software to the premises and discovered that you can make a fair amount of money in that context by overpromising, underdelivering, and making sure that you have your customer’s wallet firmly in your gunsights at every moment. I hate to say it, but there are much bigger companies that deliver much bigger accounting software that have the same mind-set. So if it’s unwise for consumers to trust Intuit’s approach to business when it comes to cloud applications, isn’t it unwise for consumers to trust the other guys?

Now wait a minute, Leo or Larry might say, aren’t you tarring perfectly reputable, upright, leading companies with a brush that should be reserved for Intuit? Well, I dunno. I don’t own your software. You tell me, L&L. I know that Intuit has provided me with support that was completely inadequate and left me genuinely vulnerable as a result; has your enterprise software company done that? I know that Intuit has misled me about what’s in upgrades or in more expensive editions and cost me a lot of time and money as a result; has your enterprise software company done that? I know that Intuit has tried to charge me for things that I thought were included in the original deal and has raised rates on me without providing anything to me in return; has your enterprise application done that? And I know that Intuit designs software in a way that shifts a lot of costs onto me, even though it would often be very simple for them to avoid doing this. Does your enterprise application company do that?

If the answer is, “Yes,” to any of those questions, what’s going to stop you from doing this to your customer again, when your customer buys your cloud-based apps?

Maybe there’s an answer. But until there is one, my recommendation for customers of companies that do this would be to avoid their cloud-based applications for the same reason I would run, not walk away from Intuit’s.

So how do you know if your No-software salesman is lying? Well, I guess you don’t. But if he used to work as a software salesman, shouldn’t you at least check what he says?

Advertisement

Let’s say you go off maintenance. (I know, I know, it’s unthinkable. But there’s no harm in a little noodling, is there?)

So you go off maintenance. What consequences does that have for your application strategy?

Don’t tell me you don’t need one any more. You still need a strategy. True, you’re letting your primary back-office application lie dormant. Unfortunately, though, even today your current application doesn’t work perfectly. And, as time marches on, your business will change, your work will change, new kinds of work will come in–and you’ll need to deal with it.

I don’t know of any analyst who has actually addressed this issue. So there isn’t a canon of accepted practice. You’re kind of on your own.

But I think there are some principles you can follow, so let me suggest them. It might help. Broadly speaking, they are as follows:

* Don’t go backwards

* Embrace heterogeneity

Going backwards is dropping back to an era when IT tasks or business tasks were done on isolated, often custom-built applications. If you need new functionality, and you’re not going to get it from your now moribund application, the obvious thing to do is build it yourself, just as you used to do.

Don’t. The reason we bought commercial applications was that doing it yourself cost too much. The cost of maintenance for the home-grown stuff and the unsatisfactory performance of what you got, often due to limitations on access, outweighed the benefits of having a bespoke application. If you ignore this lesson, you’ll repeat the same mistake. If you learn from it, on the other hand…

And heterogeneity? Well, the other reason we embraced commercial applications was that heterogeneity was too expensive. Yes, you got a best-in-breed application, one that was well-suited to the business.But the cost of integration (and other maintenance costs) was simply too high. You were better off using the [Fill in blank] stuff that your platform vendor foisted on you.

So, shouldn’t you learn from this and go back to the platform vendor with your tail between your legs? Not necessarily. You see, the cost of best in breed has gone down a lot, and the difficulty of integration is less. What’s more, the delta between what best in breed does and what the platform vendors do remains very high. (i2 or Manugistics works much better than APO or Demantra in many cases.)

Bearing these principles in mind, how do you approach the problem of adding to or extending what you’ve got, when you can no longer ask the software vendor for help? Here are some suggestions.

1. Always ask yourself, “Why not the cloud?” If you’re thinking of buying a best-in-breed application, can it be a cloud-based application? If (horrors), you’re building something yourself, can you put it in the cloud? Why the cloud? Because a cloud-based application changes the economics, be it an application you build yourself or a new, best-in-breed application.

Take a simple, simple example to show you what I mean. Assume that you’ve gone off maintenance, and you want to establish a new discounting system for large customers, which involves basing the discount on the volume of orders, frequency of orders, credit history, and credit rating. Let’s assume that customization is unreasonable, partly because of the maintenance issue.

The temptation is to put the data on a spreadsheet, roll in the data once a week, have it do the calculation, and then and change the discount table. Fine. But wait a minute. Why not the cloud? Rather than putting it on a spreadsheet, which will be locked on somebody’s computer for the rest of time, why not put it on Google Apps?

It may not seem like it, but the costs of storage and maintenance for that mission-critical spreadsheet are significant. So are the costs of making the data easily accessible and securely available to all the people (and systems) involved. So are the costs of getting updates from public data sources out in the cloud. So are the costs of having the spreadsheet “belong” to one person.

Get rid of all those costs, in one swell foop, and make it easy to use other public data sources as you refine your discounting. Put it in the cloud.

2. Try to do less for your application customer. No, don’t recoil in horror. Ask yourself what the right strategy is going forward. With your old platform strategy, which you’re now abandoning, you always wrote for the ages. Be it a report, a custom app, or an app extension, you wanted it to be robust and highly satisfying to the user, doing everything that the user wants. But if you’re not building for the ages, you want to rethink this. There are many situations where quick and dirty is superior, where even the users would rather have something fast that works more or less. You’re in an age of limited resources; don’t go backwards to the time when you were expected to achieve perfection.

3. Tolerate application islands. The idea of your platform, remember, was that eventually everything would be on one system. Great idea. More work done by the platform would mean fewer systems to manage, more consistent data, better access, etc. Well, that idea is over with; why not look to make the best of the freedom this gives you. Lock down the mission-critical data and functions, sure. But aren’t there areas where people want to use best-in-breed apps, iPhone apps, social networking apps–am I scaring you, yet?–and really, at the end of the day, you’ll make their computing environment better if you let them? Remember, if you’re off maintenance, the new work still needs to get done. Why not be open to finding the best way of doing it?

I could go on, but hey, I know that I already write the longest blogs in the known universe. Comments (and more questions) are welcome. It’s a fruitful and interesting topic. It needs more discussion.

Clarity at SAP

May 31, 2009

How will SAP develop? Where will it lead its customers?

We expect a CEO keynote at a software conference to answer questions like this; in what was his first full-CEO keynote, Leo did not disappoint. The answer? Clarity. Clarity is exactly what is needed to combat a global downturn and, guess what, clarity is exactly what you get from SAP.

I was there: the heads were nodding around the room and the Twitterati were passing the approval on as fast as their thumbs could go. “Good message,” one reputable analyst told me, and given the general dearth of good messages from SAP in recent years, you could see why he was pleased.

Good message? No. Illogical message. It makes no more sense than saying, “Language enables clarity,” and for roughly the same reason. Language doesn’t in do anything about clarity one way or the other. Used well and in the proper way by people who are intending to communicate, language can bring clarity. Used for other purposes, it can equally well confuse or deceive.

Now, in the history of the world, there have been many people who have claimed that a new language or a better language would indeed improve clarity and bring new intelligence and insight to people. But they’ve all been mistaken. They’ve seen a desirable effect (clarity), and they’ve known that you don’t achieve this effect unless a certain tool (language) is used correctly. So they think that the effect can be achieved by constructing the tool in a way that makes it impossible to misuse. But that’s just a mistake (what philosophers call a category mistake). The effect is not in fact caused by the tool, but by the way it’s used, and the tool itself has only a limited amount of ability to dictate what the final effect will be.

Similarly, SAP is merely a tool for storing business data. Good data, right problem, excellent analysis: voila, insight! Bad data, wrong problem, silly analysis, voila, confusion.

Now, there is an actual arguments that could be made in favor of what Leo is so blithely promising. You could say that the structure of SAP, the way it’s put together, is designed, through the use of best practices, to provide clarity, much as those mythical clear languages were going to be incapable of stating things that weren’t true.

I’m sure that Leo believes this, but since I don’t work there, I find it a bit of a stretch. It certainly can’t be something one would want to take on faith. It’s at best an empirical question. Whether it’s true or not would depend enormously on the quality of the implementations, the quality of the data actually being stored, the ability of the data to be used in multiple different circumstances, so that the data could be helpful in addressing real problems. If best practices genuinely produced good and useful data, flexibility and agility, etc., etc., that would be good to know, but I, for one, would find it surprising and at odds with what I know.

I might be more inclined to believe that SAP really does produce clarity in this way if I hadn’t asked Henning years ago what were his biggest problems in running SAP, and he pretty much said that it was hard for him to get insight into what was going on. I would also be more willing to believe it if SAP spent a lot of time analyzing whether the customers are using the software effectively. If they had lots of evidence that showed that people aren’t having problems with data quality, with fitting best practices to their own, or with flexibility and adaptability–that is, if they spent a lot of time figuring out whether their software was working in this way and could persuasive show that it is–one might feel that they really have happened on that magical clear language.

I actually had a long talk with Leo on a subject closely related to this. He’s a very smart guy, and it was a very enjoyable talk. In the talk, he insisted over and over again that it’s not his company’s job to see to it that the software is used effectively. I believe him, and I believe that’s a sensible statement of the company’s mission.

Unfortunately, though, if he doesn’t want to start reaching into companies and making sure that they’re using the software well, he can’t know one way or the other whether the best practices, etc., of SAP are producing the clarity that he’s claiming for it.

It may be enough for him to proclaim as an article of faith that SAP is enabling clarity. But it is not enough for me.

A client asked me the title question recently, and my answer was just a shrug of the shoulders. The answer is, “They probably shouldn’t.”

Yes, it’s a little more complicated than that. Maintenance on enterprise applications may be worth it to some customers, just as an extended warranty plan might well be worth it to some buyers of appliances, automobiles, or electronic, because they they get some comfort in knowing that they can do something if it breaks. It’s also worth it–absolutely 100% worth it–if your installation is in its early stages or incomplete, that is, you’re planning on buying more software from the company or you’re certain that you will need to maintain an aggressive updating policy.

But for most customers of most enterprise applications, it seems to me that paying a maintenance bill is in some ways akin to putting down your money in a three-card monte game. The money is gone. And it is more than a little unlikely that you’ll get any return from it.

Have I ever done this? Well, I’ve avoided three-card monte. But there was a period in my life when I paid for a health club membership that I wasn’t using. I kept on thinking, “Oh, I’ll go there next week,” or “I don’t want to have to pay the initiation fee,” or “My doctor told me to get more exercise,” and so I paid.

But really, it was just that I couldn’t face the facts. I hated that health club; I hated the pool and the locker room and the crowding. I hated the way they were gouging me. And I hated having to admit all this to myself. So I paid.
I didn’t use my membership, but I paid.

So is that why most people pay maintenance. I think so. At the moment of payment, it’s easier to write a check than it is to face facts, so they write a check.

Now there is an obvious counterargument to this. It goes like this. Paying maintenance isn’t like paying for a health club membership; it’s like paying for insurance. True, with insurance, you pay and you pay and there’s little visible benefit. But that’s the idea. Frankly, you ought to be happier to pay and not get much visible benefit than to pick up the phone and call the insurance agent.

This is certainly the argument that the CFO hears when he calls up a CIO and says, “Can’t we do something about the 2 million a year we pay to $AP (that is, any of the middle-aged apps vendors)?” The CIO says, “There’s nothing we can do. It’s an insurance policy. We have to pay. What happens if our system goes down?”

Most CFOs seem to find this compelling. But they shouldn’t. Come on. They’ve been to business school. There is a point, obviously, when it’s not worthwhile to pay insurance. To see what that point is, imagine that you lived in a normal, middle-class neighborhood where there hadn’t been a serious house fire in twenty years. Would you carry insurance if the insurance cost was 1/5 the cost of rebuilding the house? You shouldn’t. What about 1/10? Nah. What about 1/50? Well, maybe, but probably not. 1/100? Nope. Normal insurance for this kind of situation shouldn’t be much more than 1/200, and that should cover a lot of other things besides fire replacement.

So the CIO is right only if the odds of failure are high or the cost of maintenance is low. As for the odds of failure being high, I don’t think any CIO should be basing the argument on this. If the odds of catastrophic failure are high, even after operating the system for years, maybe you need a new CIO. As for the cost of maintenance being low? Well, they’re not. They’re a a little more than 1/5 (of the software costs). So you could just stop paying maintenance and after five years, you’d have enough money to buy a brand new package, with money left over to pay the integrators. Yes, the integration and hardware costs would add on a fair amount. But to pay those, you could just coast for a few more years. And remember, when you’re finished, you’re getting a new system, one that is now ten years more advanced than the system you bought.

So which should you do? Don’t pay and save for a new system that will work better. Or pay for insurance that you don’t or shouldn’t need.

So what’s the answer? Don’t pay. It’s really very simple.

A few weeks ago, I made some people at Lawson unhappy, because I criticized their inscrutable demo of a new interface and search tool. (See the post, below.) I have to admit that my irritation level with what they were doing was pretty high, since they had not invited me to their conference, and their virtual sessions for analysts were abysmal.

The basic point of the piece, though, had nothing to do with my irritation. Basically, Lawson had demoed something that purported to make a big difference to customers. But you couldn’t actually tell whether it would make a difference or not. I argued that these days, for middle-aged apps, the burden of proof is on the vendor. They can’t just show us something that you can’t even make out and then expect us to stand up and cheer. They have to make what they’re doing persuasive.

Now this point applies to every vendor of middle-aged apps, not just Lawson. Whether you are Oracle, SAP, Infor, Epicor, Dynamics, or Lawson, you can’t just wave your hands, announce that you’ve created something awesome, and leave the audience befuddled about whether what you’ve got is worth anything at all. If you have something great, prove it.

Isn’t this just common sense? When there really was a lot of new stuff you could do with these apps, just showing it off really did garner some deserved oohs and ahhs. But those days are over. These are commodity products; for the most part, their technology is well behind the curve. To get an ooh and an ahh, you have to show that something about what you’ve been doing for ten or fifteen years has really changed.

I happened to pick Lawson to make this point, but it could just as easily have been SAP. It’s just
that their user conference came later.

So now, turnabout’s fair play. Let me show you how this argument applies to SAP.

First, some context. For the past three months, SAP has been making a BIG deal over the release of Business Suite 7, its “new” software package which for the first time gave all the latest software at SAP the same version number. (Until the announcement, the main part of the suite was called ECC 6.0, and the version that was relabeled 7.0 was ECC 6.0 EhP 4, which stood for enhancement pack 4.)

Now I admit, I’m not exactly being fair. That wasn’t quite all there was to Business Suite 7. Business Suite 7, SAP told us, changed the model for delivering software, because in Business Suite 7, you would be able to add SAP software to your current installation at a click of a button. No more sending for disks or downloads or whatever. If you needed any piece of software, you could look at the menu in your administration panel, select what you needed, and there it would be.

In an earlier age, that would have been “something amazing,” as Auden put it. These days, however, the idea is pretty familiar. The SaaS vendors do this routinely, more or less, and so do most consumer apps. So you kind of want to see just what this big, big, big advance really amounts to.

At the original announcement, to which I was also not invited, you couldn’t tell anything about what they were providing. (The broadcast was even worse than Lawson’s.) At Sapphire, though, we got a chance to see it. The inimitable Ian Kimbell, a man I greatly admire (though I must confess I can well imagine him playing Uriah Heep in some amateur theatricals in the Midlands, without a change of costume), gave us a demo.

The context was the Jim Hagemann Snabe/Bill McDermott keynote, which was devoted to product news. In the demo, which you can view yourself here

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.

Lawson’s New Office

April 22, 2009

If you read this blog at all, you know that I hammer over and over again at a single theme: the middle-aged application. What is a middle-aged application? It’s one whose basic mode of interacting with data was invented almost 20 years ago. It stores data in tables; you interact with it by pushing data into those tables or taking the data out. It was a great model, 20 years ago. Today, in my view, it’s fading.

What do you do if you’re a vendor, and you have an app that was built on a paradigm invented 20 years ago? Well, one thing you can try is a new interface. That way, even though you’re still basically storing data in tables, you’re doing it in a way that’s brighter, more colorful, and possibly more useful.

Unfortunately, this is kind of an obvious idea, and the landscape of ERP systems is littered with “new” interfaces that turned out to be not so new after all. According to the vendor, every single one of these modernized the application completely. But all they really did was put lipstick on a pig–and not much lipstick on an exceptionally hairy pig.

The latest such attempt (and surely one of the most creditable) is an interface demo’ed by Lawson at its recent CUE conference. I got a chance to take a look at it (if not a look into it), and I would have liked nothing more than to say that it changes something important about the application.

Unfortunately, that’s not possible, but not for the reason you’d expect. It isn’t that I looked at it and saw, “Oh, it’s just like all the others.” It’s that Lawson made it impossible for me to tell one way or the other. This is not a good thing, of course; if Lawson really has something great, they should show it to people. But it does say something important about the software industry.

First, let me tell you what I know. Lawson told us at the conference that they’re offering two new things that might change the way users work with the application. The first is a search function, which allows you to search for records via their contents, rather than getting at them through the menu system. The idea of this is really good; if you had to name just one thing that makes the old ERP apps middle-aged, it’s the fact that you can’t Google through them in any way, shape, or form. The second is something called Smart Office, which puts a Microsoft Office-like skin on Lawson and lets you interact with Lawson through Microsoft Office products, like Excel and Outlook.

The search function is particularly exciting, because the problems with search are built into the way 20-year-old ERP systems work. ERP systems store their records in a database; to get the records out, you have to use the tools the database provides. Search isn’t one of those tools. (It is too slow.) Lawson gets around this problem by manages pushing all the records in the database out to an appliance, a separate virtual machine, and then using a tool that wouldn’t work on a database, the open source search-engine, Lucene.

From what I could tell, there are some really thoughtful things in the way they’ve implemented the search. Particularly impressive was the fact that you can search back on all the work you’ve done, which makes it easier for you to stop in the middle now, go back to something when somebody asks you about it, or correct mistakes.

Smart Office, alas, seems to be a little more ho-hum. Some of what SmartOffice does was actually built into PeopleSoft more than 10 years ago; much also looks like a knock-off of Duet, the much-vaunted SAP attempt to integrate with Microsoft Office. Still, when you take a quick look at it, it doesn’t seem too bad.

If either product had been introduced ten years ago, I think I would have left my reporting at that. Lawson had come up with something new in the interface and demo’ed it. It wasn’t really very clear exactly what. But who cares. One needed to give them the benefit of the doubt. Surely it was better than a green screen.

Ten years later, though, I don’t think that’s right (even though that’s what most of the analysts did). Ten years later, there’s been a lot of experience with “major” interface improvements, and, as I said above, it’s been a disappointing experience. Most of these improvements have been at best, an injection of Botox, doing nothing about the basic problems with an aging interface, and possibly making things worse.

What this means for Lawson is that the burden of proof has changed. If they’re going to come up with a change in the way users get at data and claim that it’s a compelling, potentially transformative difference, they’re going to have to prove it, some way or another.

Certainly, if the language of the demos is any guide, Lawson does think that they have a compelling and transformative innovation. To listen to Dean Hager, their inimitable and endlessly enthusiastic spokesman for the product, Smart Office and Enterprise Search are, at the very least, what people were offered in the movie, “Seconds,” a brand new body and hence a second life.

So did they prove it? Nope. Yes, there were a few things in the demo which were encouraging. Some of the examples of how to use Search, for instance, were pretty insightful. And while the SmartOffice demo couldn’t be made out by those of us watching on the web, some of the claims sounded good, and the customers who were video’ed were enthusiastic.

But there were also a few things that were discouraging. Since I couldn’t actually see the demos (Lawson doesn’t invite me to their user conferences, even though I don’t ask them to pay my way), I can’t point to anything concrete. But I can say that I found the fact that Smart Office is a client technology (not a thin browser technology) provided by Microsoft less than heartening. (Anybody who doesn’t understand why that’s a problem should take about a ten-second look at a phone that runs Windows Mobile, then take a 10-second look at an iPhone.) Also not so heartening was the fact that Lawson’s broadcast of the event for “remote analysts,” that is, people they don’t think are very important, was incredibly web unsavvy. (Unless you use Microsoft products, you basically can’t even get a feed.)

Add up the discouraging and encouraging, though, and do you get proof? Certainly not. Both the positives and the negatives are way too vague.

And that’s precisely the trouble. It’s 2009. People have been working on these products for 20 years. There’s a great deal known about them. And today, there’s a presumption, born of bitter history, that when a vendor announces something fabulous, but most of what the vendor says is hand-waving, that what they’ve got isn’t really that fabulous.

So what would it take for me (or any rational person) to be convinced that the latest Lawson innovation is one that matters?

Well, let me tell you, it’s not easy. Even if I had full access to this application, something that there’s not a snowball’s proverbial chance that Lawson would give me, it would probably take me a day or two–I’m not kidding–to figure out how much of an improvement it is. To see why this is, let’s just take search as an example.

Lawson says they’ve made search of an application’s records as easy as Google search and that they’ve done this, as I said above, by putting the records on a separate appliance and using an open-source search engine. Certainly, doing this solves the problem of speed, which has been a serious problem.

But the trouble is that solving the speed problem does not make the record search as easy as Google. To make it as easy as Google, there are a lot of other problems you have to solve, too.

Here are some examples. You need some way of ranking what is sent to you in a way that makes sense for your uses; otherwise, as with Google, you’ll get tens of thousands of records when you make a search, and you’ll have to page through them. And you need to solve the ontology problem, the fact that you want to include synonyms in what you found, as well as exact matches. (Sometimes, these “synonyms” are nothing more than making sure that IBM, I.B.M., and International Business Machines are all included in the search results.) You need some way to use metadata descriptions. (Can you easily–and I mean easily, easily–restrict the search to sensible populations, like AR records, or sales orders from two years ago.) And above all, you need to deal with the problem of bad data. Many of the records you’ll grab in any search are records that shouldn’t be in the system. You need some way of filtering them out.

(Enterprise applications that have been in use for any time at all have this big, smelly layer of refuse in them, just the way lakes do. On the whole, I think, the bottoms of lakes smell better. Unless carefully managed, search has a way of stirring up all that stuff on the bottom, not something you want to do.)

If an enterprise application search product doesn’t deal with those problems, well, it isn’t much good. You can say it’s as easy as Google. But when the customer uses it, they just won’t have that experience.

There are still other problems, and one of them’s a real biggie: it’s what I call the transition problem.

You see, if the search (or Smart Office) is really going to change the way people interact with this 20-year-old app, people have to use it. So, in addition to providing a brand-new very hot, ultra-cool search capability (or Smart Office capability), Lawson has to make it possible for its existing customer base to take this capability up and take it up in a way that prevents the costs from overwhelming the benefits.

This transition problem is a thorny one for all the providers of middle-aged enterprise apps; I’ve seen versions of it at SAP, Oracle, and Infor, as well as Lawson. The provider figures out some way of getting an app to sit up and sing, “Rule Brittania,” as the old phrase goes. But then they tell the users that they’ll have to go through a massive upgrade and retrain all their users in order to make the trick happen. Then they’re surprised when most users opt to dispense with any stirring displays of patriotism.

To prove that Enterprise Search or Smart Office actually does something important, it seems to me that Lawson has to tell people (you, me, the customer, etc.) in a clear, simple way just exactly what it has done to deal with all these problems, and then it needs to provide us (you, me, the customer) with enough access so that we can genuinely see for ourselves.

Has Lawson done that? Well no, of course it hasn’t. I’m sure the thought of doing something like that never even entered Dean Hager’s head.

Not only is this unfortunate, it also says something important about the enterprise application industry and about the ability of Lawson (or any of the other middle-aged app companies) to modernize. The fact that Lawson (or SAP or Oracle or any other apps company that does this) doesn’t even realize that the burden of proof is now on them shows how far behind they really are. In a way, it’s puzzling. In the era of the iPhone and FaceBook and the collapse of GM, shouldn’t any company like Lawson be worried? But the answer seems to be, “No.”

Why don’t they think so? I”m not sure. What it comes down to, I guess, is that middle-aged apps and middle-aged apps companies are a lot like middle-aged people; it seems obvious to them that they’re still young, and so they don’t realize it when people start laughing at them. They think that they can give a cute demo at a user conference, have a lot of salespeople go out and tell their customers that it’s the latest, greatest thing, and then the IT staff will put it into the plans. That’s how it was ten years ago, and that’s how it is today. After all, the customers are paying maintenance, and Lawson is taking the maintenance money and working on things that keep the product up to date. What more is wanted?

Well, what is wanted is evidence. Without that evidence, the presumption has to be that applications like Salesforce (enterprise search three or four years ago) or Workday, which uses Flash, not Microsoft, and doesn’t use a 4GL, are now carrying the innovation banner.

Of course, the middle-aged apps vendors are unconvinced, just as all middle-aged employees are. We have the experience, they say; we have the know-how; we have the functionality; see, we can still dance a jig.

They say it, but in my view, they are wrong. Viewed by anybody who uses an iPhone every day, these apps just don’t work all that well any more, relative to how much they cost. They badly need to be brought up to speed. Ten years ago, we could assume that the companies were trying to keep up and we could accept mere assurance. But ten years later, that is no longer enough.

Yes, it may take the customers longer to figure this out than it does the analysts. But eventually, even the most ardent fan realizes that Elizabeth Taylor weighs a little more than she used to.

Oracle Layoffs

April 17, 2009

April 15 apparently saw a fairly good-sized layoff at Oracle; on LayoffBlog.com, the usual background chatter suddenly swelled to a roar.

I’ve been canned once or twice, and I once quit in advance of a layoff, so I know how bad it feels. For anybody who’s experienced this, I’m sorry.

It makes me wonder, though, what is a person’s useful life in this industry? We all know technology changes, and we all know that an existing technology can only be pushed so far. But for people who have trained as programmers or salespeople or application consultants (or analysts, for heavens’ sake), the feeling was that you had something–but what?–that transcended the technology, so that you could grow and adapt even as things changed.

Is that really true, though? Maybe, once you spend 5 years putting in Oracle EBS 11i v6-12 Accounts Receivable, the need for you in the next 5 years is not going to be all that great. The installations that are out there are settling in and working, so they don’t need as many consultants. The number of people out there who are buying and installing the product is going down. And really, what is it you know that’s worth $120,000/year (or $240,000 or whatever)?

I don’t mean to be mean when I ask that. I’m serious. I don’t know for sure now, but it used to be there were all sorts of date problems created by the way Oracle handled multi-geographies and accounting periods (two separate issues). Let’s say you’re an expert at writing reports that cover up those problems. Sorry, this is not expertise that will be valuable into the 22nd century. On the other hand, let’s say your expertise is in something far more general and transferable, like ways to raise cash on invoices. Yes, you can get a job somewhere else. But it will take a long time for you to learn the new systems and the new businesses, and at your high salary, that’s a lot of investment for people to make in you.

In my world, the place this really hits home is in marketing. I have any number of friends who had senior marketing positions at some application company or other and are now out with the trout. They’re talented people. But I wonder whether much of what they’ve learned in the past 10 years isn’t now outdated? It used to be that you were marketing innovation, so you had to teach people about your app and persuade them that buying this innovation would make a huge difference to them. But these days, apps are mostly a commodity, and the job in commodity selling is different.

So maybe, what you think is that you’ll hold a job in this industry for an entire working life, advancing from post to post and area to area, as you learn more and more, and eventually retiring with a big nest egg from those stock options. But maybe that’s just now how the technology business works. Maybe you get in and what you know is only worth what you’re paid for 10 years.

After that, you’re out.

My Worst Implementation

April 6, 2009

Vinnie Mirchandani has been asking his friends to write about the way technology has changed their hobby. He’s gotten responses on everything from chess (from his daughter) to repairing old cars. Now he’s got a column on bridge, a hobby of mine that has been transformed by the multi-player gaming technologies that got their start, among other places, in the old Project Athena.

You can read the post on his Innovation Blog.

But I always think, one good idea should beget another. Here’s what I suggest. I will ask friends of mine to send me a short article called, “My Worst Implementation,” in which they briefly describe a failed or completely inadequate implementation that they’ve been associated with personally in some way.

My single worst? Well, there are so many. But it was probably the implementation of SAP that the project manager later described as, “Like going through the gates of hell.” I kid you not. The factory, which made telecommunications equipment and was located in Westminster, Colorado, first bought QAD, which is why I got involved, then dumped QAD and bought SAP. $600 million later, the implementation worked–better than some I’ve been involved with–and the project manager was justly proud of what he’d done. But by that time, the business had completely changed, and I believe that almost all of what they made is now made overseas.

Ooorgh.

Got an oorgh of your own? You don’t need to be my friend. You can just send me an article. Write me and inquire; you can get my e-mail from the web site, but I don’t want to post it in a blog.

A few ground rules, required. Tell the truth. Don’t name names, except the names of application companies. Explain why things went wrong, but recognize that these things are never one person’s or one company’s fault. I haven’t done all that yet, but this is already too long.

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.