Software packages have lagged behind the software tools. This is to be ex-
pected because software vendors must rewrite their systems using the new tools.
This occurred with the vendors’ adoption of database management systems,
fourth-generation languages, client-server systems, and intranet systems.
Packages now have exibility through control tables and, to some extent,
through object libraries. The next wave of change in packages may be toward
object-oriented software packages in which an organization customizes an
application much more than is possible with tables.
The popularity of software packages is growing for several reasons. The
packages have more capabilities than in the past. Companies lack the internal
resources and time to develop the software on their own. The internal legacy
systems have aged to the point where many must be replaced (e.g., Year 2000
problems). Management views these packages as a rapid fix to both business
processes and systems —just shove the package and fit the process around the
package. Failure occurs often because of this last faulty assumption. Processes
are not rubber bands or silly putty that can fit anything. Instead, they re ect the
unique organizational, cultural, social, political, and industrial settings of the
firm at that time and place.
In the past, you could select a package and then modify it to fit your current
process. Many vendors now resist this for several reasons. First, customization
brings problems in keeping new versions of the software compatible with
various customized efforts. Second, vendors only make profits in overhead on
time and materials for customization. It is often more fruitful to devote these
resources to new releases and versions of the core software.
No comments:
Post a Comment