Information Technology Reference
In-Depth Information
Metaphor for Selecting an OTS Product
Select the right metaphor for implementation of enterprise software, which
is often one of the strategic IT undertakings for many organizations — it
can be a long and arduous journey. The metaphor we recommend is that
of learning a new language. For the company, implementing a new OTS
product is like learning a new language — albeit these are languages with
non-natural language names such as SAP
. They have gram-
mars and lexicon familiar to few, yet they must be learned consciously
by an organization.
Now consider how one gets to learn a language. There is the formal
element, the informal element, and the practical element. For example,
one needs to know the formal syntax, query elements, nomenclature, and
data elements used in the OTS product. These are best gathered through
classroom sessions with an experienced trainer. It would be inefficient to
try to understand these concepts only by “playing around” with the
product. On the other hand, there is hardly any substitute for using the
software in practical situations, to learn aspects that cannot be learned in
the classroom. Most end users who have used an OTS product over a
period of time can tell you of very practical and ingenious ways of doing
things with the product.
®
and Siebel
®
The Dependency Factor
A frequent and normal fear while choosing an off-the-shelf package is
that it makes one “dependent” on the vendor, possibly “forever” (i.e.,
lock-in). This fear is understandable. It is one good reason why products
must be selected carefully, after looking at factors beyond functionality
and price.
From where does this dependency arise? How is it different from a
dependency on some other technology? After all, if one has developed a
system in COBOL or Java, one is dependent on that. How different is it
from, say, selecting a “corporate” database such as Oracle? In discussing
dependency, one often mixes business and technology dependencies.
The business dependencies include economic factors; once one is
“locked in” to a package, the vendor can raise prices. Exit can be painful,
expensive, and risky, especially after one has captured a number of
business rules in the package. To be fair, this exit barrier could be equally
bad in an in-house development, in case the business rules are scattered,
undocumented, and cryptic. There is still another business angle, especially
in enterprise management software. The introduction of a particular prod-
uct within the company introduces a strong gradient to use that product
in other areas within the company even where it may not offer the best
