Chapter 10 • Methodologies for Purchased Software Packages 403The long-term disadvantage is that the organization
becomes dependent on an external IT provider not only for
the initial installation and perhaps some package modifica-
tions but also for the ongoing maintenance of the package.
Although in many cases this can result in a strategic
alliance of value to both the vendor and purchaser, the
purchaser might not fully anticipate the coordination costs
associated with managing the vendor relationship. In addi-
tion, of course, there is the risk that the vendor will go out
of business or be unresponsive to the needs of the purchas-
ing firm. There can also be pricing hazards if the vendor
makes it difficult for third parties to compete for support
services.
Special Case: Enterprise System Packages
By the end of the 1990s, the majority of U.S.-based
Fortune500 companies and more than one-fourth of
European-based midsized organizations had invested in
a first wave of enterprise system packages: enterprise
resource planning (ERP) systems. Most companies pur-
chased these systems in order to achieve business benefits
(e.g., cost reduction, more efficient business processes, and
faster compliance with legal requirements), but ERP
investments are also IT platform investments (see the dis-
cussion of major vendors and ERP benefits in Chapter 5).
One of the primary business benefits associated
with ERP systems is to enable access to a single repository
of integrated data, sometimes real-time data, for better
management decision making. This is accomplished by
getting most business applications on a common platform,
the ERP system. Because most ERP systems are built to
support cross-functional business processes, there will be
fewer system interfaces to maintain. Further, ERP mod-
ules that can be “configured” to be used by different types
of firms in different industries enable those firms that have
already conducted projects to reengineer their business
processes to now implement them; building custom
systems to support new cross-functional processes would
require a much larger system investment over a much
longer time. However, an ERP system is not a total infor-
mation system for an organization; rather, an ERP system
itself will meet only roughly 70 percent of the needs of the
organization (Markus, 2000). Thus, it is important in
selecting an ERP system to consider how the system will
interface with existing operational systems with which it
must share data. Such interfaces may not be trivial
because the software platforms of legacy applications can
be quite different than the platform for the more modern
ERP system.
Adopting an ERP system is a major undertaking for
any organization, and there are potential risks and costs
(see Fub et al., 2007). ERP systems are very expensive to
purchase, plus there likely will be significant consulting
fees to assist in configuration and installation. Like any
package, but more so because of the comprehensive nature
of ERP, the package confines an organization to the capa-
bilities of the particular package. The ERP package may
establish standards for the platform for all systems that
will interface with it. Also, an organization becomes very
dependent on one vendor for a sizeable portion of its core
business applications. The task of deploying the ERP
package, which includes turning off legacy applications in
the organization, is complex and can be perilous to contin-
uing operations. These are all important risks and costs,
hence, the decision to acquire an ERP package and how to
manage its deployment are critical.
For the IS departments within firms that purchase an
ERP package, this could also be the first time that their
project team personnel would be asked to configure a
package in the best way possible, rather than to custom
develop an application based on the requirements of their
business users. IS and other project team personnel, as well
as business users, must be sent to training classes, typically
conducted by the software vendor, so that they can learn
the packaged software as well as learn new vendor-specific
languages for writing interfaces and queries. Because, out
of the box, an ERP system is a generic, semifinished prod-
uct, IS and other personnel must learn how to configure the
software for the options that are best for your organization.
New “business analyst” skill sets may also be required to
effectively manage the process steps for a packaged
software project, rather than a customized life-cycle
methodology.
Another key characteristic of the early ERP projects
has been the heavy reliance on third-party consultants who
are not employees of the software vendor, such as consult-
ants in the Big Four or smaller consulting firms. These
“implementation partners” are usually invaluable for help-
ing an organization quickly learn how the software pack-
age operates, as well as how the complex business process
options embedded in each module would work. Because of
the large scope and complexity of some of these ERP
package implementations, one of the key management
challenges has been to what extent to rely on the external
consultants to lead an ERP project and how to make sure
the purchasing company captured the needed knowledge to
continue to operate and “fine-tune” the configurations after
the consultants left. More recently, firms that host ERP
installations for several clients (see the subsequent section
on ASPs) can be relied on to keep the ERP application
running and maintained to the latest releases of the