The Enterprise Shops for Packaged Applications
BY PHILIP J. GILL
When considering whether to buy enterprise
applications rather than build them, a strategic approach is called for.
Off-the-shelf software is taking on new significance for information systems
(IS) managers. In past years, such packaged software typically has been
desktop productivity applications. Recently, however, a number of factors
have combined to make packaged software more appealing to managers higher
up the enterprise computing ladder: the success of popular desktop products;
the economies of scale inherent in mass-market software; the growth of independent
software vendors (ISVs) who specialize in applications for the enterprise;
and the general shift from proprietary, centralized legacy systems to open
systems-based, distributed client/server environments. More and more, major
IS organizations are turning to packaged software to meet their enterprise
computing needs, particularly for so-called back-office operations, such
as accounting and financials, purchasing and inventory, distribution and
warehousing, human resources, and manufacturing.
"There's been a strong trend in that direction for the last couple
of years," says Clare Gillan, director of applications and information
access research at International Data Corp. (IDC) in Framingham, MA. "Companies
are trying to provide users greater access to information and to reengineer
their businesses. Generally, when they reengineer, they want to become more
process-oriented than department-oriented. Legacy systems have a hard time
adapting to that."
IDC's research shows momentum in that direction. In 1994, combined software
license and service revenues for packaged client/server applications approached
$6 billion worldwide. And Gillan forecasts the market continuing to grow
at a compound annual growth rate (CAGR) of 37 percent for the next three
to five years. (see
But buying packaged software for the enterprise isn't like buying it for
PCs. An IS manager shouldn't expect to stroll down the aisles of a local
computer store to pull an enterprise accounting suite off the shelf, for
example. Buying and using packaged software at the enterprise level are
considerably more complicated and require a well-thought-out strategic approach.
Better to Buy
The first step is to make the buy-versus-build decision. Fewer and fewer
IS organizations would prefer to build their own applications, given the
clear benefits of buying packages.
For one thing, packaged software almost always costs less than internally
developed applications. ISVs can spread development costs over many customers
during the life cycle of a given product; when an IS organization decides
to roll its own software, it is the only one bearing the costs. "Buying
is always better than building, because of the large investment needed to
build a client/server application from scratch," says Bobby Cameron,
director of the software solutions service for Forrester Research of Cambridge,
A second consideration is that buying packaged software allows IS organizations
to better deploy their own existing internal resources. For instance, instead
of building accounts payable or general ledger software, programmers at
an investment brokerage could invest their scant resources in developing
trading applications or stock evaluation algorithms that could give the
company a competitive edge and contribute directly to the bottom line.
Third, packaged applications almost always can be deployed more quickly.
After all, most of the work is already done by the time it gets into user
Fourth, packaged software is likely to be more robust and stable, with fewer
bugs. Naturally, if an IS organization decides to beta-test a new package
or if the application chosen is relatively new (less than a year or so),
it should expect more problems. However, most of the popular packaged software
products are several years old and mature enough to have most of the bugs
Finally, buying packaged software allows the user organization to leverage
an ISV's collective expertise in a particular application area, such as
financials or human resources. It's often simply not possible to have that
kind of depth in-house. And even if it was, recruiting such personnel would
certainly drive up costs.
Case in Point
James Madison University, a 10,000-student, state-run institution of higher
learning in Harrisonburg, VA, recently chose PeopleSoft of Walnut Creek,
CA, to supply three key applications--human resources (HR), accounting,
and a student information system (SIS)--for its move from a legacy mainframe
environment to a campus-wide distributed client/server network.
Allen Cerveny, associate vice president of enrollment services, says the
university was impressed with the quality and features of PeopleSoft's Human
Resources Management System (HRMS) and its Financial accounting suite, but
what sealed the deal was that PeopleSoft has staffed its new educational
software division with professionals seasoned in SIS software.
"We felt we would benefit from being involved with people who have
developed student information systems before," says Cerveny. A prominent
software vendor can recruit top talent that a single university couldn't
afford on its own, he adds. In this case, JMU and PeopleSoft will jointly
develop the new SIS, and JMU will act as a principal beta-test site.
Users and analysts also agree that it's easier for ISVs to keep pace with
new technologies. An IS organization's time and resources are better spent
addressing the needs of the business than studying every facet of IT advances.
When to Build
Despite all these reasons, there are times when it makes sense or in fact
may be necessary to build. If a specific business need is not met by any
packaged application, the company that wants the app may have to develop
For instance, organizations on the leading edge of IT may outstrip the market.
Russell Lewis, CIO at Jeffries & Co., a Wall Street investment brokerage
firm, says that when his previous employer, Salomon Brothers, another Wall
Street brokerage, made its first moves from centralized legacy systems to
distributed client/server computing, it had no choice but to build. "Back
in 1989 there wasn't any packaged software out there to speak of,"
says Lewis, who works out of Jeffries' IS operations offices in Jersey City,
NJ, across the Hudson River from New York.
Today, he says, things are different. In his new job at Jeffries, the IS
department is consciously choosing to concentrate its expertise and internal
resources on a few core applications it considers essential to achieving
a competitive advantage. For the rest of the applications, Jeffries will
buy packaged applications wherever possible, in large part simply because
now it can.
But not everyone is so lucky. Mark Cates, director of logistics systems
for Seattle-based Airborne Freight Corp., says some aspects of operations
are so industry- or company-specific that his company sometimes has no choice
but to build applications, or parts of them, on its own.
Bill Connor, vice president and director of IS for Motorola Corp.'s General
Systems Sector in Tempe, AZ, says his organization buys 75 to 80 percent
of all its software from outside suppliers. "I wish it could be 100
percent," he says. But he acknowledges that there are times when this
isn't feasible. "It's probably better to build when it's directly related
to your line of business or when the application provides a revenue-producing
service to customers," he says.
Yet Lewis is adamant about avoiding major in-house development. "I
see building software as an option of last resort," he says.
Once the buy decision has been made, IS should work with users to determine
the features and specifications they need. Users should be in on the process
at the beginning, but it's part of the IS role to help them see beyond the
constraints of their current system.
In some cases, going with packaged software may involve not just a new IT
infrastructure, such as a move from mainframes to client/server networks,
but major reengineering of business and workflow processes. That may be
a change the organization needs to make anyway. It can learn, say IS managers,
from the wealth of experience that established client/server ISVs bring
to the party.
"You have to be prepared to change the way you do things to fit the
software," says Connor of Motorola. His group provides information
services and support to Motorola's computer systems and cellular telephone
Part of buying packaged applications means being willing to accept the business
and workflow processes embedded in them, says Connor. Often, a user organization
can learn a useful thing or two that would improve efficiencies of operations
and cut costs. But Connor adds that users shouldn't take extreme measures
to adapt to packaged applications. "It shouldn't be the tail wagging
the dog. It's got to be a good balance."
The most important thing, IS managers agree, is to instill a sense of ownership
in the new client/server software from the outset among its target user
population. If they don't feel that this is their choice but something being
forced down their throats, the chances increase that the project will fail.
Even then, expect last-minute resistance. Connor recalls that recently one
department tried to back out of using a new packaged application shortly
after it was installed, saying they didn't think it would work out after
all. The department's users had been in on the requirements, evaluation,
and selection processes, almost from the outset--a fact that gave Connor's
IS organization great leverage at this critical moment. "I told them
that they chose it, so they'd have to live with it," he says.
As users are painfully aware, software vendors differ drastically in which
standards their products support. A user organization should have at least
a clear policy on what standards it demands. Some firms prefer strict allegiance
to industry standards, both de facto, such as Unix, TCP/IP, or Microsoft
Windows, and de jure, such as Posix. Other companies find it more important
to adhere to internal standards, even if those don't conform to industry
For example, Airborne Freight requires that all its packaged applications
run on one of two internal system architectural standards, either a legacy
IBM mainframe environment with MVS or its newer, distributed processing
environment, which is based on Hewlett-Packard HP 9000 servers, HP-UX Unix,
and the Oracle relational database management system (RDBMS).
"We don't want to support more than two architectures," says Cates.
"The costs are too high." In one recent case, the company chose
not to purchase a packaged warehousing and distribution application, even
though it met all of the company's functional requirements. The reason:
It was available only on the IBM AS/400.
As well as checking standards conformance, the IS organization should evaluate
a vendor of packaged applications in other ways. Is its technology sound
and up-to-date? How long has it been since the latest update or revision?
How old is the application? Is its architecture current, and will it suit
both short- and long-term needs of the buyer?
Cates of Airborne says a key evaluation criterion was whether the vendor
had built its application using a layered architecture. Right now, many
users at the company's ALS subsidiary use dumb terminals, but Airborne intends
to migrate them to X terminals or Windows PCs. "We want to be able
to slide out one interface and slide in the other easily," he says.
Another factor to consider is the ISV's financial health. Nobody wants to
be left with orphaned software. That puts an IS organization back where
it started, developing and maintaining key enterprise applications on its
What about service and support capabilities? If users need service 24 hours
a day, seven days a week, IS should make sure the ISV can provide it.
Furthermore, there are personality issues. Is there a fit between the IS
organization and the ISV? For instance, is upper management accessible and
interested in having and keeping your business? Can you develop both personal
and partnership relationships with the ISV?
Most users don't require that ISVs have comprehensive product lines. In
certain fields, such as warehousing and logistics, it's simply not possible
to find large ISVs with broad product lines, says Cates. Particularly in
warehousing, he says, the smaller firms tend to have more innovative products.
On the other hand, James Madison University made finding a single vendor
to supply all three applications a priority. "We were interested in
finding a single vendor because originally we had three separate committees,
and we were all competing for the same scarce resources," says Cerveny.
"We quickly realized we all had the same objectives and same goals."
An added benefit of having a single vendor, he says, is that it eases the
process of integrating applications across a network.
Once a vendor is chosen, negotiations begin. It is critical during the negotiating
process to establish clear guidelines for the vendor in terms of who is
going to customize the packaged application--the customer, the vendor, or
a combination of the two.
IS managers say it's usually better to have the vendor do it, at least when
making the initial purchase and installation. Later releases, updates, or
upgrades could be handled by internal staff, once they're up on the product.
It's also necessary to establish a schedule of deliverables tied to payment.
Payments should be made in portions, as the vendor hits targets. Don't be
afraid to incent the vendor with rewards for early deliveries, and don't
be afraid to hold back should it fall behind.
Flexibility is key. Motorola's Connor says that working with a packaged
software vendor is a two-way street. Naturally, as a customer, users expect
the ISV to be sensitive to their needs. But, he says, IS organizations have
to be aware of their ISV's needs as well. For instance, Connor sometimes
has paid a smaller vendor ahead of schedule, since it may not have the financial
resources to finish a project on time. This will be especially true for
more specialized application needs, in which case you'll have to deal with
Lewis of Jeffries & Co. says IS organizations should not be afraid to
get involved with those smaller ISVs, who often employ the most innovative
technologies or newest approaches. In some cases, where it fits with corporate
business objectives, he recommends that IS consider funding development
projects or even investing in a smaller ISV if its products or technologies
are potentially beneficial to the business.
"This way, you can put your two cents in and also be assured of the
quality of the products," says Lewis. At Salomon Brothers, he says,
such strategic investment and partnership agreements with small ISVs were
And never negotiate so tight a deal that the vendor can't make money. "You're
never smart pressing a small vendor to the point where they can't make money,"
says Airborne's Cates. In this regard, it's better to think of the ISV as
a sort of partner than an adversary over cost.
Nothing truly comes off the shelf in packaged applications for the enterprise.
There will always be some customization. How much depends on individual
companies. Most users agree that the best guideline is to look for the standard
application to provide at least 80 percent of the functions you are looking
for. Then be prepared to customize for the rest of the needed functions.
Luckily, according to Bob Bacon, vice president of finance at Groth, Inc.,
a Houston-based valve manufacturer, most packaged enterprise applications
today are so feature-rich that a large part of any customization process
is merely picking among options the package provides. In fact, Groth recently
purchased ManMan/X, a client/server manufacturing resource planning (MRP)
II system from Computer Associates International (CA) of Islandia, NY, because
it contained such extensive configuration options that users could tailor
the software to their business needs.
ManMan/X contained 80 to 90 percent of the features the business needed,
says Bacon. "There were so many options and tables in the package that
it allowed users to do the customization rather than go to the programmers
to do it," he says. "We modified screens to meet the needs of
Nevertheless, careful examination of a package's development tools, usually
included in the standard package, is a must. JMU's Cerveny says one of the
reasons his institution chose PeopleSoft applications was the high quality
of their development tools.
However, be careful not to customize packaged software so much that it becomes,
in essence, a proprietary application. First off, that's what the IS organization
is trying to get away from. Second, a high degree of customization will
make updates and upgrades to new releases more difficult to implement. Finally,
your organization would lose one of the basic advantages of going with packaged
applications--that is, getting more function at less cost, because the vendor
spreads development and ongoing maintenance costs over many customers.
Living with the Package
It's probably best to let the ISV do most of the initial installation and
train the user departments, say IS managers. But vendor involvement can
range from minimal to total.
Connor likes an ISV to get actively involved. "They know their product
best," he says. He even prefers the ISV to do all the customization
for the Motorola site. He says that such an arrangement usually helps build
better long-term relationships with the supplier.
Airborne takes a different approach. When it purchased CA's MRP software
for its ALS subsidiary, Cates says, the company chose to keep CA's involvement
to a minimum. Cost was one reason; the less the vendor is involved, the
lower the cost. The other was the desire to get its own IS staff up to speed
on supporting the product as quickly as possible. "A CA consultant
comes in once every two weeks or so to see how we're doing and answer questions,"
Once the software is up and running, that doesn't mean the relationship
with the ISV is over. In fact, it's just beginning. By now both parties
should have shared something--the customer shares its business needs and
direction, and the ISV its current and future technology. The most successful
business relationships between IS and ISV will be those in which both started
at the outset to build close business and personal relationships. "Remember,"
says Connor, "they're people, too."
* Philip J. Gill is a free-lance writer and editor based
in San Diego, CA. He can be reached at firstname.lastname@example.org.