Vous êtes sur la page 1sur 3

Part B - Information Systems and Information Technology Solutions

B.4.5. Selecting an Acquisition Alternative


An objective comparison of options for the acquisition of software applications is rarely possible. A
completely objective analysis can be done only if one assumes that absolutely equivalent systems
would be acquired and only the manner of acquisition would differ. Table 1 compares the four
software acquisition alternatives.

Part B - Information Systems and Information Technology Solutions

Table 1. Summary of Project Requirements and Application Software


Acquisition Alternatives
Acquisition Alternative

Project
Requirement
Contract

Not applicable

Tight control of cost


And schedules;
recourse against
contractor possible;
may include
warranty and
support

Development or
Acquisition Cost
Implementation Cost
Systems' Reliability
Flexibility in
Meeting User's
Requirements
Maintenance and
Ease of Modification

High

High

Purchased
Package
(Turn-key)
Predefined cost
and schedule; ease
of specific
performance
statement;
recourse against
vendor well
defined; should
include warranty
and support
provisions
Moderate

High to moderate
Moderate
Excellent

High to moderate
Moderate to high
Excellent

Moderate to low
High
Moderate

High to low
Moderate to low
Minimal

High with permanent


in-house staff,
difficult otherwise

High with support


contract, low without

High if performed
by vendor,
probably extremely
difficult otherwise

Confidence in Final
Product's Operation
(1-4) where 1 = low

2. (assuming
competent staff)

3. (assuming
competent
contractor)

4. (assuming
proven package)

Planning and
Analysis
Requirement

Full conceptual plan


Required; general
Analysis completed;
minimal detail
design required

Implementation
Time/complexity
(1-4) where 1 = best
Staffing Needed

3.

Full conceptual plan


required; general
analysis completed;
full detail design
defined; milestones
defined; project
management plan
completed
2.

Conceptual plan
necessary for
package selection;
general analysis
completed for
adaptation; no
detail design
required
1.

Project
management,
administrative
functions,
systems analysis

Administrative
functions,
minimal project
management
required

RFP preparation,
contracting, project
administration,
contractor reliability,
staff acceptance of
system, long-term
support

Package
capabilities and
adaptability, staff
acceptance of
system,
maintenance,
modifications,
upgrading, longterm support

Limited to support
available from
original developer
and quality of
documentation
1. (assuming no
previous
widespread
distribution)
Conceptual plan
necessary for
package selection;
general analysis
completed for
adaptation; no
detail design
required
4. (generality and
documentation
problems)
Project
management,
administrative
functions,
programming (if
outside support is
unavailable)
System capabilities
and adaptability,
reliability,
implementation
support and cost,
documentation,
long-term support,
maintenance,
upgrading,
modification,
staff
acceptance

Major Potential
Problems

In-house
Development

Project
management,
administrative
functions,
systems analysis,
systems design,
programming
Technical staffing,
personnel
management,
project management,
cost control, control
of system scope

Contract
Development

Transported
System
Not normally
available

Low

Part B - Information Systems and Information Technology Solutions

Although theoretically possible, this assumption is unlikely to be the case except possibly in a
comparison of in-house development and contract development. The following assumptions about
acquisition alternatives could reflect a more realistic set of circumstances:

The in-house staff is competent, but not as experienced or technically strong overall as the
staff a good contractor could provide, and there will be turnover in the in-house staff.

The contractor has worked in the same or a closely related application area, will not be prone
to miss schedules, and will not fully comprehend all aspects of the hospital's management
requirements.

The packaged system comes close to the actual requirement but will require modification,
and the package has been successfully installed beyond its original development point.

The transported system was originally developed to meet a very specific set of requirements
for another facility and it is not well documented.

Each of the four alternatives offers inherent advantages and disadvantages. However, all the options
share several basic requirements:

Determination of minimum system requirements must precede any move to acquire an


information system.

Planning for the implementation process must be carefully developed and documented well in
advance.

Policies and procedures to support the systems must be established before implementation is
complete.

Management commitment to and support of the system must be very strong and evident.

In many situations, the best approach may well be a combination of the four options. For example, a
reliable system might be available from another health organization or an independent software
vendor that appears to meet the majority of the organization's needs. In this case, a contractor could
be employed to make modifications to the software and assist in implementation planning and
conversion. In-house staff could be hired to assist in the modification process, conduct staff training,
provide conversion support, and provide long-range system maintenance.

Vous aimerez peut-être aussi