402 Part III • Acquiring Information Systems
Purchasing Advantages- Reduced time to implement
- Lower overall acquisition costs
- Reduced need for internal IS resources
- High application quality (debugged and best
practices) - Infusion of external expertise (IS, business)
Purchasing Disadvantages- Risks due to lack of package knowledge
- Risks due to extent of organizational
changes required - Initial and ongoing dependance on vendor
FIGURE 10.7 Advantages and Disadvantages of Purchasing
Packaged Software
Purchasing Advantages and Disadvantages
Figure 10.7 summarizes the advantages and disadvantages
of purchasing packaged systems, as well as some potential
long-term advantages and disadvantages for buying pack-
aged software solutions.
ADVANTAGES The primary project advantage is that,
compared to customized application development, less time
is needed to implement the system. Nevertheless, for mid-
sized systems, the entire process will still require several
months, and for large-scale enterprise software implemen-
tations (with packages such as ERP systems), the process
can take several years to implement enough modules of the
software to achieve a net benefit.
A second major advantage is that packaged software
implementations can be very attractive from an economic
standpoint. For example, a small business can obtain a
complete accounting system for less than $25,000, which
is very low compared to the cost of developing a compara-
ble customized application. Assuming that the vendor has
more than 10,000 installations of this small package ($250
million in revenues), the vendor will have an incentive to
spend millions of dollars on improving the package in
order to issue new releases. Everyone comes out a winner
because each purchaser has cost avoidance from purchas-
ing a package, and the vendor makes a large-enough profit
to stay in business and provide upgrades and other support
services on an ongoing basis. As shown in Figure 10.2, the
initial purchase price of a software package might be a
relatively small fraction of the total cost of acquiring and
installing a software package.
A third temporary advantage is that in-house IS
resources could be freed up to develop mission-critical
applications that could provide the firm a competitive
advantage if software packages can be implemented for
relatively common processes that provide no specific strate-
gic advantage.
Two potential long-term advantages are application
quality and the infusion of external expertise. The quality
of a software package might be substantially better than
that of a custom system, because a vendor can afford to
spend much more time and effort developing the system
than an individual company. Also, the package may
include best practices or choices of best practices for dif-
ferent situations. The documentation can be much better
than the typical in-house documentation, and new releases
of the package might incorporate improvements recom-
mended by companies that are using the system.
Furthermore, each release is usually thoroughly tested,
including a beta test in a client organization.
Finally, a packaged solution is a quick way to infuse
new expertise—both IT expertise and business expertise—
into the organization. Given the fast pace of technological
change, most organizations today find it difficult to train and
retain IS personnel with expertise in new, emerging tech-
nologies. Software vendors often have the funds and motiva-
tion to develop systems using newer technologies. Packaged
solutions for a particular industry, or large ERP systems,
also frequently have best-in-class processes and procedures
embedded in the software. By purchasing the software,
companies can also adopt better business processes.DISADVANTAGES Two major project risks are also asso-
ciated with implementing purchased packages. One risk is
the lack of package knowledge. The package implementa-
tion can require significant training for IS as well as busi-
ness personnel, which increases the implementation costs.
Because of an organization’s relative unfamiliarity with the
software package, the organization might also not be as
quick to leverage the capabilities of the package as it would
be to leverage the capabilities of a system that members of
the organization had designed and custom developed. Some
organizations also make the mistake of initially modifying
the package, or adding other functionality, only to learn
later that the package could have provided the same func-
tionality if it had been implemented differently.
Another related project risk is that since imple-
menting a packaged system often requires significant busi-
ness process changes, there are greater project risks.
Knowledgeable business managers and skilled IS special-
ists need to be significantly involved in the Definition
phase to understand what organizational changes need to
be made. Furthermore, there often is more user resistance
due to the extent of changes required in order to implement
the packaged solution.