Jon Reed Interviews Bobby Cameron of Forrester on the Future of SAP, 1999
An Historical View of the ERP Market
(and the Challenges SAP Faced with Its R/3 Product in the Late ‘90s).
Jon Reed Looks Back on His Landmark Interview with Bobby Cameron of Forrester

Jon Reed's new introduction, April 2008: In January of 1999, I had the opportunity to interview Bobby Cameron, Principal Analyst at Forrester, about SAP's position in the evolving ERP market. Things are different now, but in the mid-‘90s, Forrester really was the thought leader in the ERP marketplace in terms of analyzing trends, and also providing a cautionary tone towards some of the over-spending and over-hype that was occurring in the market at that time. Nowadays, there is no one analyst firm that has a corner on the vision for the market.

I suppose other analyst firms will disagree, but Forrester stood out to me with the boldness of their predictions, many of which were accurate. Of course, not all of Forrester’s predictions have stood the test of time. The prediction of a truly component-based, best-of-breed ERP market hasn’t really come to pass, though we could make the argument that the age of Service-Oriented Architecture represents the next attempt at such an architecture, and perhaps the one most likely to succeed.  

In this interview, Cameron may not have predicted the acquisitions that would turn the ERP market into a two horse race between SAP and Oracle, but there are still some great insights to be had in this interview – especially Cameron’s view of dynamic trade, and the vision of extending ERP to customers and suppliers – not to mention the increasing role of Business Intelligence.  

All these things have come to pass, though perhaps not in the exact form Cameron predicted. Perhaps most interesting, Cameron’s notion of why ERP consultants are well suited to the next phase in the market, due to their business process orientation – this closely resembles the push towards the Business Process Expert that SAP is encouraging via its BPX community.

It is great to have the opportunity to share this interview with a broader audience again. Perhaps more than any other interview I have done, this one captures the feeling of SAP in the midst of its big North American heyday, but with the warning clouds of the Internet and post-Y2K on the horizon.  

Interview with Bobby Cameron, Principal Analyst with Forrester Research’s Packaged Applications Strategies Service, part one of four.  

1998 Introduction by Jon Reed:
 In April of 1996, Forrester Research created an industry firestorm with the publication of  “The Prudent Approach to R/3,” the first installment in its “Packaged Applications Strategies” series. This controversial report set off a fierce debate on the merits of SAP and is widely credited with causing a significant drop in SAP’s stock price following its release. Although not every prediction in “The Prudent Approach” came to pass, the report did usher in an era of accountability for the ERP market. Many people still rely on SAP, but few romanticize it anymore. Forrester had something to do with this.  

The visionary behind that first report was Forrester Principal Analyst Bobby Cameron. Never shying away from bold predictions, Cameron always seems to be one step ahead of the ERP market. He balances cautionary tales of SAP excess with a compelling vision of IT-driven business change he calls “dynamic trade.” Since that first report, Cameron and the Forrester Packaged Applications Strategies Service have been putting in their two cents on the ERP market each month. Any SAP professional trying to stay a step ahead of the market would be wise to stay tuned to Forrester’s analysis. 

Recently, Forrester published a new report, “Re-evaluating SAP,” which looks ahead to the future of SAP with a fully updated market assessment. We caught up with Bobby Cameron as the report was going to press, and for a good part of an afternoon we engaged him in a dialogue about the future of SAP. Cameron’s frank approach, not to mention his willingness to rethink his own previous positions, offers ample proof of how Forrester has been able to keep the attention of ERP industry leaders. 

Forrester has often been perceived as being “too negative” on SAP. But readers of this in-depth interview will see that while Forrester is skeptical about SAP’s far-reaching attempts to dominate multiple markets and industries, they are also more than willing to grant SAP credit where credit is due. In this fascinating four part interview, Cameron traces the evolution of Forrester’s perspective on the ERP and “extended ERP” markets, and brings us up to speed with his latest predictions on what the future holds for SAP. 

Forrester has never been afraid to step out on a limb in its Packaged Apps series, and in this interview we present Cameron with a chance to tell us where Forrester’s been accurate and where it’s erred. If Forrester’s been outspoken, they’ve also been right more often than not. Cameron’s strongly worded opinions on ERP are informed by continual conversations with industry leaders in all segments of the ERP market. He has never been shy about taking the logical next step implied by the off-the-record comments he gleans from his own investigations. This “unofficial” commentary gives us a much clearer indication of SAP’s future than the official “PR” material that shows up in brochures and in conference booths.   

But the best thing about a conversation with Bobby Cameron is that his quotable “sound bites” on all things SAP are fully integrated into a well-thought picture of how the ERP market is evolving, with change as the only constant, and a fully-integrated, web-enabled supply chain as the inevitable next phase in this business evolution. In Cameron’s view, the more adaptable SAP can become, the bigger share of this extended ERP market it will get.  

In the first part of this interview [each interview section will be briefly introduced here] Cameron gives us a look back at the first Package Applications report…..etc to be added at publication time.]] 

January 10, 1999

Jon Reed: Bobby, what is Forrester’s take on the IT marketplace?

Bobby Cameron:
Our whole view is that things change and that change is a constant. Technology is a key factor in overall business change, and in fact our current tag-line is “Technology Changes Everything.” Our role in the overall IT market is to help people thrive on change -- so we create models to help people understand and embrace technology-driven business change. That’s really what we do, so when we write, think and work we frequently have that as our orientation. People who don’t know that’s what we’re up to -- even when we use the words in what we write and what we say -- can get misled. So you’ll find that I recommend SAP even though I’ve got a reputation for being an SAP hater. 

Reed: In your “Packaged Apps” reports, you’ve outlined several key concepts that impact the SAP marketplace. One is the trend towards component-based ERP apps, another is portfolio assembly, and another is the implications of an extended ERP/best of breed/front office market. Tell us about how SAP is faring within these areas.   

Cameron: I think SAP works where it works and it doesn’t work where it doesn’t work -- just like PeopleSoft -- same thing. So having said that, you picked up on the two, probably the three key theories that we’re working on in the Packaged Apps service. One is the component/apps theory, the other is the channel transition that’s part of the portfolio assembly model, and the final one has to do with where the user/buyer technology need is.  

The component story is a real simple one. I grew up as an IT Director in Chase Manhattan’s electronic banking business. My job was to tie about 8,000 treasurers in large corporations worldwide with about 100 bank offices worldwide to do all kinds of information transaction work, and one of the challenges that we had from that perspective -- and it’s been there forever, was change. The challenge was change, but the expectation was that this new world of client-server and objects was going to come save the day. Much later we looked around and said, “Well, what did client-server turn out to be? It’s nothing like our dreams and fantasies.” SAP, PeopleSoft, all those guys are, in effect, a class of terminal-host style applications. Now PeopleSoft’s a fat client -- it’s a stretch to say it’s terminal-host, but it behaves just like one: slap a form up in front of data and do something with it. It’s not a new class of applications, just the old form and data model.  

Reed: That brings us back to the remarkable debut of your packaged application series in April 1996, with the release of the “Prudent Approach to R/3” report -- a report which has been credited for knocking SAP stock down quite a few points after its release.  

Cameron: Actually, SAP is responsible for it (laughs), because they kept bringing that report up. Even four months later, SAP blamed bad financial performance on our report, and it may or may not have been true. 

Reed: In that first report, you said some pretty pungent things about SAP. One such example: you encouraged users to have an exit plan from R/3. 

Cameron: That’s correct. And be prepared to use it. 

Reed: You also said that R/3 was basically a legacy system going in, which definitely went counter to the buzz that the ERP packages were trying to create about being a new wave of cutting-edge applications. And you also predicted a full scale, Internet-based SAP product, possibly called R/10, which would be a complete replacement for R/3.  

Cameron: A brand new product. 

Reed: A totally re-written product... 

Cameron: Restructured new technology.

Reed: So how do those predictions look to you from this vantage point now? 

Cameron: You missed the one prediction I was wrong on, which was the revenue decline of R/3. I predicted this would be a declining revenue year. 

Reed: Right, you said SAP would level off in ‘97 and decline in ‘98. And the other thing that looks like you were wrong on -- I don’t know if you’ll agree -- is that you said SAP would not do well trying to take its product down into the mid-market. 

Cameron: Yes, that’s exactly correct. That’s another error we made. In fact, part of R/3’s success is its down-market success. Let’s start with that one, the revenue issue, which gets in most people’s craw. There are several things we missed. One is that we did miss that down-market success -- in the last two years, SAP’s biggest growth engine has been down-market. Certainly revenue-per-seat is lower; revenue-per-sale’s a lot lower. But the aggregate growth is huge. In U.S. operations alone, the down-market accounts for over fifty percent of the sales last year.  

The second thing was that I was very naive about the overall surge in the apps market. I just had no idea that we would see this unprecedented buying behavior, although it is stopping now. BaaN lost money last quarter. [ERP sales] are certainly slowing down. SAP’s miraculously kept it above 40% but they’re also slowing down. That surge we’ve seen is just far beyond anything that’s ever happened in the package industry and I don’t think we’ll see it again. There were way too many stars aligned. I misjudged that huge surge, so that was the second key piece.  

The third reason is that when we wrote that report, we were a bit careless in our wording. It wasn’t our thinking -- our thinking was on, but our wording was poor, in that when I was talking about R/3 decline, I didn’t isolate the accounting revenue and HR-related revenue and even single plant manufacturing revenue from everything else. That was a bad job we did in actually building that report. What I really believed would fall off from core R/3 revenue is those categories. The new outward-facing stuff, which is showing up as APO and New Dimensions apps, I believe will be a growth engine, and by SAP’s own estimates, will be 30% of revenues by 2001. SAP is in fact seeing a decline of accounting and HR and overall R/3 revenue, though the middle market’s propping it up so it’s nowhere near what I thought it would be.  

So you throw all that together and that estimate was off. The thinking underneath it was right on. I had talked to over a hundred CIOs to prepare that report and I was taking models for the report from the most successful R/3 sites --  SAP’s favorite accounts. Companies like a DuPont -- and even they’re not 100% R/3. They may be 60-65%, max 70%, depending on the account. In fact, DuPont has a very good program for rolling R/3 out, where they wrap the hell out of it; they pre-configure it for what they need to do, then roll it out as the tool it is. And I think they’re heavy into Manugistics around supply chain and they’re merrily going along there, and I don’t know what they’re doing for sales force automation and the like, but the point is they use R/3 as a tool that’s appropriate. So that’s where the whole exit strategy came from -- it says, “Look, you may have no choice but to put in PP or even PP-PI, but manufacturing’s changing, and the next generation of manufacturing’s going to be very different.” We believe, and it’s no news to anybody, that APS will in fact displace MRP -- that APS will generate bills and routings and work orders and schedules directly. 

Reed: Right, because it’s been understood for a long time that Enterprise Resource Planning is kind of a misnomer, that the planning functions are really underdone and undercapable -- ERP is really more of an operations program. 

Cameron: That’s right, and to supply chain’s credit, it’s been pretty’s only now getting mature. But if you look at the way Red Pepper does it, when PeopleSoft sells MRP or manufacturing, it is an APS engine that’s doing the work that MRP used to do -- but it’s fully constrained. That’s my point. And if you put PP in today, tomorrow you will say “What’s SAP going to do for manufacturing?” and the answer is APO -- and don’t miss that. So that was our whole message about an exit strategy. We said: “Put PP in, it may be the best product you can get, but be ready to change later.” Of course, SAP didn’t have APO on the list at the time, but when you put APO in, it won’t be built, as you probably know, with ABAP technologies. Even though SAP swears, “Oh it’s just an extension to ABAP/4,” -- sure, and Java’s an extension to FORTRAN.  
January 17, 1999

Reed: But when you look back on that first report, there was more that was right than wrong. That report ushered in the end of that so-called honeymoon period for SAP, when people were just buying it and expecting it to solve all their business problems. And as you look at how the market’s evolved since 1996, your points about the lack of flexibility inherent in a tightly-integrated, monolithic suite of apps has certainly come to pass. In 1996, you were already anticipating the “extended ERP” market, and your contention was, and still is, that to capitalize on the promise of “supply chain” and the so-called “front office” apps, that your IT solutions will need to be very agile and dynamic -- two words not usually associated with ERP systems. You raised questions back in 1996 about whether ERP was flexible and adaptable enough for the fast-moving post-Year 2K market, and those questions are still a major issue for SAP and all the other major ERP vendors.  

Cameron: Right, and what we said is: “SAP’s smart; they’re an engineering firm and they will understand the value of new technologies, and will in fact leave ABAP behind” and they have done so. That was a transition that we projected and it’s showing up as New Dimensions, so every New Dimensions product is built without using the existing repository, without using the existing reference model. Now as a development methodology, yes, they’re maximizing the re-use of data and definitions and the like, but it’s not ABAP -- it’s C++, it’s Java, it’s different code. That was probably the key stuff in that report -- the component message.   

Reed: Soon after the first report, you began laying out your prediction that ERP packages would begin breaking themselves down into “plug and play” components -- you were one of the firms to anticipate the trend towards component-based ERP packages. 

Cameron: Right, and we weren’t really saying anything new in that report, just trying to be clear about what it is. We could have done some numbers at the time, but it wouldn’t have worked. You probably saw our June ‘98 piece where I went to 44 apps vendors and structured the component message much more clearly. In essence, the component idea has several key pieces from my perspective. One is that everyone knows if you build modular things you can re-use them more easily. There’s no new message there -- it’s also obvious that if I can break things apart, then I can re-use the pieces more easily. That’s very clear. Where there’s a lot of difference is in how big the things are and what characterizes the things that you break apart. And it’s classic since COBOL days to think of modular business logic -- good procedural code has in fact been modular forever.  

Where issues arise is the question of what you do with the data. And I’m a real heavy data-centric guy. I believe that the world turns on data, and that you can discover how easy an application’s going to change based on data. In fact, my understanding of how tough R/3 was going to be to work with came when a user was describing to me how, in the 3.0 release, if you changed the fixed asset table structure -- the data table structure --  you’d also have to test the PP code, the production planning code, because they shared the same physical table. 

I grew up as a developer, and so it was real clear to me that [SAP’s data structure] was going to kill you. With tons and tons of SAP developers now, about 4500, that’s a real clash of integration. In fact, I’ve been told by some SAP developers that they don’t adhere to those stringent shared tables. In fact there are now five or six versions of an invoice inside of R/3 -- but no one will tell you that. These developers would come up with a need for an invoice and they didn’t want to go through the mechanics of changing the shared table so they’d just go build a new one. So that’s what the data issue is around SAP. Now let’s put it back in the component context. Only half of the apps vendors understand that they need to break the data apart as well as the business logic. 

Reed: And which vendors understand and which don’t? 

Cameron: If you pull up that June ‘98 report, you’ll see them all on a table...  

Reed: So you’re standing by the assessments published in that report?  

Cameron: Yes. On the right-hand side of the table, those are the guys who are not planning to disaggregate the data. (editor’s note: the companies Cameron is referring to, in alphabetical order, are: ACCPAC, Aurum, CONNECT, CWC, Great Plains, HBOC, Hogan, i2, IMI, JBA, JDA, Open Market, Oracle, PeopleSoft, Pivotpoint, PowerCerv, QSP, Richter, Siebel, SQL Financials, Trilogy, and Vantive). 

Reed: And you think that’s a fundamental business mistake right now? 

Cameron: Yeah. What they’re doing is putting abstraction layers in so that they theoretically isolate the data structure from the code. That’s a classic approach. But if you go talk to a developer who’s done that in a highly volatile applications base like supply chain or customer management, they’ll tell you that you bloat the middle. That abstraction layer gets bloated and becomes a problem. 

Reed: Over time, your thinking on ERP components evolved, because in October 1997, in the “Portfolio Assembly” report, you seemed to adjust the ERP component prediction from a pure “best of breed” market into a new “core apps” market prediction. According to the Forrester “core apps” scenario, you envision companies making a single core apps “back office” ERP choice, encompassing ERP financials, HR, and possibly basic manufacturing, all provided by one vendor, for low cost and ease of integration. In your view, the ERP back office is going to be dominated by one of two camps, either SAP with a Microsoft technology platform or Oracle Apps with an Oracle technology platform.  

Instead of a pure “best of breed” market, your new scenarios predict that companies will take advantage of core apps in the back office areas, and that either SAP or Oracle will become the “enterprise backbone,” with a best of breed “front office” market built on top of it, adhering either to Oracle or SAP interface standards. At the time of that October 1997 report, you envisioned SAP and other ERP vendors functioning as “portfolio assemblers,” actually integrating other vendors’ apps on top of their own, according to the end clients’ preferences. Is that how you’re seeing it now?  

Cameron: Most of that is correct. With the sole exception that SAP’s interest in playing as a portfolio assembler seems to have been focused in U.S. operations with Paul Wahl in particular, and with Paul’s exodus there is an absolutely unambiguous statement that portfolio assembly was Paul’s thing and now they’re not doing it. They do have their partnering programs; they’ve got the strategic partners that are on their price list -- there are about five of those now -- it won’t grow to a very large number. And they tell me -- I’ve not seen this --  but they tell me that their level two solution maps list a bunch of the CSPs and they’re in fact featuring alternate non-SAP solutions. But in essence their marketing message is “We’ll do it ourselves.”  

Reed: In terms of what customers want, your theory is that customers are mostly going to say “Let’s get one back-office, no-brain, cheap solution and use our best of breed money on this cutting edge technology.” 

Cameron: That’s right. And SAP has taught them to want a single source for solutions. Dial 1-800-FIXIT and someone fixes it. And given that SAP’s not going to act as an assembler…[there’s an opening for the major consulting players to move in on the portfolio assembly business]. That’s why PWC, last month at SAPPHIRE, announced their first portfolio based on SAP.  

Reed: Why don’t you describe how you define “portfolio assembly” and how you see it applying in today’s market and beyond. How do you describe the term to someone who’s never heard it used in the packaged apps business? 

Cameron: The driver is the need for the user to minimize the integration burden, which in that report of July ‘96 was 30% of total spending for a large IP shop. So that’s the driver: “I want to be able to cut that burden and yet keep up with the apps.” And users are best of breed every time I’ve measured it, by far and away -- they have a best of breed strategy. The question then is: what are the operational pieces that you need to make that happen? The key is for someone who has outsourcing skills to outsource the integration -- meaning if I’ve tied Manugistics and R/3 and Siebel together, those guys are going to change their apps at their own pace and the whole bundle has to change. Every time they change -- who’s going to do the work?  

What I’ve seen is users turn increasingly to their systems integrators and say “Give me a fixed price for five years to integrate these apps and support their integration,” outsourcing the integration. Now in order to execute on that, the systems integrators say “That’s actually a very good business for me. I can do it for one company and I can do it for another half dozen. I spread my cost and I get this annuity stream and if I’m good at it I make a high margin. And if the user’s got a lot of money they’re spending internally, they’ll be happy to share some of that with me.” 

Given that that’s the driver, the systems integrators are then saying, “Well, I’ve got to pre-assemble these things. I’ve got to put some money on the table to tie these things together so I’ve got something I can support. And for the user to buy it, I’ve got to target an industry.” So what happens is we see about half the systems integrators doing this today. They pre-integrate a set of solutions, which increasingly they’re going to sell. They of course try to implement them. And then they do varying levels of support on them, at least supporting the integration, but we see them taking on full level one and level two support. So that’s the model. The model is that in response to the users’ need for best of breed, but the desire for a single source and someone to outsource the integration in response to that drive, systems integrators are re-making themselves to pre-integrate solutions, targeting specific industries that they then increasingly will sell but definitely implement and support.  

Reed: And in ERP terms, you see these systems integrators focusing on either the SAP or Oracle back-office camps and building around one of the two... How does that address the needs of the end client?  

Cameron: There are two classes of camps. One is “Just give me the back-office apps.” For lack of a better term, let’s call them “corporate apps,” because they’re things that headquarters wants. We originally put manufacturing in that core and it behaves differently than the other apps, but it really doesn’t belong as a corporate app because it’s operational. So it’s really accounting and HR that are at the base. The other piece of the platform is the technology. There are two pieces of that of course. There’s the message handling, which is COM/DCOM versus CORBA, with COM/DCOM having a two-to-one edge, and the second level of that platform is the API structure -- how the applications actually talk to each other.   

January 24, 1999

Reed: Moving into the so-called “extended ERP” market, ERP vendors obviously want a piece of these new markets, which are now mostly being served by smaller, specialty players. You’ve outlined four key growth areas in extended ERP: Internet commerce, supply chain optimization, customer management, and industry-specific apps. ERP vendors want this business badly. They’re all going about it in different ways -- SAP’s mostly building the new apps themselves; Oracle and PeopleSoft are leaning more heavily on partnerships. Do you see ERP vendors getting this business? Or do you think that the smaller, nimbler third party vendors are going to get this business? How do you see it playing out? 

Cameron: It’ll vary by company. SAP is a conservative company. Paul Wahl represented the non-conservative side of SAP. SAP as it remains now, with the existing board having reasserted its strength with Paul’s departure, is very clearly about products -- it’s a product-centered company. They’ll do services as much as they have to, in order to make sure that the product goes in cleanly and reliably. And they’re not into delivering risky products. SAP is very successful, first of all, around tangible goods. So in tangible goods industries, SAP has strength. In the services industry, they have very little strength and quite frankly very little likelihood of deep penetration.  

The second thing to characterize SAP is stable vs. unstable processes. Even in the tangible goods world, if you look at high tech manufacturing, the leading edge is leaning less and less on SAP. Yes, Intel and Compaq are happy SAP customers, though if you look at what they’re doing for supply chain and where they’re going with those products it’s not SAP. Dell looked at SAP and said “Sorry, I can’t do what I’m trying to do with you.” Now, SAP could in fact tackle the risk stuff and probably do very well. It’s just not their culture. So when they deliver APO, they will do APO as planning and scheduling around the well-known, well-understood functions: you take orders, apply them to constrained plans, and out comes the schedule. That kind of work has been around for four or five years. So SAP’s going to be very successful with apps based on classic planning and scheduling. But if you talk about anything to do with logistics, which is wide open, and time planning and optimization with execution in the logistics world -- brand new, leading edge logistics, anything to do with the extended supply chain, SAP’s just not there.  

A year ago, SAP told us that “The way to do extended supply chain is R/3 everywhere.” They’ve backed way off that, but that just shows their conservative thinking and therefore, coming back to your question, they will in fact be providers of products for stable processes, especially in goods-related industries, for manufacturing and distribution. They will have less success around unstable processes: high tech manufacturing, telecom, utilities, all those guys. Now we’re into services as well and in the services industry they’ll have a lot more trouble.  

Reed: And do you think that customers are likely to say, “Hey, SAP has built in their own sales force automation product, so we’ll go with that,” or are they going to say “Sales force automation is too important to us, we’re going to go with the best of breed solution for our industry there?” 

Cameron: Track the classic company. If you’ve got a flat-top, low-change company, they’re much more likely to be quite happy with what SAP offers.  

Reed: So you think it comes down to the industry, the company’s culture and their attitude towards risk. 

Cameron: That’s right. Yesterday morning, I had a room full of quite mixed industries. There were eight industries in there -- retail, a couple major high tech manufacturers, oil, gas, utilities, and it was quite interesting testing this idea. Being Forrester customers, because of who we are and what we think, they’re all out trying to push the envelope and they agreed 100%. They’re very happy with R/3 for what it does. But they’re not necessarily going to buy into R/3’s extended supply chain products. Now for the other ERP suppliers: BaaN we think is going to be relegated to, in fact has been relegated to, a component supplier, and their game is to do the extended supply chain in their target industries, which is the industrial sector. That’s a huge challenge for them. With Aurum, BaaN also has an excellent customer management opportunity.  

Reed: PeopleSoft? 

Cameron: PeopleSoft: they’re trying to do what SAP has done, and that’s the biggest mistake they could possibly do, because their entire market penetration has been best of breed. Yet now they’re trying to make the suite play, and it’s not that they shouldn’t try to do the suite play, but the best of breed’s where they’ve won business, and it’s where we believe they have sustainable advantage. They will obviously continue to be a dominant player in HR.  

PeopleSoft is also setting up a program to try to develop partnerships and the like, and will try to establish their APIs as a platform. We believe that they will succeed in building a proprietary platform, but we don’t believe that they’ll succeed at being the preferred core, except for the HR piece of menu systems, because they’re non-standard. They don’t have DCOM or CORBA and they don’t have component technology in their blood and they’re not good at partnering. They’re a buy/build company and the cultural shift is tough and it’ll be too little too late.  

Reed: Oracle Apps? 

Cameron: Oracle Apps: obviously the other official portfolio assembler now, other than Price Waterhouse -- their challenge is that they’ve been trying to become a solutions company, instead of a technology company. Inside Oracle, it’s the product side against the solution side. The database is a commodity. We believe they will in fact continue to survive. We don’t think they’re going to do a Sybase on us. 

Reed: So you don’t think Oracle is fully committed to its Oracle Apps business? 

Cameron: Well, they say they are but we’ve heard that before. Oracle’s been a generation to a generation-and-a-half behind technically forever. The other side is that they’ve decreased about 25-30% of their investment in their CAI partner program. They’re trying to compete on the hot markets of front office and supply chain in the industrial sector, so that’s going to pit them against partners. What they need to do is get some very clear strategies of where they want to play as lead and where they want to be a partner and base it on the ability to succeed. I don’t think I’d want to take on SAP in the industrial sector. In automotive I would and also in high tech manufacturing. In Aerospace I wouldn’t want to touch them. If I took SAP on I’d want i2 as my buddy. 

Reed: Absolutely. Do you consider J.D. Edwards in this leading ERP class or not? 

Cameron: Yes, but with a very clear -- bless their hearts, it’s good for them -- middle market strategy. 

Reed: Any dark horses that you see emerging? 

Cameron: There are always dark horses. Intentia out of Scandinavia seems pretty solid. I think the real dark horses are going to show up as variants of portfolio assembler suites. Somebody who says, “I don’t really care about the rest of the stuff, I’m going to remarket R/3 and just ignore all that other stuff and I’m going to lead the way.” Now, I don’t know who they’ll be, or exactly how they’ll pop up, but there’s a lot of creative thinking. You look at Cap Gemini and Origin and some of these guys. There’s some real clear thinking.  

Reed: Let’s talk about SAP’s Business Warehouse initiative. The other critique you’ve levied on ERP packages is the difficulty of accessing data for strategic purposes. Is that an area you see a lot of growth and challenge in? 

Cameron: Growth, challenge, opportunity, all that stuff. Obviously the information is a very important piece of the puzzle. If you don’t have visibility up and down the supply chain, it doesn’t matter what you can do with the transactions. Up and down the supply chain, across the company -- it’s all part of the same animal and you’ve got to be able to execute that. SAP, to their credit, has recognized that this whole solution space is integral to certain classes of business function.  
Business Warehouse is featured more in their APO investments than in the other areas, for good reason. I think it will be increasingly featured in their FOCUS investment. Essentially what they’re trying to do is to create closed-loop styles of opportunities, where you analyze data, you make a decision, and you take an action. And that’s part of a solution. Now they’re not alone in that. Their business partners like Business Objects, IBI, and Cognos -- these are all trying to move up the food chain.  

Reed: But in your component-based vision, one vendor couldn’t solve a company’s problems with data access and analysis... 

Cameron: If it’s a multi-vendor environment, it’s going to be very tough for SAP to be the cross-function solutions supplier. They will, in fact, be a solutions supplier for key functions where their apps are core. In the accounting world, to do your monthly management reports, you tend to use the ones supplied by your general ledger vendor. But you don’t use that general ledger vendor’s reporting product to go do your manufacturing returns.  

Reed: So do you think the systems integrators are the ones who are going to capitalize on the need for an all-encompassing data solution?  

Cameron: It’s a combination of that and users’ own investments. The user needs to have a consistent strategy across all their functions and applications. Systems integrators are developing ever more aggressive businesses in that area.  

Reed: A long time ago, you predicted Microsoft making a packaged apps play, taking what they learned from SAP and entering the market. Do you still feel that way?  

Cameron: Specifically what we said was that Microsoft’s apps play is to make it easier to link applications together in the Microsoft environment than to do it anywhere else. And they are, in fact, doing that. In financial services, they have an initiative called DNA FX, which started out as consumer-to-bank, and it’s now bank-to-bank, bank-to-broker, consumer-to-broker... they’re essentially defining key points in the interface, and building components that they distribute as “templates” in developer toolkits.  

Reed: So you see Microsoft playing more of a complimentary role to SAP than actually taking over SAP business share at this point?  

Cameron: That’s correct, but they are starting to shift the SAP business proposition and help SAP to do what they’re doing anyway. SAP is increasingly confirming their historical commitment to being a product, as opposed to any kind of a services company, and what Microsoft is doing is making is possible for services-based businesses to more easily subsume R/3 as a piece of their offering, and SAP’s not going to do that. SAP’s BAPIs head that direction, but Microsoft’s actually going to make it easier.    
January 31, 1999 

Reed: Your new theory of where innovative companies are ultimately headed is called “dynamic trade.”  Your vision of dynamic trade involves the strategic use of leading edge apps, working towards a new kind of extended supply chain with Internet-enabled, demand-driven forecasting. Define the term “dynamic trade” for us, and then we’ll look at how the ERP market might be affected by dynamic trade. 

Cameron: “Dynamic trade” is the leveraging of technology to satisfy current demand with customer response. It’s a pretty simple statement, but it’s got a far-reaching impact. It will vary by industry, but there are three rules of dynamic trade.  

One rule is that services eclipse products. In high tech manufacturing for PCs, you can compete on price, but Dell is trying to be able to do online, custom sales to make sure you’ve got good service capabilities, so if you have any trouble you can respond to them directly. At Compaq, if you’ve got to fix a problem, they don’t ship the PC all the way back to Texas; they actually can do the repair in a distribution center run by Fed Ex. We’ve also seen utilities companies talking about selling 71 degrees Fahrenheit, instead of selling power at so much per kilowatt hour. The utilities companies would partner with Johnson’s Control to put in the HVAX system and operate it, and they would sell the temperature, and essentially the customer pays to keep it at 71 degrees.

For banking, we think that for the emerging affluent (people earning over $55,000 a year), the financial services industry will create --is creating-- a new class of product which combines lots of instruments -- investment, insurance, banking -- and gives a performance analysis and advice about what to do. In all these cases, services become a more important differentiator than the product itself. Merrill Lynch, with its very upscale clients, differentiates itself by how it services those clients, and it’s therefore able to charge more. 

Reed: And your second rule of dynamic trade is “demand drives production.”  

Cameron: Yes, and that is specific, custom product delivery.  

Reed: And right now, even the most sophisticated software planning tools don’t enable demand-driven production...  

Cameron: Most do not. In particular, if it’s anything to do with an extended supply chain they don’t.  

Reed: And the third premise of dynamic trade is...  

Cameron: “Prices match the current market.” That would mean instead of getting weekly, or daily price tables, having information that is much more immediate and much more current.  

Reed: And at this time, you don’t see a suite of cutting-edge applications that are enabling these changes, right? It’s still a best of breed situation with companies patching together their own solutions...  

Cameron: Right, and where you’ve got stable suites of products from a single vendor is where the business process has been around for a while and pretty well understood. At the leading edge, you and I could argue for hours about what the right business process is. I argue with automotives and high tech manufacturers who say, “The best thing I can do is to reduce the total amount of suppliers I’m dealing with, and get long term contracts so we all work together.” And I’m saying, “No.” VW cut its supplier network by 30%, and two thirds of its suppliers went out of business as a consequence, and now when VW gets under price pressure, who are they going to turn to if one of their suppliers doesn’t respond? So we don’t know what the best practice is because it’s not been proven; it’s brand new, and the packages are all over the map.  

Reed: And for companies, it’s not just a matter of getting the right software, it involves organizational and cultural changes.  

Cameron: Yes. I class it into four things: the relationships themselves -- the contracts among suppliers, customers and partners have to change; the processes themselves have to become more flexible, more agile; of course the technologies themselves have to become more tolerant of change, more supportive of change; and then the organization themselves have to be change-oriented, including managing outsourcing as a core competence.  

Reed: I guess that results in your quote: “The key to dynamic trade is agility, and that’s where ERP stumbles.”  

Cameron: That’s exactly right.  

Reed: So you see ERP as fitting somewhat uneasily into this new, change-oriented business spectrum.  

Cameron: That’s right, that applies to the bulk of ERP that you can buy today... the only exception I can think of is in the process industry -- it’s Marcam’s brand-new product.  

Reed: So would it be fair to say that your take on ERP for customers right now is: implement ERP if it will deliver a pre-defined value related to transaction-oriented work; otherwise, focus on the outward-facing apps, the cutting-edge apps like extended supply chain, Internet commerce, and customer management, and use a component-based strategy to drive the whole thing?  

Cameron: That’s absolutely correct.  

Reed: So will there be a shift in focus where ERP systems, drawing on transaction-based functionality, don’t seem as cutting edge to buyers as dynamic trade apps? Are we going to see a time when companies will want to spend more of their time and money on these cutting edge areas, paying less attention to ERP and less money for ERP implementations?  

Cameron: It’s cliché, but I believe it’s true. We haven’t done any hard evidence on it -- it’s hard, actually to measure it, because people lie. But the dissatisfaction or the surprise as far as users go -- users who, having completed a big R/3 installation, are surprised that they didn’t get any further than they got -- is pretty intriguing. And I believe, in essence, what we’re seeing is the user community waking up from this honeymoon as you called it, a period of the ERP era and realizing “Oh, I was just doing some hard work to clean up my crap.” In fact, if you look at some of the smarter companies, they figured it out in the process of putting R/3 in and backed out -- if you look at where PP’s in, it ain’t in a lot of places. It just isn’t.  

I can name you some of the top SAP accounts, and the plant guys turned around and said “You want me to do what? Why?” And I believe that sort of questioning is what’s at the heart of it and the same thing is true for supply chain. We got very a clear message from users in general, not just an SAP base, that they believe supply chain’s not going to be ERP’s strength. And if I come back to my model of SAP, supply chain on the APS side has been around forever, and SAP will do well there, absolutely. That is SAP’s strength and they’ll do it well. And as for the rest of the supply chain, as it matures, SAP will do a knock-down-drag-out job of it. They’ll whip people’s asses.  

But when you consider the leading edge stuff such as drive and demand forecasting, not to mention doing it all in a creative way that’s real, SAP’s got its hands full. When you consider the extended ERP world, with the ramifications that come from the dynamic trade model, which starts to imply real coordination, starting with the logistics part and extending into the entire optimization, planning and execution phases -- SAP’s going to have a real challenge getting that business. And if you add outsourcing to that loop then you need some God-awful good component technology. You need products that are built from the get-go to integrate.  

Reed: And do you need a new kind of professional?  

Cameron: Now that is absolutely true! I believe the class professional is one who’s agile -- it’s actually what SAP’s been breeding. The opportunities out there are for people who understand business process, who are able to drive solution at that process and who understand that the opportunity is for flexibility not for stability. There’s been this orientation that manufacturers are about increasing velocity while driving greater efficiency. Now you hear people say “Let’s add in responsiveness along with velocity.” So I think that’s the right direction and with dynamic trade, we’re now talking about agility. I define agility as changing direction at speed without rolling the Isuzu over. If you’ve got agility, you can execute dynamic trade. 

The technology side of that is only a piece. There’s the organizational side, a huge process side, and a relationship side. Technology is key to making that happen. To execute dynamic trade, companies are going to have to have in place a very good set of technology. And the best thing to look at is someone like a Dell, with all the postponement strategies, the merge-in-transit stuff that’s going on...those are exactly the model. They don’t do a good job of extended supply chain, but no one does. 

Reed: Not yet. It’s such a new frontier. That’s a bit of a cold shower, though, for the aspiring ERP professional trying to get into the field right now, as the rates may start to go down when companies turn their resources to other areas. You’re espousing a slightly different model for IT professionals, which is “Don’t just focus on what you can do well right now if it looks like those skills may be obsolete next year -- push for new technology exposure.”  

Cameron: Right. Take your skills to market. And the skills that ERP people have, especially SAP guys, is that they think process. And they are used to working with tools that have process at the core.  

Reed: So you think that ERP professionals have a new thinking pattern because they’re not thinking in terms of silo-functional responsibilities, but in terms of overall business process. And you’re saying “Take your skills to the next level and just expand them beyond the boundaries of the enterprise and into the partners and suppliers and the extended supply chain...” 

Cameron: I was working with the CIO of about a $30 billion company earlier this week and a team --  a cross-divisional team -- that was chartered with coming up with a new architecture. The methodology they were trying to adopt is one that has, at its core, trying to understand what the business drivers are and what the processes need to be to support that, and then what the capabilities are that the company has to have to satisfy that or implement that and then obviously what the architecture has to be to support that. This is an excellent approach. Out of twenty people, the three who understood what that was about were the SAP people. Everybody else who was locked away in engineering or somewhere else didn’t understand that and that’s a huge asset.  

Reed: Bobby, thank you for giving us such a thorough assessment of the ERP marketplace.