Managing Information Technology

Chapter 10 • Methodologies for Purchased Software Packages 397

1. P&Ls:
   Appearance
   Ease of retrieval/access to


2. Modeling:
   Ease of use
   What-ifs
   Goal-seeking
   Quality of modeling
   What-ifs
   Goal-seeking
   User friendly?
   Screen presentation
   Movement around screen
   Saving a model/What-ifs
   Language
   Platform
   Complexity
   4. Update:
   Ease of using a What-if to create new
   projections
   Functionality of update
   Update security
   User friendly?
   Screen presentation
   Movement around screen
   Saving the update
   Language
   Platform
   Complexity
   5. Reformat:
   Ease of reformat (and time)
   User friendly?
   Screen presentation
   Movement around screen
   Saving a model/What-ifs
   Language
   Platform
   Complexity


3. Change Analysis:
   Accuracy
   Report presentation
   Consolidation accuracy

FIGURE 10.5 Continued (B) Example of Evaluation Worksheet for Vendor Demonstration

Choose

Alternatives

Identify

Discrepancies

Change

Procedures

Live with

Differences

Modify the

Package

Needs of

the Company

Capabilities of

the Package

FIGURE 10.6 Matching Company Needs with Capabilities of
the Package

packages, there are three major alternatives to choose from.
As shown at the bottom of Figure 10.6, the company can
change its own procedures to fit the package, investigate the
feasibility and costs of modifying the package, or imple-
ment the package “as is” and work around the differences.

An important factor when choosing among these

alternatives is fully understanding the additional develop-

ment effort and costs that would be required to modify the

package in order to tailor it to the company’s needs and

integrate it into the company’s environment. These alterna-

tives therefore need to be made in collaboration with

internal IS specialists and the vendors of the top candidate

packages in order to be sure that the extent of the discrep-

ancies havebeen fully identified and that the feasibility and

advisability of modifying a given package have been fully

considered.

If system modifications are a viable alternative, the

plans for which organization will be responsible for pro-

gramming the changes and the total costs of these changes

will need to be taken into consideration. Further, the

impacts of modifying the package need to be evaluated for

not just the initial system project but also for subsequent

maintenance and package upgrade projects. For example,

many companies that purchase today’s large complex

enterprise system packages, such as an ERP system, are

advised to avoid reprogramming portions of the package in

order to avoid the costs of continually modifying new

releases of the package in the future (see the later section

entitled “Special Case: Enterprise System Packages”).