The Information Technology Interaction Model*

Introduction
We refer to the model as the "Information Technology (IT) Interaction Model" because it rests on the
premise that the consequences of information systems in organizations follow from the interaction of
the technology with the organization and its environment. Understanding the nature of this interaction,
therefore, is central to leveraging the benefits and avoiding the hazards that information technology
presents for organizations. Consequently, understanding the nature of this interaction must be at the
core of understanding the information systems.

The model addresses the interaction of an information system's features with five elements of the
organization: (1) its external environment, (2) its strategy, (3) its structure and culture, (4) its business
processes, and (5) its IT infrastructure. The model considers the consequences of this interaction for
system use, for organizational performance, for the organization's personnel, and for the firm's future
flexibility. Moreover, the model relates various aspects of the interaction process to the phases of the
development and implementation lifecycles.

By combining these various components, the model integrates the many aspects of the Information
Systems design & implementation, including such topics as technology basics, what businesses
accomplish with information technology, how IT can change firm and industry structure, how
organizations acquire new applications, how firms manage IT standards, and so forth. At the same
time, the model serves as a formal foundation for the understanding of Information systems. And the
model builds practical skills, as well, since it can be used proactively in designing and implementing
systems or reactively to evaluate what transpired after the fact. In particular, the model lends itself to
use in case discussions.

The Premise
The consequences of information technology are non-deterministic and not necessarily positive. That
is, despite all the excitement surrounding the potential value of IT for business, the benefits of a given
system for a given firm may be non-existent, and the effects may even be negative. Indeed, the road
to information systems success is strewn with information systems failures.

Theoretical Background and Foundation

The definition of an information system commonly found in the textbooks: An information system
consists of "hardware, software, data, people, and procedures." we see that it considers the key
elements of the organization, such as people and business processes, to be subsystems of an
information system. If one were to diagram the definition, one would have a figure in which the
information system is the inclusive supersystem, whereas people and procedures-the stuff of
business processes and tools such as computers and programs are the subordinated subsystems
(see Figure 1). By contrast, the would-be MBA a future entrepreneur or CEO of an enterprise would
naturally draw the diagram shown in Figure 2. Here, the organization or enterprise is the
supersystem, containing, among other things, people, business processes, and information systems.

We find justification for our pedagogical model in general systems theory. As Ackoff so eloquently
states, it is not possible to understand a system by analyzing it alone that is, by simply decomposing
it into its constituent parts. One must first synthesize it determine its function in the supersystem, the
next higher-level system of which it is a part. In the case of an information system, this supersystem
is the organizational (or interorganizational) system to which it belongs. Briefly, the rule of thumb one
gleans from systems theory is "one level up, one level down." This rule translates to information
systems as follows: One first asks, "What is the organizational (or interorganizational) supersystem of
which this information system is a part, and what function does the information system play in this
supersystem?" Only then should one ask, "What are the information system’s features and
component parts and how do they enable the system to serve its function in the supersystem?" Not
only is this two-part synthesis-analysis procedure more consistent with the spirit of general systems

*Abridged from “The Information Technology Interaction Model: A Foundation for the MBA Core Course by Mark S.
Silver, M. Lynne Markus, and Cynthia”
theory than straightforward decomposition into component parts, but it is also consistent with the
manager's world view, in which the organization, not the information system, is the centre of the
universe.
Using general systems theory as a starting point, the fundamental theoretical assertion of the IT
Interaction Model is that the effects of an information system for an organization emerge over time as
the result of the interaction of the system with its organizational context.

Introducing the Model

Why organizations build information systems? The usual response is to derive economic benefits: "to
make money," "for greater efficiency," and so on. Probe a bit, and ask yourself "Do systems always
have these effects?" Here, we often get into the region of failures and "non-impacts" everything from
the recent CONFIRM debacle to the Productivity Paradox. Next, to ask yourself is about the potential
for negative impacts. Job loss, deskilling, loss of security, and computer-monitoring usually surface,
among others.

Now let us try to understand this model:

So, now that we have determined that information systems do not always have the intended benefits, what can
you do to ensure that (1) failure does not occur, (2) negative effects do not occur, and (3) positive effects do
occur? Can you do this by directing all your managerial attention and resources to the Information system itself?
Of course not. You must consider your information system in the context of your organization and what your
organization is trying to accomplish in its transactions with its environment.

At this point ask yourself how businesses succeed and fail. After some fumbling around, you will
arrive at something that begins to resemble "Theory of the Business." When all goes well, (1)
businesses understand their external environments of potential markets and various trends, (2)

2|Page
businesses undertake missions consistent with their markets, and (3) businesses develop the core
competencies needed to accomplish their missions. Failure can result from inadequate performance
on any of these core tasks.

Now, we are ready to address information technology. "Where does IT fit into the theory of the
business?" we ask. Here, we can get into an interesting discussion of IT as strategic versus IT as
support. The ante starts to rise as we ask what factors determine an organization's ability to use IT
either strategically or supportively. This surfaces ideas that relate to the concept of IT infrastructure.
For example, you might think that managers' IT knowledge and skills (key elements of a firm's IT
infrastructure, in our view) can affect the firm’s ability to deploy IT effectively. From there, we can
probe the details of IT infrastructure, such as networks, skills in application development, and so
forth.

If by this time you have not raised the question of "where do information systems come from," we
seed the discussion by asking it point blank. We briefly describe (1) the traditional system
development life cycle, (2) the major alternative methods of acquiring systems, and (3) how system
acquisition itself needs to be viewed in the context of the larger system implementation process. To
make the point, we ask the following:

Ok, now suppose you have gone out and paid $100 million for custom software for a strategic information
system. Someone drops off a bunch of diskettes on people's desks with a post-it notes saying 'I think you're
going to like this. Just install the system on your hard drive, reboot, and click your way through the online
tutorial. Sincerely, DP Jones, systems analyst jr. grade.' What do you think will happen?

Not surprisingly, this question should trigger your imaginations about, and prior experiences with,
system implementation and the characteristics of implementation success.

At this point, we have come full circle. We are now ready to tackle the more difficult questions of
when and why systems sometimes have negative effects that may reduce or even eliminate the
positive economic benefits that organizations hope for when they make sizable investments in IT:

When we started this discussion, we noted that information systems sometimes fail to have the expected
benefits. We have just shown that the implementation process can influence information system success or
failure. Does this mean that, as long as we implement it well, any information system is capable of producing
positive economic benefits? Or could it be the case that, to have benefits, the system must not only be well
implemented but must also be 'a good system?'

Usually, you will concede that the system itself has to be good.

"So, what constitutes a good system?"

Now there is much discussion of interface and user friendliness, and a few IT-literate souls will
venture comments about object-oriented systems, DBMS, 4th-generation languages, and the like.
Finally, we work our way around to the idea that systems have "design features" that define how the
system operates in its larger organizational and business context. These features must fit the
organization and its environment for benefits to occur.

Any number of different concepts can be used to illustrate the notion of "interaction between
information system features and organizational context” in our model. We might use such
features as restrictiveness and guidance attributes. We might use automate/informate dichotomy. Or
we might consider the distinction made by reengineering experts between designing a system that
automates the existing process and one that transforms it. These illustrations also allow us to connect
with the implementation issues discussed earlier, making the point that in order for the features to fit,
the system to be "good," and system effects to be positive, there must be an extremely effective
collaboration between IS professionals on the one hand and managers and users on the other.

3|Page
The Model

4|Page
What follows is an overview of the essentials of the model:

• System Effects
• The Organizational Context: The Environment and Elements of the Organization
• The Features of the Information System
• The Fit Between System Features and Organizational Context
• The Implementation Process

System effects

We begin at the end, discussing first the system’s effects, because ultimately these are what will
matter for the students when they enter the workplace. Organizations employ information technology
with the objective of producing positive effects and, if they are savvy, with an eye toward avoiding
negative ones. An essential assumption underlying our pedagogical model is that system effects are
nondeterministic and not necessarily those intended or anticipated by the system's designers. It
follows that MBA candidates must learn how to manage, influence, and cope with those effects as
best they can. Knowledge of the potential interactions between systems and various elements of the
organization is just the tool they need to do this.
System effects fit into three stages. Although not always thought of as an effect, one of the most
fundamental results of introducing an information system into an organization is that the system either
is used or is not. This first-order effect must not be neglected because it is quite common for systems
not to be used, and such non-use is a major reason for systems not achieving their designers'
objectives. If the system is used, the question of how the system is used-when, by whom, for what
purpose, and so forth-remains a significant issue. Systems are often used in ways other than
intended, sometimes with positive consequences, as when a decision support system also serves as
a tool for improving customer relations, and sometimes with negative consequences, as when an
executive information system is used to intimidate subordinates, thereby stifling creativity. So,
understanding if and how a system is used is an essential first step in evaluating system effects.

The second stage of evaluating effects is to assess the consequences of the system for the
organization. The model focuses on three classes of outcomes: (1) performance effects, (2)
consequences for people (the organization's personnel), and (3) future flexibility. Performance,
indicated by a "$"in Figure 3, includes such bottom-line results as profit, gross revenue, and market
share. For some firms, quality, service, and customer satisfaction are also considered performance
effects. Consequences for people include such outcomes as shifts in power and influence, job
enrichment, and deskilling. Future flexibility (the infinity sign in the figure) refers to the ways the
system may enable or constrain future information systems and strategic initiatives by the
organization. For example, companies that have invested heavily in mainframe computer
architectures and mainframe related skills are predicted to incur great difficulty and expense
converting to object-oriented and client-server architectures.

The consequences of an IS are not necessarily uniform. Some may be desirable while others may
not. Performance effects may be at odds with people effects; for example, a system might improve
profits at the expense of the quality of work life for company personnel. Various aspects of
performance may clash; increasing long-run market share may conflict with increasing short-run
profit. And the consequences for people may differ from one person to another; a system that
enriches or empowers one person's job may deskill or disempower someone else's.

A third-order effect of implementing an information system is that as a result of how the system is
used and its perceived consequences for performance, people, and future flexibility, adaptations will
be made over time to the system, other elements of the organization, or both. At FritoLay, for
example, changes due to the hand-held computer project and the improved IT infrastructure enabled
the organization to shift from a one-year planning cycle to a three-times-a-year planning cycle,
dramatically improving the rate of organizational learning. Similarly, it has been suggested that, as

5|Page
with any new technology, a period of learning, adjustment, and restructuring may be necessary
before the full return on an IT investment is reaped. Figure 3 depicts these adaptive effects in the
form of a feedback loop at the bottom of the diagram.

Managing the effects of an information system entails not only understanding the range of possible
outcomes but also understanding the factors and dynamics that produce those effects. Armed with an
understanding of the effects to look out for, we now turn to the organizational context that makes
particular effects desirable or undesirable and that influences if and how such effects occur.

The organizational context: environment and elements of the organization

In our view, the effects of information systems ensue from interactions between system design
features and the organizational context, which includes the organization's external environment as
well as such internal elements of the organization as its strategy, structure, and culture. Moreover, a
system's design features are themselves often heavily influenced by the organizational context. For
example, the Republic of Singapore's extreme dependence on foreign trade led it to build an
information system (Tradenet) that would significantly reduce the time required for shippers to clear
customs, because this was believed likely to give it competitive advantage over other ports in the
region. And the extent to which Tradenet actually resulted in the desired effect depended heavily on
interactions between its various features and a variety of contextual factors, such as the behavior of
potential users and competitors.

It follows that an adequate understanding of the organizational context is important for two reasons.
First, the organizational context determines what the features of an information system should be, if
an organization is to achieve benefits from its IT investment. Second, the organizational context
interacts with the features of the information system the organization actually implements (which may
not be the features it needs) to determine the system's effects. These two reasons for understanding
the organizational context correspond to the two ways we discuss later for using the model
(proactively and reactively).

Of course, the organizational context is not the only influence on an information system’s design
features and effects. The manner in which the system is built and introduced into the organization
also matters. Consequences will depend, for example, on whether the organization develops custom
software to meet its needs exactly or whether it makes do with an off-the-shelf package. This section,
however, is primarily concerned with the organizational context; other factors are addressed
subsequently.

What follows are brief descriptions of the dimensions of the organizational context and some
examples of the kinds of interactions the model helps illustrate. For the purposes of understanding
the dynamics of information systems interventions, we find it useful to distinguish between the
organization’s external environment and internal elements. Moreover, we find it pedagogically useful
to group the internal elements into four components: the firm's strategy, its structure and culture, its
business processes, and its IT infrastructure.

The External Environment

A firm's external environment is defined by such factors as the competitive structure of its industry,
the relative power of buyers and sellers, the basis of competition, whether the industry is growing,
shrinking, or stable, the state of regulation, and the state of technological deployment. Of particular
interest is how the firm is situated in its external environment for example, the competitive position of
the firm, its relationships with its customers and suppliers, and its relative technological capabilities.
The external environment and the firm's position in it influences which information systems a firm
chooses to implement, the design features of those systems, and their effects for the firm and the
industry.

While the external environment often influences internal information systems for example, regulatory
changes frequently impact a firm's transaction processing and reporting systems considering the

6|Page
external environmental is especially important for understanding those systems that link one
organization with another (interorganizational systems). Electronic Data Interchange (EDI) provides a
good example of how industrial factors influence technological adoption: Some firms embarked on
EDI only following pressure from their trading. Other firms responded not to direct pressure from their
partners but to the indirect pressure of their competitors' successful deployment of EDI technology. In
a number of notable cases, industry associations have facilitated the industry-wide deployment of
EDI. Furthermore, these same forces (trading partners, competitors, and industry practices) may
influence system design decisions, such as whether to use proprietary protocols and whether to
employ a value-added network, and the consequences of those design decisions.

Regarding system effects, interorganizational systems (IOS) can improve a firm's performance in a
number of ways, including reducing transactions costs and differentiating a firm from its competitors.
But the consequences for one firm may be different from those for another (buyers versus sellers,
industry leaders versus small players, and so forth). Consider, for example, the differing effects of the
Sabre airline reservation system for American, which receives substantial revenue from Sabre and
the now-defunct Frontier. Moreover, such systems may affect not only the performance of an
individual firm but may change the external environment itself by altering the basis of competition in
the industry or shifting the balance of power between buyers and sellers. The ASAP system at
American Hospital Supply Company is a classic case of such environmental effects.

Firm Strategy
Many information systems projects in organizations today are closely linked to corporate strategy. In
some cases, the information system is a key element in executing a marketing or manufacturing
strategy; in other cases, it is at the very essence of the strategy. For analyzing many information
systems, therefore, examining firm strategy is a critical factor. Among the business strategies that are
now receiving much attention for their IT implications are differentiation, low-cost production, a focus
on quality and service, globalization, right-sizing, customer intimacy, supplier intimacy, and just-in-
time inventory and manufacturing.

In addition to the typical treatment of the information system-firm strategy relationship, which employs
a variety of examples together with the five-forces model or value chain analysis to explain how firm
strategy can drive the effective use of IT, we also consider what can go awry in this arena. For
example, had Bank of America's Masternet project succeeded, it might now be another example of
the strategic use of IT, leapfrogging B of A into the 1990s and catapulting it into trust-fund leadership.
But a combination of factors including a bad implementation process, inability to leverage the existing
IT infrastructure, and questionable objectives led instead to disaster. In particular, it was not clear that
the information system's objectives were a good fit with the organization’s strategic needs. Similarly,
many firms are finding that the benefits of reengineering projects do not "always drop to the bottom
line" unless the projects are carefully chosen on the basis of strategic fit.

Organizational Structure and Culture

A firm's internal design elements, its structure and its culture may influence information systems
design as well as information systems success. Conversely, an organization's information systems
may contribute to changes in its structure and culture.

By organizational structure we mean formal aspects of organizational functioning, such as the division
of labor, hierarchical authority, and job descriptions. Structure typically includes whether the firm is
centralized or decentralized, whether it uses a divisional, functional, matrix, or networked
organization, its reporting relationships, and its reward structure.
Organizational structure can influence information systems consequences in a number of ways. For
example, while advances in IT are breaking down the technological barriers to the sharing of
information in organizations, organizational structure often remains a formidable barrier to the timely
sharing of accurate information because organizational units fear the negative political consequences
that may accompany sharing their data with others. Instead of realizing the intended benefits,
organizations may find that these fears lead to non-use or misuse of the information system.

7|Page
Similarly, systems that share data across departmental boundaries are especially vulnerable to
resistance from users due to lost flexibility.

As a consequence of the deployment of information technology, there are often dramatic changes in
organizational structure. For example, improved data management can lead to greater centralization
of decision making in an organization, even when it is not a design objective. Or, alternatively,
information technology can push decision making down in the organization. Frito-Lay, for instance,
used its information systems to promote a "hybrid" organizational structure reflecting "directed
decentralization"-greater decision-making power at lower organizational levels coupled with greater
opportunities for control and direction at higher levels. Moreover, given the information sharing and
communication capabilities of IT, traditional organizational hierarchies are giving way to adhocracies
and networked organizations.

By culture we mean the pattern of shared basic assumptions that an organization learns as it
becomes integrated into a whole and adapts to its environment. The essence of these assumptions
becomes embedded into the organization and is passed along to new members. Elements of culture
include whether the organization values individuality or teamwork, whether bigger is better, and
whether risk taking, such as that commonly associated with IT innovations, is rewarded, or
reproached. Like organizational structure, culture can influence the consequences of an information
system. For example, in an organization that values individuality over teamwork, groupware systems
especially those that operate with anonymity may fail to achieve their desired consequences of
promoting productive collaborative work. On the other hand, when coupled with other measures, such
a groupware system might be used as part of a conscious effort to make the corporate culture more
team oriented.

Business Processes
Business processes are the sets of activities, often cutting across the major functional boundaries
within organizations (for instance, sales, manufacturing, and engineering, among others), by which
organizations accomplish their missions. Examples of business processes include order fulfilment,
materials acquisition, and new product development.

Ever since computers were first used in commercial situations, organizations have tried to improve
the operation of their business processes through the application of information technology in ways
that have come to be described as "automation." While automation has achieved many stunning
successes, experts in management and information technology have begun to recognize its
considerable limitations. In brief, when business processes are automated without first streamlining
and improving them (for instance by eliminating redundant activities), organizations generally fail to
achieve significant benefits from their large investments in information technology. Also, when
automation efforts are confined to small pieces of a business process (such as those pieces that fall
within the boundaries of a particular functional unit of the organization), it can happen that the larger
process is suboptimized, and performance is degraded rather than improved.

Growing recognition of the limitations of the traditional “automation" paradigm, has led experts to urge
managers to conduct their systems acquisition and systems development activities in the context of
larger organizational "reengineering" efforts. By carefully scoping out the boundaries of the whole
business process and identifying its critical performance measures and the major points of leverage
on them before selecting or developing an information system, managers can avoid the twin
automation pitfalls of automating a bad process and automating the wrong process. For example, the
designers of Singapore's Tradenet began by considering which business processes were key to the
success of the economy and which were not. By every measure, trade was the most important
economic sector. Within trade, the business processes judged to have the greatest impact on
economic competitiveness were those that directly influenced the speed of transit; among these,
customs clearance was the most visible and had the biggest impact. Tradenet's designers were not
content with the incremental improvements they would achieve by automating all the customs

8|Page
clearance activities that were then performed. Instead, they radically simplified the process,
transforming it, and in doing so significantly improving the time required to clear most shipments.

IT Infrastructure
IT infrastructure is a term that appears frequently in the IS literature, but whose meaning varies from
source to source. The term "infrastructure” in general refers to aspects of our physical and social
environments that are shared for the public good: highways enable the movement of goods and
people, languages enable the sharing of ideas and information, and monetary systems enable our
global economy. In our model, the IT infrastructure encompasses the physical components, the data
and document repositories, the technical capabilities of IS professionals and users, and the
technology strategies that enable current business processes and equip the firm to create new IT
applications. Here, we emphasize that the IT infrastructure represents the organizational resources
that give the firm the capacity to generate new IT applications. As such, it is both enabling and
constraining.

The physical part of the IT infrastructure, sometimes called "the platform", includes computer and
communications network components, operating systems, and utilities. Databases, including the
relatively static databases describing the firm's accounting system, products, customers, and
employees, as well as such less-structured document repositories as Lotus Notes "databases" and
engineering drawing files, are another potentially leverageable component of the IT infrastructure.
Application programs, especially common or shared applications, or reusable program modules and
objects may also enable the development of new information systems.

The capabilities of technical and non-technical people in the organization to develop and manage
information technology are an often overlooked but equally important part of the IT infrastructure. We
include as part of the IT infrastructure the firm's knowledge of the languages and protocols of the
platform, as well as expertise in developing and using information systems. The IT infrastructure also
includes procedures, such as those inherent in systems development methods, CASE tools, and data
dictionaries, because these ease or speed information systems development. Finally, we also
consider the firm’s strategies, plans, architectures, and standards-all of which direct development
toward firm goals-to be critical components of a shared, enabling IT infrastructure. Some argue that
the systematic development of core information technology components and competencies will lead
to sustainable advantages in productivity, flexibility, or speed. Similar arguments favouring
capabilities over strategic thrusts can be found in the recent strategy literature. Using our model, we
argue that the management of the IT infrastructure-that is, the thoughtful accumulation of long-term IT
capability-is a task best shared by information technology professionals and the rest of the firm's
management.

In our model, any application of information technology can leverage or extend the existing IT
infrastructure. A given information system leverages the infrastructure when it draws upon the
resources the existing infrastructure offers. An information system extends the infrastructure by
contributing physical or non-physical resources that can be drawn upon by other applications. The
implementation of the Tradenet system in Singapore illustrates this leveraging and extending of the IT
infrastructure. The Tradenet system leveraged existing governmental transaction processing systems
by linking traders to these systems. In addition, the process of implementing Tradenet was managed
so that a considerable increase was made in Singapore's stock of information systems related skills,
both in the private and public sectors. Moreover, these information system skills, the Tradenet
concept, and its EDI architecture were subsequently leveraged as Singapore quickly implemented
similar systems for its medical, legal, manufacturing, apparel, and real estate industries.

Features of the information system

Most of you may think of an information system as a computer, some programs, and perhaps some
data. The traditional IS view that an information system consists of hardware, software, data, people,
and procedures is a major improvement over naive view because it highlights that many people and
procedures are required "behind the terminal" if systems are to run reliably without considerable pain

9|Page
and suffering on the user's part. The traditional view is misleading, however, because it puts the
primary emphasis on the information system when it should be on the organization whose
performance the information system is intended to improve. As shown in Figure 3, we encircle the
information system within the organizational rectangle to emphasize the relationship between the
information system and the organization. You may think of the circle as a lens, a magnifying glass,
that focuses our attention on a particular subset of the firm's computer technology, people, and
procedures.

No matter how much this traditional definition of an information system improves one’s initial views, it
does not go far enough to support insightful proactive or reactive analyses of the factors that
contribute to information system success. To design effective information systems, and to understand
and predict their effects after the fact, one must consider not just the system's constituent elements
but also the design features of the system as a whole.

We define system design features as those properties of an information system that affect system
use and the consequences thereof. These properties reflect, usually somewhat imperfectly, the
designers' attempts to translate their intentions for changed functioning into system attributes. A
system’s features and the designers' intentions differ because a given user's perceptions of what he
or she can do with a system often differs from the capabilities designers are trying to build in. Indeed,
an entire body of literature in the computer-human interaction field is devoted to users' mental models
of software and to the affordances of technology.

We discuss features in two ways. First, we contemplate features in terms of general, broadly
applicable concepts such as system functionality (what the system does), the interface (how users
interact with it), restrictiveness and guidance, automating versus informating, and anonymity versus
identity. Some executive support systems, for example, restrict users to predefined displays, whereas
others support personal analysis as well. Similarly, one expert system might produce decisions for
the user, whereas another might be designed as an expert support system that assists the user in
arriving at a decision. Moreover, the consequences of a given feature may be mixed: the more
restrictive system may produce better performance in the short run but deskill the organization's
people in the long run.

We also discuss features in terms of the highly specific decisions made by system designers in
particular cases. For instance, in the case of the CONFIG expert system, designers deliberately
decided, over the objections of users they involved in design, not to integrate the expert system with
another information system the users had to employ. This decision had a major adverse effect on
how much the system was used, and consequently the system did not achieve the intended business
results.

While topologies of general features can go a long way toward helping you design effective systems
and analyze their impacts, much skill is involved in identifying the key specific design features that will
make a difference in any given case. It is useful to provide numerous examples that reinforce the
growing intuitions about those features of systems that must "fit" with the other elements of the
organization and those that can and should be allowed to clash.

Fit between information systems features and the organizational context

Central to understanding the interaction of the information system with its organizational context is the
concept of "fit." The notion that a system must "fit" its context the organization, its strategy, its
business processes, its environment is intuitively appealing. Things that fit are good; misfits are bad.
Systems that do not fit political dynamics, managerial assumptions, users' cognitive technology
frames, or users' incentives are likely to be resisted, underused, misused, actively sabotaged, and so
forth. This suggests that organizations wishing to introduce new systems should conduct a careful
diagnosis of users and their needs prior to systems development to produce a system that fits well
enough to promote positive effects and system success.

10 | P a g e
But what if the organization wants to use information technology to change users’ behavior,
organizational culture, or business performance? In this case, a strong fit between the system and the
existing organization is likely to be counterproductive; the new system may be used, but the
organization is not likely to change very much, and the desired consequences are not likely to occur.
In this situation, the organization must confront the need to change other aspects of the organization
(structure, culture, and so forth), either prior to or simultaneously with the introduction of the system.
This strategy where the information system clashes with the pre-existing organization but fits with the
transformed one-both creates the fit needed to ensure that the information system is used and
changes the broader organizational system into a new configuration, enabling the improvements in
performance.

Indeed, the business process reengineering approach was developed precisely to address this
tension between the need for fit and the need for change. Hammer has argued that systems
developers have for years sought fit at the expense of change by "automating" flawed business
processes, rather than reengineering them. In so doing, they have merely "paved over the cowpaths,"
producing at best incremental improvements. Reengineering aims to accomplish radical
improvements by complete redesign of business processes supported and enabled by the use of
information technology.

This analysis suggests that, when developing new information systems, organizations adopt one of
two strategies. They may engage in incremental improvement or in a more radical transformation
(reengineering). In either case, examining the fit between the organization and the information system
sheds light on the effects. In instances of incremental change, for example, a good fit may explain
desirable effects, and a poor fit may explain negative ones. In instances of transformation, the
situation is more complex because the new system can fail at its mission either by fitting the existing
organization too well so that not enough change occurs, or too poorly, fostering resistance if
corresponding changes are not made in other organizational design elements. In particular,
reengineering's high failure rate can often be traced to the "misfit" it produces in the organization. The
key to successful reengineering is to balance the desire to "obliterate" dysfunctional business
processes with the need to re-establish a harmonious organizational fit between systems, processes,
and such other aspects of organization as structure and culture. Achieving this balance is the goal of
effective "information systems implementation."

The implementation process

Thus far in our discussion of the model, we have only considered two causal relationships-the effects
of the organizational context on information systems design features and on information systems
effects. Another major influence, however, on information systems design features and on information
systems impacts is the implementation process.

The term implementation has multiple meanings in the context of IS and in English language usage
more generally, according to our dictionary. Systems developers often use the word most narrowly as
a synonym for "coding" or "realizing the system designer's intention". This is consonant with the
dictionary’s third definition: "3. to provide with implements." Among behaviorally oriented researchers,
the term is often used in a somewhat broader sense to refer to the user-oriented activities that
generally occur after coding. These activities include training, support, communication, and
establishing policies regarding use. This perspective reflects implementation’s second meaning: "2. to
provide with the means for carrying into effect or fulfilling; give practical effect to."

It is our experience that "clients"-the managers who fund systems development efforts-implicitly use
the broadest, most inclusive definitions of the term "implementation," which our dictionary holds as "1.
to carry into effect; fulfill; accomplish." Managers, we find, are not simply concerned that a system has
been built successfully, or even that the intended users are using it. They are also critically concerned
that use of a built system delivers on its promise of improved organizational performance.

11 | P a g e
In our view, the different uses of the term implementation are not just wordplay or a semantic
curiosity; they reflect real cultural and communication gaps among systems developers, researchers,
and managers. Those who have a thorough understanding of the miscommunication possibilities
inherent in this one term are much better able to understand the importance of undertaking an active,
even proactive, personal role in systems development efforts in the future.
This model employs the broadest, most inclusive view (definition 1). Moreover, the model's treatment
of the implementation process neither adopts nor depends upon any particular view of the systems
development process. It is intended to be compatible with the various versions of the traditional
Systems Development Lifecycle (SDLC) as well as with such alternative lifecycles as those
associated with prototyping or outsourcing. Consequently, we identify four generic stages in the
implementation process: (1) initiation, (2) acquisition (build/buy), (3) introduction, and (4) adaptation.
In Figure 3, time proceeds from left to right, but the process is deliberately left "open-ended" to reflect
that adaptation of both the organization and the information system is ongoing.

The downward arrows in the figure indicate that the implementation process influences the
organization in particular, the design of the information system and mediates the effects of the
organization-system interaction. For example, in cases where the new system is in conflict with the
existing organization, the way the implementation process is handled may facilitate organizational
change and system acceptance or, alternatively, may provoke greater resistance.

OTISLINE: a reactive illustration

The OTISLINE case is a popular business case that illustrates how Otis used information technology
to enhance its competitive position in the elevator industry. The case is rich with respect to many
aspects of the IT Interaction Model.

In brief, the case describes how Otis centralized its dispatching and monitoring of service calls,
thereby improving the quality of service and achieving a variety of related competitive benefits. Our
objective in the discussion is to recognize what transpired and to analyze why. The way we open the
discussion is usually to ask if OTISLINE was successful.

You may conclude that the system was a success by noting that Otis strengthened its number-one
share of the service market (performance). And they point to a number of second order competitive
benefits that also followed from the system, such as the edges in manufacturing and selling elevators
that OTISLINE produced indirectly. Further analysis also reveals that OTISLINE served as the
springboard for additional technological innovations that Otis planned down the road. You may
explore on this issue of future flexibility versus current performance, asking questions such as the
following: How dependent is Otis on OTISLINE? How can Otis insulate itself from the risks of
dependence? Is Otis blinding itself to other, better approaches that might be invented in the future?

Next, we ask what made OTISLINE a success. It is usually agreed that OTISLINE met the firm's
strategic business need and was responsive to the competitive problems Otis faced in the elevator
service industry. But we probe further. While the system may have been a good strategic fit,
consonant with the demands of the external environment, OTISLINE represented a transformation
within the organization. Otis moved from a highly decentralized handling of elevator service,
controlled by the field office managers, to a highly centralized approach. Many of the immediate and
future benefits of OTISLINE follow from this radical change, which was not just a redesign of the
business process of dispatching, but a transformation of managerial control within the firm.

We probe still further. The case notes that Otis was only able to implement OTISLINE so rapidly
because a critical database was already in place. So OTISLINE's success was attributable in part, to
having necessary infrastructure already in position that could be leveraged to support the new
system. Try to understand the implementation process; note a number of implementation factors that
further contributed to OTISLINE's success.

12 | P a g e
At this point, the discussion may seem complete to many of you, but we have not yet considered the
effects on people. These effects varied by position. Centralized dispatching meant replacing local
dispatchers with new ones at the central site. For mechanics, the improved dispatching made their
lives better in some ways, but it also subjected their performance to greater monitoring. And field
office managers found themselves bypassed because service data flowed directly to corporate
headquarters, which began to intercede in local service operations. So, the consequences for people
in the organization were very mixed. In this sense, OTISLINE is similar to many systems, we believe,
which is why we find it so effective to use this case in conjunction with our model.

We use the IT Interaction Model to present our conclusions. Among the conclusions we reach is that
OTISLINE was a good fit with strategic need, but that it was not the technology or the fit alone that
produced the successful outcomes. Having an appropriate infrastructure and employing a good
implementation process also contributed. And the key ingredient was transforming the organization
through centralization. While this transformation had a positive effect on performance, it had a variety
of negative effects on many people's jobs. This conclusion can support a discussion of alternative
systems design features or alternative implementation strategies that might have produced different
results.

Reactive Analysis of an Information System

13 | P a g e