The Information Technology (IT) Interaction Model is a stylized view of the dynamics of information systems in organizations. The model asserts that the effects of an information system for an organization emerge over time as the result of the interaction of the system with the organization. This view leads to a model with four interrelated elements:
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 nonuse is a major reason for systems' not achieving their design objectives. And, 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, 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:
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 worklife 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 one person's job may deskill or eliminate another's.
A third-order effect of implementing an information system is that as a result of how the system is used and of its perceived consequences for performance, people, and future flexibility, adaptations will be made over time to the system, the organization, or both. At FritoLay, for example, changes due to the handheld computer project and the improved IT infrastructure enabled the organization to shift from a oneyear planning cycle to a threetimes-a-year planning cycle, dramatically improving the rate of organizational learning. Similarly, it has been suggested that, as with any new technology, a period of learning, adjustment, and restructuring may be necessary before the full return on an IT investment is reaped. The figure depicts these adaptive effects in the form of a feedback loop at the bottom of the diagram.
Organizational structure refers to 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 system 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 as 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 nonuse or misuse of the information system. Similarly, systems that share data across departmental boundaries are especially vulnerable to resistance from users due to lost flexibility.
Culture refers to the shared values, basic assumptions, and behaviors of organizational 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.
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 system acquisition and system 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.
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, may also enable the development of new information systems.
The capabilities of technical and nontechnical 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.
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 system 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, as 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 reestablish 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 system implementation."
This view of the implementation process is compatible with the traditional Systems Development Lifecycle (SDLC) as well as with such alternative lifecycles as those associated with prototyping or outsourcing. Consequently, the implementation process is divided into four generic stages: (1) initiation, (2) acquisition (build/buy), (3) introduction, and (4) adaptation. In Figure 1, 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 organizationsystem 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.
The interaction model can also be used reactively to analyze the outcome of an information systems project. Such analysis might be useful either for academic purposes or as part of the adaptive process of revising the system. When using the model reactively, a good starting point is to ask whether the design objective was to improve or transform. If the objective was improvement, then the results might best be understood by looking for places where there may be a lack of fit between the system and the organization. If the objective was transformation, the results might depend on understanding where there were fits and where there were clashes. Table 2 presents a checklist of questions to consider when performing such an analysis. Note that not every question-every possible interaction-will be important for every situation. The challenge is to determine which are the salient issues for a given project.
The External Environment:
|
Business Processes:
|
Firm Strategies:
|
IT Infrastructure:
|
Organizational Structure:
|
Information System Features:
|
Organizational Culture:
|
The Implementation Process:
|