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.