Chapter 10 • Methodologies for Purchased Software Packages 407
critical when an organization enters into an ASP agreement.
A purchasing process that carefully assesses the capability
of an ASP to provide reliable performance, security to the
organization’s data, and the likelihood of the ASP surviving
in the marketplace are especially important for ASP con-
tracts, because this market is still in its infancy. Some of
these risks appear to be diminished when the ASP host is
also a large software vendor—such as SAP or PeopleSoft
for ERP modules or Siebel Systems for CRM modules. The
ASP host may not be in the business of integrating their
hosted software with client-hosted software; thus, the ASP
model works best for stand-alone applications. Also, the
host will not customize the software for the client (beyond
any customization features built into the software such as
including your organization’s logo in computer-generated
documents). Security (ensuring your data will be protected
from access by others, especially those in competitor
organizations using the same hosting service) can be a con-
cern, but most ASPs provide high-end security services.
Finally, the hosting service may require you to convert to
new versions of the packaged software, which may not be
when you want to convert.
Metrics for vendor performance and penalties for
noncompliance should be a key part of the contract.
Aservice level agreementshould be part of the contract, in
which specific performance expectations are set for various
operational metrics—such as system uptime, recovery
time, wait time on calls to the help desk, notifications about
software upgrades, and other factors important to the
customer. As described in the box entitled “A Dream Versus
a Nightmare,” if you do not do a good job with the ASP
selection process up front, you risk paying the price later.
Summary
Purchasing packaged software is an alternative to custom
software development that has been increasingly pursued
by organizations of all sizes since the early 1990s. The fact
that packaged solutions can be implemented more quickly
than a custom-developed solution with the same, or simi-
lar, functionality is a major advantage in today’s fast-
changing business environment. A major disadvantage can
be increased dependence on a vendor that could go out of
business.
The process for purchasing an application is based
on the same life-cycle phases as a custom approach:
Definition, Construction, and Implementation. Even if an
application is to be purchased, an organization first must
define its basic system needs before attempting to select
the best off-the-shelf application solution. The Definition
phase also includes the development of an RFP to be sent
to software vendors and an evaluation of the vendor
responses. If successful, the Definition phase ends with a
vendor contract, which should be negotiated with the help
of contract specialists.
The time spent on Construction phase activities
varies greatly depending on whether or not the source
A Dream Versus A Nightmare
It was an IT manager’s worst nightmare. The OshKosh B’Gosh Company online store was open, but
the orders went nowhere: The communications link between the clothing retailer and the company
that hosted its Web application had gone down. Resolving the nightmare was further complicated
because the ASP with which OshKosh had contracted had subcontracted with another firm to
host their application. And OshKosh’s telecommunications carrier needed to get into the hosting site
to repair the equipment. According to CIO Jon Dell-Antonia at OshKosh, “It was like the Three Stooges
and the Keystone Cops combined. If I went through the whole litany, you’d be rolling on the floor
laughing. But we were not laughing at the time.”
One common mistake companies make when choosing an ASP vendor is that they involve their
application specialists in the meetings with the prospective ASPs, but not their computer operations
specialists. According to an analyst with the Gartner Group, customers should concentrate not just on
the A in ASP—the application that will be provided—but also the S—the service. You need to carefully
document your needs first, before you start talking to an ASP.
[Based on Anthes, 2000]