Minneapolis, MN
March, 2005

A Piece of the Stack

Oracle outbids SAP for Retek. Why?

Auction Frenzy

It's a staple of cheap melodrama. An art auction. A rare painting. Two big, loud guys with ruddy faces, and diamond pinkie rings, getting into a frenzy over a de Hooch that they've been told is a Vermeer. Testosterone flies, and the auctioneer grins.

When it's not de Hooch, but Retek does this scene even rise to the level of melodrama? How could smart businessmen like Charles Phillips and Henning Kagermann be acting like... like...well, like Larry Ellison and Hasso Plattner?

It isn't just that Retek is far less attractive than the worst de Hooch: a barely profitable company with a checkered history that has never made a compelling case to its target market. It's that once you have it, you have to figure out what to do with it. It isn't a de Hooch; it's one of those Damien Hirst creatures in plexiglass. You can't just take that home and put it on the wall.

I know. Everyone says that they're not bidding on Retek, they're bidding for control of the retail applications market.

But as usual, what everyone says makes no sense. Retek doesn't give you control of the retail market; it gives you access to two or three hundred existing customers and a product that some of the thousands of non-ERP'ed retailers might find interesting.

How much is that access and product worth? A complex question requiring a sober assessment of risks.

But it doesn't seem to me that either company was conducting this kind of assessment. Their logic apears to be more simple-minded and goes like this. Both want to be the primary providers of the corporate information stack. Both think that a retail application is a necessary part of that stack. At $700 million, both apparently thought that it would be more expeditious (if not cheaper) to buy Retek and plug it into their stack, rather than build one on their own.

Now I agree with the commentators that Oracle has a better chance of doing this with Retek than SAP does. But for both companies, a plan like this seems highly speculative. Does anyone really know what a corporate information stack looks like? Won't their ability to retrofit and retool Retek depend a lot on what form that stack eventually will take(in which case, the cost of fitting Retek in is essentially unknown). Does the market really want a stack?

Remember, what you do with the product is just one of the balls you have to juggle. Until Retek becomes part of the stack, you still have to support the current customers, sell new software, and figure out how to move everybody to the new stack.

Sounds like a lot to me. But evidently, both companies wanted to give it a try. What I'd like to do for the rest of this article is to lay out what I think their reasoning was and point out some of the problems they each would have had to overcome. At worst, it will help us all get a better understanding of what the stack wars are all about. And at best, it will give Oracle a chance to amaze the world by overcoming obstacles that at least one reputable critic thinks are pretty close to insuperable.

Why Retek?

Before I turn to each company's stack strategy, however, let me lay out my pre-auction position on Retek.

I view Retek as a company that has tried, but failed to make a compelling case for its technology. Like Palm or the post-Alpha DEC, it had come to market with a product, found some acceptance, but never gained any momentum.

As with Palm, it wasn't that the product was bad or useless; it just turned out that there were always other ways to go, which offered better price and performance, and people took those ways.

This product was and is what's called a merchandising system. Such a system can give certain kinds of retailers a coherent, integrated view of their inventory positions and replenishment requirements and the ability to act on this view.

Not a bad thing, but limited in a lot of ways. At the pure technology level, it is limited because you had to integrate it with a lot of other expensive systems: a POS (cash register) system, a finance system, an HR system, and any number of specialty systems for managing demand, promotions, and pricing.

A merchandising system, in other words, isn't ERP. You can't sell it the way SAP sold itself in the nineties, by promising everybody that this would be the only system you need.

It was also limited because the idea of an integrated inventory system just isn't going to sing to retailers the way SAP sang to the CFOs. ERP salespeople in other industries were often able to convince the early adopters that the purchase was strategic. But this was a hard sell in retail (despite the example of Wal*Mart). A system like this was going to take considerable investment, and generally speaking, retailers are cheap. They'd prefer not to invest if they don't have to, and if they do want to invest, they would rather invest in things like new stores or new branding, rather than systems that counted inventory.

In my view, the reluctance reflects fairly good judgement about costs and benefits. In retail, the costs of these inventory management systems are proportionally higher than they are in other industries. Because retailers sell lots of things in lots of locations, there is lots of data. To handle the data, you need a lot of hardware, a lot of network, a lot of systems people. The data itself is in some ways more complex in some ways than the equivalent data in other systems, which means that the software itself has to be complex and the job of data managers is harder.

Unfortunately, this high relative cost is not fully offset by high relative benefits. In other industries, you really have to count and replenish items accurately because they are expensive or take a long time to replenish. In retail, sloppy inventory management is not as costly; in fact, it is the norm.

Perhaps because it is the norm, success with inventory management and replenishment systems in retail is expensive, because it requires that retailers learn how to achieve a level of operational excellence that is really quite rare. (See my articles last summer.) Remember, the Wal*Marts that succeed with this are the rare, rare exception.

Bottom line: the core value prop for the core Retek system is not fabulous--wasn't fabulous ten years ago, isn't fabulous today.

Why is this? And can something be done about it? I would argue that it's pretty intrinsic. A commercial merchandising system uses the same core modeling techniques that any ERP system uses. But those techniques are really stretched by retail requirements.

You can see this in the fact that retail application companies like Retek and JDA tend to have very long implementation times and tend to assume in their business model that their customers will do a lot of customization. Essentially, this has happened because modeling everything that retailers want to do (economically) is really hard.

I've worked in a fairly detailed way with several of these systems; when you do that, what I'm talking about becomes really clear. In my view, these retail systems are still a little overwhelmed by all the things their customers want; you can see this in the surprising number of relatively simple problems that they leave to the reader to solve.

Again, this is testimony to the high cost-benefit ratio. If there were a big payoff to supporting these relatively simple things, the vendors would have written the appropriate code.

So what do you do if you're a software company and you're in a market where most of the buyers think (possibly correctly) that your product is too expensive and doesn't provide enough benefit? Well, if you were in a different business--say you were operating a Rover dealership in coal-mining country during the Thacher years--you'd shut down and look for better opportunities.

But if you're in the software business, well, you change management teams, you change Power Point slides, you make sales where you can, and if you want to sell the company, you cut R&D until you start looking profitable. But unless you can change the rules of the game, it's no more than a slog.

Changing the Rules

No limping software company of the kind I'm describing is worth 3.8 times trailing 12-month revenues (or in my view, 3.8 times future 12-month revenues). To justify that price, the buyer must be able to change something about the situation that company finds itself in.

So what could the game-changer be?

Ordinarily, there are three rational reasons to buy a technology company that needs a game-changer.

• You want the company, and you're going to change the rules by running it better than the old management did.
• You want the technology, and you're going to change the rules by putting it on a different platform or selling it in a different way.
• You want the customers, and you're going to change the rules by getting far more money from those customers (through cross-selling or upselling) than the old company could get.

If, as an outside observer, you can't figure out which of the three strategies is operating, then you begin to wonder whether the bidders are just guys with loud voices and big rings.

Buying the Company

To me, the best available game-changing strategy is to buy the company. The new owner could provide Retek with economies of scale, infrastructure, global reach, improved marketing, and some credibility.

Both Oracle and SAP woud think this absurd.

Would this strategy really provide a game-changer and justify 3.8 times trailing revenues? I doubt it. But it would at least preserve the business model that Retek has evolved, a model that, for all its faults, is adapted to the tough conditions that retail imposes.

The model is based on big deals, long implementations, plenty of retail expertise throughout the company, a high percentage of revenue from consulting and customization, and patience. None of these (except perhaps the big deals) are things that either SAP or Oracle find inherently congenial.

They're not congenial, of course, because the model is not as scalable as a "purer" software model, and its margins aren't as high. It's a model that makes rapid growth difficult. It's only a good model, in other words, when your market consists of large, very cheap companies and your product's core appeal is that it's the only one available to do a dirty and expensive job.

Bear in mind that the components of the model are interdependent. When you build very large systems that are always heavily customized, pose a lot of risk on implementation, and take a long, long time to put in, you need a sales force that can speak the customer's language and has the patience to establish relationships. You need to provide some assurance that the product will work. You need to build products that are adaptable, rather than highly functional or reliable.

This interdependency means that you can't just do what Oracle is trying to do to PeopleSoft: rip out part of the company and replace it with your own, more competent people. If SAP, for instance, had bought Retek, they couldn't have just given the Retek product over to the SAP sales force. Yes, those guys understand big-money deals. But the average rep doesn't speak retail-speak and has no clue how cheap and demanding retailers are. Under current SAP rules, you can't even structure the deal properly, since SAP has a limit on commissions that makes 2-year deals undesirable and discourages selling the services that are integral to Retek deals.

Anything you do to dismember the company, in other words, can only be a game-changer if you figure out some way of solving the problems that the part you got rid of used to solve. If you don't have a strategy to do this, you risk the destruction of the very expensive assets that you have kept.

The Retek Technology

Of course, keeping the company and running it better is not what either SAP or Oracle have indicated that they want to do. The attraction of Retek, for them, is the technology. The game changer is to integrate their product and Retek's so that they can offer retail firms a full suite of products.

For both companies, this is basically a buy vs. build decision. They think its cheaper to spend $700 million on an already developed technology and adapt it to their toolset than it is to spend an unknown number of dollars and years to deelop a comparable product.

In SAP's case, history provides considerable justification for this view. After all, they've been rying to build an equivalent product since about 1998, and they haven't managed it. Yes, they have a few installations at large retailers. But a person who is intimately familiar with two of those implementations describes SAP Retail as "only a toolset, not a product." And my own experience with the product is that even small retailers find it preferable to build their own merchandising capabilities, rather than use SAP's.

In Oracle's case, history isn't quite as clear. But their experiences trying to build best-in-breed quality products in other areas (CRM or, for that matter, HCM) have not been heartening.

At the same time, neither company has shown themselves to be expert buyers either. With SAP, probably the closest comparable experience is their "partnership" with Commerce One--another $700 million experiment in buying technology that resulted in SAP building its own product from scratch.

With Oracle, the experiment I know the most about was a company called Dtalogix--a process manufacturing software company that Oracle was going to use to launch its high-end CPG product. After the purchase, what actually happened? The Datalogix product fell behind its competitors. The integration never happened (as recently as last year, full integration had not been achieved). And Oracle is still an also-ran in CPG.

BPeople who want to buy rather than build retail applications should also remember the experiences of PeopleSoft and Intrepid (a bust) or Lawson and Armature. I ask this as a joke, but might it not be cheaper for Oracle to take all the old Intrepid assets, which they bought when they bought PeopleSoft and invest $700 million in improving them? I'm sure that there's still a disk lying around somewhere in Pleasanton.

The track record on either buying or building these specialized applicationsis lousy, I think, for an obvious reason. Most of the companies that try to move into a difficult specialty market sadly underestimate what they're getting into.

With SAP Retail, for instance, SAP decided that it was going to be easier to build retail capabilities using its toolset than it would be to integrate somebody else's technology. But let's look for a second at what happened early on. For reasons now probably lost, somebody made a critical decision: they would use R/3 as the core, but put a switch into the SAP Retail product that would enable the specialized retail capabilities, while disabling certain replenishment capabilities that were regarded as irrelevant in retail.

This may have been the right decision, in some ways, but it is not a decision you would ever make if you really understood what it takes to compete in the high-end retail market with a fully integrated solution. My guess is that it was just one of htose decisions that somebody made without thinking through the consequences, and there was nobody else around who knew enough to anticipate the problems being created and correct the decision.

Now, both Oracle and SAP would argue that the past has little relevance here. Both are now committed to doing whatever it takes to build a stack that includes a useful retail product, and with that commitment, they won't make the mistakes that were made in the past.

Whether they will or not is an empirical question, of course, and for the sake of customers, I certainly hope they're both right. But I'm not holding my breath.

They would also argue that the technical problems associated with adopting someone else's technology have changed considerably in the last few years, and this will reduce the challenges that confront the people who have to do it.

We are all familiar with the core notions here, most notably SOL--oops, I mean SOA. But I should at least point out that the SAP approach and the Oracle aproach to technology adoption would/will be quite different.

In Oracle's case, surely their best bet will be to incorporate the Retek technology into Project Fusion, building a superset technology that includes the special process and data model capabilities that retailers require. This means pretty much putting the current Retek technology on hold (as with JDE and PeopleSoft) and figuring out later on how to migrate customers to what will be an essentially new piece of application software.

(Yes, I know that Retek is written with Oracle tools in Java on an Oracle database. But the tools are Oracle Forms (which will be superseded), and the Java libraries are specialized; to be part of a more general superset, they will almost certainly have to be rewritten.)

The downside of building a new Fusion retail product is that you're doing almost as much work as you would if you built it from scratch. the upside is that the timing is good. (It would be much harder to retrofit retail capabilities into Project Fusion, as SAP proved.)

But all this assumes that it is possible and reasonable to build a superset product that includes retail. It's not really clear that it is.

Remember, when SAP looked at the problem, they decided to put in that switch. Why? Well, remember that the data throughput, quality, and management problems in retail are an order of magnitude or more greater than they are with any other kind of application. In every ERP system I've ever seen, you're always making tradeoffs. If all tradeoff decisions in the superset product are affected by the need to support very high-end retailers (who don't show much sign of buying this product in droves anyway), you risk making a lot of pretty weakening decisions. But if you decide to put the superset product first and are forced to weaken the product the way SAP did, you run the risk of losing whatever hold you had on the retail market.

Clearly, whether the right tradeoffs can be found is an empirical question. All I'm saying is that it will be extraordinarily difficult to get this right; it may well depend on such intangibles as the personalities involved and how much contact with retailers Oracle chooses to maintain. If there were more money coming in from retail than there is, it would be more likely that Oracle would devote the resources required. But Oracle wants to increase its margin every year, and money put into things that soft looks beter on the bottom line.

With SAP, of course, the strategy would have been different. Assuming that SAP is serious about its idea of becoming a platform for innovation, I believe their strategy with Retek would be to use Netweaver to "integrate" existing Retek technology with SAP.

Again, whether this would work is an empirical question, a question of resources and talent. But the technical problems associated with this are really considerable. In retail, particularly, the problems of managing semantics and scale are massive; whatever one thinks of SOA, it is certainly fair to say that the problems have yet to be solved.

Indeed, I think SAP saw Retek as a test case for SOA. An expensive one? Yes indeed. But over the very long term, any investment that led directly to SAP's becoming a plug and play company would be well worth a paltry $700 million. The real question is whether this would have been such an investment.

For both SAP and Oracle, the most immediate problem for their strategy would have been/is what to do with the current Retek product, Retek Xi. This product is a harmonization and integration of several different capabilities on a single platform. All good things. But there are some issues:

• Historically, harmonization products have quality problems. Retek's somewhat problematic history with outsourcing development makes it more likely that these quality problems will occur.
• Harmonization products pose significant challenges to customers who want to upgrade (as well as significant benefits).
• Planned as a platform for the long term, Retek Xi now must be seen as an intermediate stage on the road to the superset product.

This last point is easy to paper over (Retek is "already built on Oracle technology!!!!"), but it should worry the customers who might otherwise want an end-to-end product or might otherwise be willing to upgrade.

So, to all the other costs and technical problems associated with buying this technology, one must also add the cost of weakening the not-yet established flagship technology that you just bought. When you buy a new technology for a very high price, you'd like the existing customers to fund your adoption, but precisely because of where Retek is in its product cycle, this will be particularly difficult. Retailers who are always inclined to stay put now have even more reasons to do so.

The Customers

Which brings us to that last strategy: buying the customers. To some extent, access to customers had to have figured into both Oracle's and SAP's idea of how they should value Retek. But it's also clear that what either new owner could extract from these customers is fairly limited.

For Oracle, there seem to be two kinds of gains, one at the database level and one at the application level.

Informix has historically been the database for retailers; anything that this purchase can do to hasten replacement of Informix with Oracle would be a huge gain.

In places where Retek has been adopted, but not fully adopted by retailers who also have a lot of Informix installations, there should be an acceleration of Oracle database sales. I'm unable to determine how many of these there are: for Oracle's sake (and the customer's), I hope there are a lot.

Beyond that, I'm not sure how much of a case the ownership of Retek makes for the Oracle database. Companies who now see Oracle as the leader in retail may feel more comfortable about making a planned switch, but of course Informix is now owned by IBM, and I'm sure that IBM is more than capable of bringing that discomfort with Oracle back to what they think is appropriate levels.

At the application level, Oracle is certainly buttressing its position with its own retail customers (like 7-11), and it is providing some very interesting long-term growth paths for the PeopleSoft retail customers (though the biggest, Wal*Mart, is not likely to see it). But all of this is probably very long-term.

Remember, nothing Oracle does in the short term is going to change retailers' fundamental views about the value prop of merchandising systems. The big technology interest these days in retail is in POS systems and pricing optimization systems, areas where Retek does not have competitive products.

Who Wins, Who Loses?

There are three obvious winners here, and none of them is Oracle.

• SAP wins (or maybe lucks out) because it gets to use the resources it wants to put into retail in a more culturally congenial way, while at the same time acknowledging that those resources will have to be deployed better than the first time SAP tried to do it. But while they figure all this out, their major competition in retail (the Retek Xi product) will have been weakened.
• JDA wins for roughly the same reasons. They are given breathing space, while the major current competitor reforms itself.
• IBM wins big, partly because POS is hot and their POS capability has always been the most important part of the SAP-IBM retail alliance. But perhaps even more important, IBM now offers retailers real, scalable integration capabilities (with Websphere) that work with existing heterogeneous stacks, whereas both Oracle and SAP promise theoretical stacks with problematic benefits that will only begin to exist far in the future.

Does the nominal winner, Oracle, also win? It's entirely possible; it is, as I said, a question of whether and how they can solve the technical and business problems that the acquisition poses for them. But given how difficult and special retail is, they will have to execute brilliantly in order to make this deal a winner for them--as brilliantly as they will have to execute with PeopleSoft.

Personally, I admire the bold move and calculated risk. But as an observer, I have to remind my readers of how much risk there really is.

To that end, let me call your attention to another industry where companies bet billions on their ability to come up with clever, apt, and appropriate solutions to complex technical problems.

Some years ago, all the large telecom companies told Wall Street that they would invest huge amounts of money in building up their mobile network. All did this with great panache and self-assurance, and to a large extent Wall Street believed their manner.

Now, some five years later, some colleagues have done an analysis of the results. If the companies had achieved what they promised, the ratio of assets to revenue would have fallen steadily. If not, the ratio would have followed a jagged curve, as the phone companies invested to fix the problems that they hadn't solved the first time.

Of those companies, only Nextel demonstrated that they had done the investment right the first time: the ratio has fallen steadily. All the others, confronted with the same technical problem, were unable to deploy a technical solution that justified their investment plans.

The moral of the story? Well, when you have a clear business goal which requires a very large investment in innovation, sometimes the people doing the innovation are not going to have what it takes. Is Oracle the Nextel of its business or the AT&T Wireless? It is betting billions that it is Nextel. Let us hope for their customer's and investor's sake that they are right.

To see other recent Short Takes, click here for a listing.

SAP lucks out.