Columns

Q&A AMR Research's Bruce M. Richardson

The emergence of enterprise-wide client/server applications during the 1990s promised significant changes in the way IT organizations do business. Costs would be cut and development backlogs would be eased. But the reality has been different from the promise. Bruce M. Richardson, vice president of research strategy at AMR Research, Boston, and an expert in the enterprise applications business, recently shared his views on the future of the industry with Editor Mike Bucken.

Are packaged applications cutting costs and implementation times for corporate IT organizations?

Well, I don't think the tools for the ERP and supply chain are installed so much for cutting costs. There's a reuse issue, and I think there's faster time to market. That's why we see the big push by all of the major vendors to offer components that can communicate via some messaging scheme to other applications. Then the big application vendors can cut the time from 18 to 24 months between releases to something approaching an annual basis. I think there's a myth that customers want vendors to develop big, multi-user application versions in Web months or Web weeks. If that happens, they have to deal with a couple of major releases a year. I remember a vendor bragging to a user group about doing three major releases a year. One of the customers stood up and said, 'Hey, while your patting yourself on the back, you better ask your customers what that means, because to us, that's cruel.'

Are ERP vendors getting that message?

Well, I think the pendulum swung the other way, and now you have a Baan or an SAP, for example, that now have as much as two years between major releases. And so the amount of brand-new code that you're sending someone is daunting -- the implementation of the new release can take as long as the original implementation.

Is the move to component-based applications helping the implementation process?

Yes, components are speeding the release process. The issue around components, though, is that the messaging architectures tend to be immature. Once you move from all of this procedural code you wrote to more of an object-based architecture, you're missing the superhighway to connect the two worlds together. So you have this semantic messaging. That's where the gaping void is.

We just interviewed some of the early pilots for the SAP supply-chain software, which connects to R/3. We asked whether any part of the software is missing. And they said, 'Yeah, the interfaces to R/3.' That's a bit of a fatal flaw. If you're selling it on the basis of integration, and the integration doesn't exist, well that can be a bit problematical. The same is true with Baan. You look at all the companies Baan has acquired and the different pieces they tried to write themselves, and realize that messaging is going to be the hang up. They conceptually can draw the diagrams to see how everything fits, but few of the interfaces to all the pieces are there. That's what holding it back.

How are IS development groups modifying packaged ERP software?

In the old days you bought the software, and you probably did some pretty heavy modifications to it to be able to adapt it to the way that you like to take an order, place orders or check credit. Now the software is so complex -- there are so many tables in the system -- that you see people change the way they do business rather than change the code. They know that going from say release 3 to release 4 blows away all the custom interfaces they've developed, creates many database changes and creates a long-term nightmare. Now IS directors or VPs are forced to put the stuff in 'vanilla.' The whole idea of flexible applications has gone right out the window. That's one of the hopes of components -- that it may bring back a little more flexibility. But then again, because there are so many interdependencies on all of these things, sort of like human gene structure, you're afraid to tamper with one piece of DNA for fear that it will let loose a virus in another part.

Is a lack of flexibility hurting?

I think it's adding to the implementation time and the cost of modifying the applications. And there's the huge training issue. I think it probably limits how quickly you could change to a new application set as your business changed. So, you're pretty much locked into concrete.

How far off is a return to flexibility?

Everything in this industry goes in cycles. But you [need to] look at what's happening, where people are trying to simplify the desktop operating systems and the desktop applications to make it easier to add features and change. Right now the problem is big applications. We're starting to deploy them wider and wider inside organizations, so I think it's probably going to limit our flexibility for the next three to five years. One of the interesting things is, if you buy ERP software for your company, typically 10% to maybe 20% of all employees have a seat for the system. Whereas it's closer to 100% or even 150% in most organizations for Microsoft Office.

One of the things you're going to see is SAP and Oracle pushing [more and more products to their installed base] because they know the ERP business is going to slow in 1999. They want to continue the quarterly growth they're showing, so they're going to go back and try and sell more products to their installed base. If they've sold financials and order management in the past, they're going to go back and sell manufacturing, human resources, sales force automation and supply-chain management.

We're not going to have that flexible an architecture. The interdependencies are going to get more complicated. I think there's a general recognition in Fortune 1000 companies that unless the implementation of an ERP system has begun, I'm just going to do a system selection now because there's no way I'm going to get the system installed in time to beat the year 2000 deadline. What you'll do is look for last minute Y2K fixes or problems, or you'll look at applications that aren't Y2K dependent. You know, for a lot of the supply-chain management applications there is decision support and simulation. There's no database to worry about or dates.

What do you think will happen beyond Y2K?

I love the excuses vendors are using for missing their quarters. I've seen everything from Japan being a factor, even when a company gets 1% of its sales from Japan. Or the impact of the Euro or Y2K on financials. As long as the economies of the U.S. and western Europe stay relatively strong or show growth, the application business will be fun. There is a perception in the last couple of years that because of Y2K, people are rushing to get stuff done. I don't think that's the case. I think it's a case of a weaker vendor, getting between 70% and 90% of revenue from the installed base over the last couple of years. Because those people didn't have time to change.

But as we get into 2000-2001, some of those older applications could be great candidates for replacement. If Baan doesn't turn its financial operations around, we could see some widespread replacement among its largest customers. They could become SAP customers. There's always a lot of turnover in the base. In the past, the expected life cycle of an SAP system was five to eight years. Now it's about 10 years. I'd say realistically in any given year, probably 10% to 12% of the base turns over. The reason we're going to see continued fast growth is that deals are getting bigger because we're trying to create custom applications for every user. So whether it comes from the ERP vendor or if it's the new e-procurement or e-billing or whatever-you-can-dream-of to take advantage of the Internet. I think we're going to continue to see the application explosion.

Are there any opportunities for some of the smaller vendors or even start-ups?

There will be more opportunity for some of the smaller vendors to come out with new stuff. The challenge is that even the smallest vendor can find itself right in SAP's radar. SAP can spend $750 million to $800 million on R&D. That's more than the next five vendors in the ERP space will spend on R&D. Clearly, SAP is looking at covering the whole waterfront.

Do you think they can do it?

Do I think they believe they can do it? Oh, absolutely.

What changes do you see coming to the packaged applications business over the next few years?

I think it would be great to survey CIOs that have installed SAP to find out how it's been to pretty much give up their IT infrastructure and cede control to these guys. They have become the ecosystem -- they can totally dictate upgrade schedules or what new applications need to be bought. Then you can find out whether CIOs wake up at some point and say, 'Wait a minute, we're totally trapped in SAP. We want to look at a new flexible way of doing things and I don't know how to do that now.' It's one of those industry cycles we go through. Sometimes we like going with one vendor, and buy as much as possible from that vendor so we're not in the systems integration business. Then the pendulum swings, and we hate being totally dependent on one vendor. We feel like we've lost all flexibility.

I think SAP is going to have an issue at some point when a whole new technology comes up and provides flexible applications. Then customers will be forced to transition from today's older procedural-based applications to some whole new way of doing things. I think the only thing that could upset that natural evolution would be for a Microsoft or an Oracle to attack parts of the enterprise application. I keep thinking in the back of my mind that Microsoft doesn't want to be in the ERP business. But there are some parts that are completely horizontal and that could work across all businesses.

I could see Microsoft introducing Microsoft Sales Office, which provides all of the Siebel [Systems]-like functionality and price it at an annual fee of $99 per user or $500 per user, something like that. I could see them doing Microsoft HR Office and coming out with sort of the core HR applications that you might want. And I could see Microsoft Financial Office, because after all, general ledger is pretty consistent. There are some parts of the applications that I could see Microsoft upsetting the cart on and coming out with these sort of departmental or personalized views.

Aren't these horizontal systems mostly for relatively small businesses?

Well, it could be smaller businesses and it could be for large businesses. You know where Microsoft can exploit that backlash. Maybe it will be 2005 or 2002, but there should be a backlash against big, all-encompassing applications. The new applications will let CIOs decide that 'Hey, the cost of ownership is much cheaper if you buy a set of components for Microsoft, and maybe link into the manufacturing or production modules from another vendor.' Then you have a system that you can sort of snap together. This should come when we've solved the realtime messaging issues, and then get a new set of APIs endorsed by the industry. Then we'll have more flexible architectures.

How realistic is this scenario?

I don't know. I think anything is possible. I look at what Microsoft must do to grow over the next five years in order to maintain its market cap, its dominance in the industry. I think they have to look at all possible new ways of doing things. I think going out and trying to replace an entire system like SAP would be impossible. They could buy a Baan or an Oracle or someone like that, but I think we're going to see them nibble at some of the pieces over the next three to five years. Conversely, they could do what eopleSoft did with the PeopleSoft business network. PeopleSoft wants to be the start-up screen and provide the interface into the Internet, extranets or an extended enterprise. Everyone wants to
provide that sort of application portal to control access to the outside world. I could see Microsoft feeling threatened by these guys and coming up with clever schemes of their own. Then again, I could be completely off base.

Featured

Most   Popular
Upcoming Events

AppTrends

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.