Figure 1
Taking 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. This claim is based on a large body of generally-accepted theory, including web models (Kling and Scacchi, 1982), the interaction perspective (Markus, 1984; Markus and Robey, 1988), and structuration theory (Orlikowski and Robey, 1991; DeSanctis and Poole, 1994). In addition, the model helps account for and make sense of a large body of conflicting empirical findings about IT impacts (Attewell and Rule, 1984; Gurbaxani and Whang, 1991; Markus, 1994). We will provide in subsequent sections more details on the relevant theoretical and empirical literatures, but first we describe how we motivate the model for our students.
When introducing the model to our students, we use a casual discussion as motivation before presenting the model formally. We begin by asking students why organizations build information systems. They usually respond by identifying a variety of economic benefits: "to make money," "for greater efficiency," and so on. After probing a bit, we ask: "Do systems always have these effects?" Here, we often get into a stimulating discussion of failures and "nonimpacts"-everything from the recent CONFIRM debacle to the Productivity Paradox (Brynjolfsson, 1993). Next, we ask about the potential for negative impacts. Job loss, deskilling, loss of security, and computermonitoring usually surface, among others.
This discussion of effects sets the stage for us to ask the questions that introduce our model:
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 (Cash, McFarlan, McKenney, and Applegate, 1992). 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, students might volunteer 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 students by this time 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:
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.
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 Silver's (1991) restrictiveness and guidance attributes. We might use Zuboff's (1988) 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. This introductory discussion serves to preview the topics we will be addressing during the term and to demonstrate to the students that these subjects are highly interconnected. Subsequently, we present the model more formally and discuss each element more fully. In the following section, we flesh out each component of the model in somewhat greater detail, providing pointers to relevant theoretical, empirical, and practical literature that may be useful to the instructor.
We present the model to the students in diagrammatic form as shown in Figure 3. The schematic, which captures the main elements of the model and depicts the principal relationships, serves several purposes. It highlights the key components and helps the students see the relationships among them. It also helps the students remember those components and relationships. The figure allows us to focus easily on one portion of the model, without losing sight of how that component fits into the big picture. And it helps the students appreciate the model's dynamics. Table 1 accompanies the schematic, outlining and exemplifying the model's salient features. The table is intended not to define the components but to illustrate them, providing links to topics students have studied or will study in their other business courses. What follows is an overview of the essentials of the model:
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. We find that knowledge of the potential interactions between systems and various elements of the organization is just the tool they need to do this.
System effects can be seen as fitting into a series of 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 designers' objectives (Markus and Keil, 1994). 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 (Keen and Scott Morton, 1978), 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: (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 that the system may enable or constrain future information systems and strategic initiatives by the organization (Keen, 1991). 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 (Fichman and Kemerer, 1993).
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 or empowers one person's job may deskill or disempower someone else's (Attewell and Rule, 1984; "The Expense Tracking System at Tiger Creek," 1984). 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, other elements of 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 ("FritoLay, Inc.: A Strategic Transition (1987-1993)," 1995). 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 (Brynjolfsson, 1993). 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:The 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 ("Singapore Tradenet (A)," 1989; Neo, Khoo, and Ang, 1993). 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 will 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 offtheshelf package. In this section, however, we are 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 (Laudon, 1985). 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.
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 (Porter, 1980; McFarlan, 1984). 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, influence which information systems a firm chooses to implement, the design features of those systems, and their effects for the firm and the industry (Orlikowski and Robey, 1992).
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 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 partners (Bouchard and Markus, 1995). Other firms responded not to direct pressure from their partners but to the indirect pressure of their competitors' successful deployment of EDI technology (Clemons and Kimbrough, 1986; Clemons and Row, 1987). In a number of notable cases (for example, "IVANS," 1987; Palmer, 1994), industry associations have facilitated the industrywide 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 ValueAdded Network ("RASCO: The EDI Initiative," 1990; Choudhury, 1991), and the consequences of those design decisions.
Turning to 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 (Copeland and McKenney, 1988; Hopper, 1990), which receives substantial revenue from Sabre, and the now-defunct Frontier ("Frontier Airlines, Inc. (A)," 1983). 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 (Short and Venkatraman, 1992; "American Hospital Supply Corporation: The ASAP System (A)," 1988; "Baxter Healthcare Corporation: ASAP Express," 1991) is a classic case of such environmental effects.
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 (McFarlan, 1984; Ives and Learmonth, 1984; Porter and Millar, 1985; Boynton, Victor, and Pine, 1993; Treacy and Wiersema, 1993; Lucas, 1994; Palmer, 1994). 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 (Porter, 1980) or value chain analysis (Porter, 1985) to explain how firm strategy can drive the effective use of IT, or how IT can create strategic advantages for the firm, 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 1990's 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 (Hall, Rosenthal, and Wade, 1993).
A firm's internal design elements-its structure and its culture-may influence information system design as well as information system 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 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 (Keen, 1981; Markus and Pfeffer, 1983). 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 (Goodhue, Wybo, and Kirsch, 1992). As a consequence of the deployment of information technology, we are seeing dramatic changes in organizational structure. For example, improved data management can lead to greater centralization of decision making in an organization, even when this is not a design objective (Goodhue, Quillard, and Rockart, 1988). 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 (Powell, 1987; Drucker, 1988). Among the resources we may draw upon for discussing this subject are Huber (1990) and Gurbaxani and Whang (1991).
By culture we mean (following Schein, 1992) 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 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 fulfillment, materials acquisition, and new product development (Davenport, 1993; Hammer and Champy, 1993). 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 (Markus and Soh, 1993). 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 (Markus and Keil, 1994). 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 (Davenport, 1993; Hammer and Champy, 1993). 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 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 clearance activities that were then performed. Instead they radically simplified the process, transforming it, and in so doing they significantly improved the time required to clear most shipments.
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 that equip the firm to create new IT applications. For this course 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" (Keen, 1991), 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 nontechnical people in the organization to develop and manage information technology are an often overlooked but equally important part of the IT infrastructure (Davenport and Linder, 1993). 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 (Henderson and Venkatraman, 1993).
Some argue that the systematic development of core information technology components and competencies will lead to sustainable advantages in productivity, flexibility, or speed (Markus and Soh, 1993; Weill, Broadbent, and St. Clair, 1994; Clemons, 1991). Similar arguments favoring capabilities over strategic thrusts can be found in the recent strategy literature (Dierickx and Cool, 1989; Hamel and Prahalad, 1990; Barney, 1991; Stalk, Evans, and Shulman, 1992). 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 (Rockart, 1988; Henderson, 1990). 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 ("Singapore Tradenet (B)," 1993).
Most students entering the course 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 on the students' naive view, because it highlights that many people and procedures are required "behind the terminal" (Kling and Scacchi, 1982) if systems are to run reliably without considerable pain and suffering on the user's part (Gasser, 1986). 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. We tell students they can 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 on students' 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.
In the spirit of Markus (1984), 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 computerhuman interaction field is devoted to users' mental models of software (Borgman, 19xx) and to the affordances of technology (Norman, 1988). 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 (Silver, 1991), automating versus informating (Zuboff, 1988), and anonymity versus identity (DeSanctis and Gallupe, 1985; Nunamaker, Applegate, and Konsynski, 1987; Jessup, Connolly, and Galegher, 1990; Valacich, Dennis, and Nunamaker, 1991). Some executive support systems, for example, restrict users to predefined displays (Houdeshel and Watson, 1987), whereas others support personal analysis as well (Rockart and Treacy, 1982). Similarly, one expert system might produce decisions for the user, whereas another might be designed as an expert support system (Luconi, Scott Morton, and Malone, 1986) 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 (Markus and Keil, 1994), 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 students 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. We therefore find it useful, through pedagogical case studies and student projects, to provide numerous examples that reinforce the students' 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.
But what if the organization wants to use information technology to change users' behavior, organizational culture, or business performance? Here, 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 (Hammer and Champy, 1993; Davenport, 1993) was developed precisely to address this tension between the need for fit and the need for change. Hammer (1990) 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 (Bashein, Markus, and Riley, 1994). The key to successful reengineering is to balance the desire to "obliterate" (Hammer, 1990) 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."
Thus far in our discussion of the model, we have only considered two causal relationships-the effects of the organizational context on information system design features and on information system effects. We should not forget, however, that another major influence on information system design features and on information system 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 (Webster's New World Dictionary, College Edition, 1968). System developers often use the word most narrowly as a synonym for "coding" or "realizing the system designer's intention" (Swanson, 1988). 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 useroriented activities that generally occur after coding. These activities include training, support, communication, and establishing policies regarding use (Bikson and Eveland, 1990, 1991; Tornatzky and Fleisher, 1990). 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 system 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.
We believe that the different uses of the term implementation are not just wordplay or a semantic curiosity. We believe that they reflect real cultural and communication gaps (Keen, 1995; Wang, 1994) among system developers, researchers, and managers. We find that students who have a thorough understanding of the miscommunication possibilities inherent in this one term are much better able to understand the importance of their undertaking an active, even proactive, personal role in systems development efforts in the future. Among the resources we draw on in our discussion of implementation are LeonardBarton (1988, 1990), Markus and Keil (1994), Markus and Robey (1995), McKersie and Walton (1991), and Walton (1989). While we believe that discussing the various perspectives on implementation in class is important, our 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 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 system 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.
These two real-world uses of the model correspond with two uses in the classroom. The reactive approach-ex post analysis of a systems project-lends itself to retrospective analysis of business cases. Students are encouraged to recognize whether the objective was improvement or transformation, to consider whether this objective had merit, to contemplate the full set of consequences (not just the obvious ones of profit or market share), to identify the salient elements of the model that contributed to these outcomes, and to make recommendations concerning what could have been done differently. This approach can also be used for comparative case analyses, to help students examine how different mixes of organizational factors and system features contributed to different outcomes. The model can be used either for written case analyses or as the basis for class discussions. The proactive approach also has multiple uses in the core MBA course. Many such courses include small systems analysis and design projects, and others include term-long development projects. In some instances these are "textbook cases," where students design systems based on predefined scenarios, while in others they are "living cases," which allow the students to study the environment and interview the people directly. Either way, the interaction model can be used proactively to guide systems analysis and design. The proactive approach may also be appropriate for "action" business cases where students are presented with a business situation and asked what the organization should do next.
To make the IT Interaction Model and its uses more concrete, we describe two examples of how we use the model in the core course. The first example illustrates the role of proactive analysis in student projects, and the second shows reactive analysis using the OTISLINE business case.
Examining the differences across teams highlights how the students used the model. Some groups took a very technical approach to the task, devoting a good deal of their effort to designing and building prototypes. While their demos were generally slick, other teams that took a broader and more behavioral approach generally made greater use of the model and produced richer analyses. The teams varied in their assessments of whether it was best to automate or obliterate. Some teams made low-tech recommendations, arguing that little new technology was needed but that changes to the unit's processes and procedures were essential. Others argued for incremental improvement, automating existing approaches. Still others argued for more radical reengineering or transformation.
The teams identified an assortment of factors within the organizational environment that constrained the system design or had the potential to affect outcomes. For example, a number of teams expressed concerns about the ability of the existing IT infrastructure to support what they saw as the ideal solution to the problem. Concerns about hardware resources, software compatibility, data availability, and computer skills led some groups to recommend extending the infrastructure and other groups to scale back their proposed solutions. Similarly, internal structure and culture were often seen as additional constraints. Difficulties in sharing data across units, a low-tech atmosphere, and competition among units for central computer resources were all seen as factors requiring attention. Most groups pointed to areas where business processes could be improved, if not transformed. And although these were units of a nonprofit organization, the external environment also played a role. Units such as the placement center and admissions office were sensitive to the behavior of their counterparts at competitor institutions, and this influenced the project goals and parameters. In their analyses, students were also able to identify sources of potential resistance.
Based on the written reports, oral presentations, follow-up discussions with students, and feedback from clients, we believe that the model helped the students to appreciate the dynamics of information systems in the client organizations and to recognize the opportunities, dangers, and limitations that the client environment posed for the application of information technology. Of course, since the students' term-long participation reflected only the initiation stage of the implementation process, they were not able to experience first-hand the interactions and consequences that would ensue as the projects progressed. For this reason, we recommend coupling the proactive analysis of the project with reactive analyses of a number of business cases.
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. Students generally 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. We press the students 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. We also encourage the students to consider the implementation process; they generally note a number of implementation factors that further contributed to OTISLINE's success. At this point, the discussion may seem complete to many students, 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 as 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, 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 system design features or alternative implementation strategies that might have produced different results.
Like many IS core courses, we design the course around the following main topics:
The basics of technology come into play in at least three ways in the model. Technology concepts matter for assessing the IT infrastructure, for describing system features, and for examining the relationship between the capabilities of the existing infrastructure and the demands of the proposed system. Indeed, the model helps those students who might otherwise be resistant to the technological component of the course appreciate why they need to learn this material. For example, OTISLINE provides an excellent illustration of the importance of voice technology (automatic call distribution) complementing computing technology (databases).
The systems development portion of the course is reflected by the implementation process time-line that runs across the top of the model. The model portrays an abstracted process comprising four generic phases, but systems development and implementation receive proper and complete attention during the course. In particular, our treatment of these topics pays special attention to the systems analysis and design phases and to implementation tactics and strategies. We point out the importance of process, noting that the implementation process, too, affects system use, consequences, adaptation, and success. The implementation process structures the model visually just as, in the real world, it is the process that carries us from the existing organization to the new information system to the effects of their interaction. Our objective in the IT applications section of the course is twofold. One goal is to acquaint students with the range of application types they are likely to encounter in the workplace. The other aim is to familiarize them with the dynamics of these various applications in organizations. We rely on the model heavily to realize this second aim. In the paragraphs that follow we use expert systems, group decision support systems, executive information systems, and interorganizational systems to illustrate briefly this use of the model. In addition to explaining the routine characteristics of expert systems (Leonard-Barton and Sviokla, 1988)--what rule-based expert systems are, how they work, what tasks they are suited for, and what benefits they offer the organization-we use the interaction model to provide a more penetrating analysis. What are the consequences of an expert system for people in the organization? Is such a system inherently job enriching or deskilling? Are the consequences the same for experts as for novices? How can the potential deskilling effects of expert systems be prevented or mitigated? How might this system constrain the organization's future flexibility? For instance, might the system lead to deskilling, which in the long run could lead to a loss of knowledge and expertise for the firm? Similarly, we use the model to probe the features of group decision support systems (GDSS). One GDSS feature that has received much attention is the possibility of sharing ideas anonymously (DeSanctis and Gallupe, 1985; Nunamaker, Applegate, and Konsynski, 1987; Jessup, Connolly, and Galegher, 1990; Valacich, Dennis, and Nunamaker, 1991). Such anonymous communication offers potential advantages as well as potential disadvantages. For example, while anonymity might promote greater participation and more effective brainstorming by reducing inhibitions, it might also suppress participation since individuals are not rewarded for their contributions. Whether anonymity produces good or bad results, therefore, may depend upon whether the organizational culture encourages or stifles open communication and upon whether the organizational reward structure favors individual or group performance. An organization might set anonymity on or off in consonance with its existing structure and culture, or it might do the opposite, using the system, together with a careful implementation process, to transform the structure and culture. Executive Information Systems (EIS) are rapidly turning into "Everybody Information Systems," proliferating throughout the firm as a means of sharing valuable corporate data ("Trickle-Down Systems," 1990). In some firms, efforts toward corporate-wide information systems may be stymied by inadequate technological infrastructures. In others, the infrastructures may now be robust enough to support such data sharing, but structural and cultural barriers may still block it. A system intended to promote a more informed, data-rich business environment may instead evoke resistance accompanied by the withholding and falsifying of data. Here, again, success may depend upon a well managed transformation of the organization. Interorganizational systems (IOS) that electronically link one firm with another (Malone, Yates, and Benjamin, 1989; Cash and Konsynski, 1985) are also growing rapidly in popularity. Whether a given firm will benefit from hooking up with its suppliers and customers electronically, however, and what the most appropriate type of connection will be (for example, an electronic market versus an electronic hierarchy, a proprietary versus a standard EDI protocol, and so forth) depend upon such elements of the external environment as the concentration of sellers in the industry, the relative power of buyers and sellers, and the basis of competition. The Reynolds Aluminum Supply Company case ("RASCO: The EDI Initiative," 1990) illustrates a number of these issues nicely. In addition to these main topics-technology, development, and applications-two themes that run throughout the course are (1) the strategic use of information technology and (2) business process reengineering. As we have seen, the model captures these themes as well. Strategic use of technology is covered when we discuss the external environment and firm strategy. And reengineering is at the center of both the proactive and reactive uses of the model. Given the model as an integrative framework for the course, the students emerge with a better understanding of how the pieces fit together and why each is important for a sound understanding of information systems in business. And by presenting the students with a formal, causal model of information systems in organizations-albeit in the form of a schematic and not a set of equations or propositions-we convey the message that the course and the subject are not a collection of loosely related topics but an integrated whole resting on a well-defined theoretical foundation. It is reassuring to the students to be able to point to the model as the core of the course. If the students grasp the model, they can feel comfortable with their understanding of the theory that underlies IS. And our use of the model also makes the students aware of what we expect them to learn from the class. The way we employ the model in the course fosters a number of important business proficiencies that should serve the students well in the workplace. As "the line takes the leadership" (Rockart, 1988; Boynton, Jacob, and Zmud, 1992) and the partnership between IT professionals and line managers grows, MBAs are likely to have responsibility for managing some technology resources and to participate in information systems development projects in a number of significant ways: as project sponsors, as members of the design team, as managers of development, as end-user developers, and as project funders. At a minimum, managers should expect to be interviewed during systems analysis and design. Experience with proactive use of the IT interaction model will enable them to serve more competently in these capacities, increasing the likelihood of positive consequences and decreasing the chances of negative ones. Systems will always have unanticipated effects, but the more people understand about the dynamics of information systems, the better they will be able to minimize these unanticipated effects, to recognize them when they occur, and to cope with them. As citizens of wired organizations, MBAs should expect to encounter first-hand the consequences of their firms' IT undertakings. Experience with reactive use of the model will enable them to comprehend how a given system is affecting them and their organizations and to recommend any necessary corrective actions. This combination of proactive and reactive analytic ability should prepare the students well for the demands of the workplace.
First, we advocate introducing the model early in the core course. Some instructors may wish to present the model at the outset of the term to lay a foundation for what is to come. We find that it is often useful to defer introducing the model formally until the students have encountered some basic course material and have analyzed at least one business case. This approach serves to motivate the need for a model and to provide a context for appreciating the issues the model raises. OTISLINE (A) is a good choice for such a case. The case can be discussed in class prior to introducing the model, and it can then be used as an illustration while presenting the model. Second, the IT interaction model does not depend on a particular sequence of topics. Many core courses begin with technology basics, then discuss the development process, and conclude with specific types of applications. Others follow different orders, and still others integrate the topics (for example, by spreading basic technology concepts throughout the discussion of applications or by teaching development approaches in the context of particular classes of applications). Over the years, we have varied the order of presentation, and we have updated the concepts and supplementary readings, but we have made only a few changes to our graphical representation of the model. The model represents a higher level of course structure, compatible with a variety of topic sequences, that can pull together a given instructor's preferred course materials.
Third, although our model uses concepts found in other core MBA courses, such as strategy, structure, and culture, it is not our intention in the core IS course to teach such subjects. Depending on whether these courses are taken by the students previously, concurrently, or subsequently, the level of detail that we employ in presenting the components of the organizational environment varies. For example, in some instances we may make a formal distinction between structure and culture while in others we may not. For those MBA programs focusing on cross-functional integration of the curriculum, the model provides an excellent opportunity for collaborative teaching with the management and other core courses.
With respect to the course objectives, recall that our course goals are to acquaint students with the dynamics of information systems in organizations and, in particular, to increase students' knowledge of the potential benefits, dangers, and limitations of information technology, equipping them to leverage the benefits, avoid the dangers, and surmount the limitations. Based on the way students progress through the term, as evidenced in case discussions, written case analyses, and student projects, we believe that the model accomplishes these objectives. While students tend to enter the course as "technological determinists" (Markus and Robey, 1988), the model shows them that information technology is just one of many important contributors to information systems outcomes and that an assortment of factors interact to produce results. At the beginning of the term, students often focus on technological issues and positive outcomes. Midway through the course, the focus tends to shift in the other direction, such that they are inclined to see only the limitations and the organizational dangers. By the end of the term a balance is achieved.
One concern we have is that some students may be memorizing the model rather than learning to apply it effectively. Just as in other courses students may memorize equations and invoke them by rote, we have noticed that some students absorb the IT Interaction Model only superficially. These students include all the buzzwords in their written analyses and class participation, but they do not demonstrate an understanding of the concepts. For example, the better analyses and comments focus on the subset of model elements that are salient for the case at hand. The weaker ones, however, list all the components without conveying significant insight. We combat this tendency in a number of ways: through oral and written feedback, by providing a series of written assignments and case discussions so students can develop their analytic skills, and through group projects so the more perspicacious students can share their insights with their peers. We have found that the model is most successful when used for both business cases and student projects. We believe that the model is effective for analyzing most IS cases, but because there is a dearth of IS business cases, and because the existing ones were written independently of the model, finding a set of complementary cases that are rich with respect to the model is difficult. Writing IS cases while keeping the model in mind would therefore be helpful. For example, if the students were provided with rich and thorough description, they could be challenged to identify which model features are the salient factors in the case.
We have found the IT Interaction Model to be a valuable tool for teaching the MBA core course in Information Systems in a number of academic settings. Our hope is that as a teaching model that encompasses the full range of applicable topics, highlights the critical issues, and focuses on the essential relationships, while remaining independent of particular content choices, the interaction model will prove useful to others as well. We believe the model can also serve as a vehicle for advancing the ongoing dialogue concerning the design of the IS core course.
Applegate, L.M. "Lockheed-Georgia Company: Executive Information Systems," HBS Publishing, HBS Case No. 9-187-135, Boston, MA, revised, 1989.
Applegate, L.M. "FritoLay, Inc.: A Strategic Transition (1980-1986)," HBS Publishing, HBS Case No. 194-107, Boston, MA, 1994.
Applegate, L.M. "FritoLay, Inc.: A Strategic Transition (1987-1993)," HBS Publishing, HBS Case No. 195-238, Boston, MA, 1995.
Applegate, L.M. and Stoddard, D.B. "Chemical Bank: Technology Support for Cooperative Work," HBS Publishing, HBS Case No. N9-193-131, Boston, MA, March 1993.
Attewell, P. and Rule, J. "Computing and Organizations: What we Know and What we Don't Know," Communications of the ACM, (17:12), December 1984, pp. 1184-1192.
Balaguer, N.S. and Addonizio, M. "Chrysler Corporation: JIT & EDI (A)," HBS Publishing, HBS Case No. 9-191-146, Boston, MA, revised, 1992.
Barney, J. "Firm Resources and Sustained Competitive Advantage," Journal of Management, (17:1), 1991, pp. 99-120.
Bashein, B.J., Markus, M.L., and Riley, P. "Business Reengineering: Preconditions for BPR Success, And How to Prevent Failure," Information Systems Management, (11:2), Spring 1994, pp. 713.
Bikson, T.K. and Eveland, J.D. "The Interplay of Work Group Structures and Computer Support," in Intellectual Teamwork, R. Kraut, J. Galegher, and C. Egido (eds.), Lawrence Erlbaum Associates, Hillsdale, NJ, 1990, pp. 245-290.
Bikson, T.K. and Eveland, J.D. "Integrating New Tools into Information Work: Technology Transfer as a Framework for Understanding Success," in People and Technology in the Workplace, National Academy of Engineering and the Commission on Behavioral and Social Sciences and Education, National Academy Press, Washington, D.C., 1991, pp. 229-252.
Bouchard, L. and Markus, M.L. "Managing One's Business Partners: The Selling of EDI," to appear in Impression Management and Information Technology, J.W. Beard (ed.), Greenwood Publishing Group, Westport, CT, 1995.
Boynton, A. and Crowell, G.T., III. "RASCO: The EDI Initiative," UVA-IT-001, Darden Graduate School of Business Administration, University of Virginia, Charlottesville, VA, revised, 1990.
Boynton, A.C., Jacob, G.C., and R.W. Zmud, "Whose responsibility is IT Management?" Sloan Management Review, (33:4), Summer 1992, pp. 32-38.
Boynton, A.C., Victor, B., and Pine, B.J., II. "New Competitive Strategies: Challenges to Organizations and Information Technology," IBM Systems Journal, (32:1), 1993, pp. 40-64.
Brynjolfsson, E. "The Productivity Paradox of Information Technology," Communications of the ACM, (36:12), December 1993, pp. 66-77.
Buckley, W. Sociology and Modern Systems Theory, Prentice-Hall, New York, NY, 1966.
Cash, J.I., Jr., and Konsynski, B.R. "IS Redraws Competitive Boundaries," Harvard Business Review, (53:2), March-April 1985, pp. 134-142.
Cash, J.I., Jr., Jensen, M.C., and Clark, T.H. "The Newhall Land and Farming Company (B)," HBS Publishing, HBS Case No. 9-192-050, Boston, MA, 1991.
Cash, J.I., McFarlan, F.W., McKenney, J.L., and Applegate, L.M., Corporate Information Systems Management, Irwin, Homewood, IL, third edition, 1992.
Cash, J.I., Jr., and Ostrofsky, K. "Mrs. Fields Cookies," HBS Publishing, HBS Case No. 9-189-056, Boston, MA, 1989.
Choudhury, V. Cooperative and Competitive Strategies in InterOrganizational Information Systems, Unpublished doctoral dissertation, UCLA, 1991.
Churchman, C.W. The System Approach and Its Enemies, Basic Books, New York, NY, 1979.
Clemons, E.K., "Corporate Strategies for Information Technology: A ResourceBased Approach," Computer, (24:11), November 1991, pp. 23-32.
Clemons E.K. and Kimbrough, S.O. "Information Systems, Telecommunications, and their Effects on Industrial Organization," in Proceedings of the Seventh International Conference on Information Systems, L. Maggi, R. Zmud, and J. Wetherbe (eds.), San Diego, CA, December 15-17, 1986, pp. 99-108.
Clemons, E.K. and Row, M. "Structural Differences Among Firms: A Potential Source of Competitive Advantage in the Application of Information Technology," in Proceedings of the Eighth International Conference on Information Systems, J.I. DeGross and C.H. Kriebel (eds.), Pittsburgh, PA, December 6-9, 1987, pp. 1-9.
Copeland, C.G. and McKenney, J.L. "Airline Reservation Systems: Lessons from History,"
MIS Quarterly, (12:3), September 1988, pp. 353-370.
Davenport, T.H. Process Innovation: Reengineering Work Through Information Technology, Harvard Business School Press, Boston, MA, 1993.
Davenport, T. and Linder, J. "Information Management Infrastructure: The New Competitive Weapon," working paper CITA33, Ernst and Young's Center for Information Technology and Strategy, October, 1993.
DeLuca, J.R. Overcoming Resistance to Change, Evergreen Business Group, New York, NY, 1993.
DeSanctis, G. and Gallupe, R.G. "A Foundation for the Study of Group Decision Support Systems," Management Science, (33:5), May 1987, pp. 589-609.
DeSanctis, G. and Poole, M.S. "Capturing the Complexity in Advanced Technology Use: Adaptive Structuration Theory," Organization Science, (5:2), May 1994, pp. 121-147.
Dierickx, I. and Cool, K. "Asset Stock Accumulation and Sustainability of Competitive Advantage," Management Science, (35:12), December 1989, pp. 1504-1511.
Drucker, P.F. "The Coming of the New Organization," Harvard Business Review, (66:1), January-February 1988, pp. 45-53.
Drucker, P.F. "The Theory of the Business," Harvard Business Review, (72:5), September-October 1994, pp. 95-104.
Fichman, R. and Kemerer, C. "Adoption of Software Engineering Process Innovations: The Case of Object Orientation," Sloan Management Review, (34:2), Winter 1993, pp. 7-22.
Frantz, D. "Bank of America's Plans for Computer Don't Add Up," The Los Angeles Times, February 7, 1988.
Gasser, L. "The Integration of Computing and Routine Work," ACM Transactions on Office Information Systems, (4:3), July 1986, pp. 205-225.
Gersick, C.J.G. "Revolutionary Change Theories: A Multilevel Exploration of the Punctuated Equilibrium Paradigm," Academy of Management Review, (16:1), 1991, pp. 10-36.
Goodhue, D.L., Quillard, J.A., and Rockart, J.F. "Managing the Data Resource: A Contingency Perspective," MIS Quarterly, (12:3), September 1988, pp. 373-392.
Goodhue, D.L., Wybo, M.D., and Kirsch, L.J. "The Impact of Data Integration on the Costs and Benefits of Information Systems," MIS Quarterly, (16:3), September 1992, pp. 293-311.
Gurbaxani, V. and Whang, S. "The Impact of Information Systems on Organizations and Markets," Communications of the ACM, (34:1), January 1991, pp. 59-73.
Hall, G., Rosenthal, J., and Wade, J. "How to Make Reengineering Really Work," Harvard Business Review, (71:6), November-December 1993, pp. 119-131.
Hamel, G. and Prahalad, C.K. "The Core Competence of the Corporation," Harvard Business Review, (68:3), May-June 1990, pp. 79-91.
Hammer, M. "Reengineering Work: Don't Automate, Obliterate," Harvard Business Review, (68:4), July-August 1990, pp. 104-112.
Hammer, M. and Champy, J. Reengineering the Corporation-A Manifesto for Business Revolution, Harper Business, New York, NY, 1993.
Henderson, J.C. "Plugging into Strategic Partnerships: The Critical IS Connection," Sloan Management Review, (31:3), Spring 1990, pp. 718.
Henderson, J.C. and Venkatraman, N. "Strategic Alignment: Leveraging Information Technology for Transforming Organizations," IBM Systems Journal, (32:1), 1993, pp. 4-16.
Hopper, M. "Rattling SABRE-New Ways to Compete on Information, Harvard Business Review, (68:3), May-June 1990, pp. 118-125.
Houdeshel, G. and Watson, H.J. "The Management Information and Decision Support (MIDS) System at Lockheed-Georgia," MIS Quarterly, (11:1), March 1987, pp. 127-140.
Huber, G.P. "A Theory of the Effects of Advanced Information Technologies on Organizational Design, Intelligence, and Decision Making," Academy of Management Review, (15:1), January 1990, pp. 47-71.
Ives, B. and Learmonth, G.P. "The Information Systems as a Competitive Weapon," Communications of the ACM, (27:12), December 1984, pp. 1193-1201.
Jarvenpaa, S. and Ives, B. "Digital Equipment Corporation: The Internet Company (A)," World Wide Web at http://www.isworld.org/mis/cases/dec/internet.html, 1994.
Jessup, L.M., Connolly, T., and Galegher G. "The Effects of Anonymity on GDSS Group Process With an Idea-Generating Task," MIS Quarterly, (14:3), September 1990, pp. 313-321.
Keen, P.G.W. "Information Systems and Organizational Change," Communications of the ACM, (24:1), January 1981, pp. 24-33.
Keen, P.G.W. Shaping the Future: Business Design Through Information Technology, Harvard Business School Press, Boston, MA, 1991.
Keen, P.G.W. Every Manager's Guide to Information Technology, Harvard Business School Press, Boston, MA, second edition, 1995.
Keen, P.G.W. and Scott Morton, M.S. Decision Support Systems: An Organizational Perspective, Addison-Wesley, Reading, MA, 1978.
Kling, R. and Scacchi, W. "The Web of Computing: Computer Technology as Social Organization," in Advances in Computers, (21), Academic Press, New York, NY, 1981.
Konsynski, B. and King, J. "Singapore Tradenet (A): A Tale of One City," HBS Publishing, HBS Case No. 9-191-009, Boston, MA, 1990.
Konsynski, B. and Warbelow, A. "IVANS," HBS Publishing, HBS Case No. 9-187-188, Boston, MA, 1987.
Laudon, K.C. "Environmental and Institutional Models of Information Systems Development: A National Criminal History Systems," Communications of the ACM, (28:7), July 1985, pp. 728-740.
LeonardBarton, D. "Implementation as Mutual Adaptation of Technology and Organization," Research Policy, (17), 1988, pp. 251-267.
LeonardBarton, D. "Implementing New Production Technologies: Exercises in Corporate Learning," in Managing Complexity in High Technology Organizations, M.A. Von Glinow and S.A. Mohrman (eds.), Oxford University Press, New York, NY, 1990, pp. 160-215.
Leonard-Barton, D. and Sviokla, J.J. "Putting Expert Systems to Work," Harvard Business Review, (66:2), March-April 1988, pp. 91-98.
Lucas, H.C., Jr. Information Systems Concepts for Management, Mitchell McGraw-Hill, San Francisco, CA, fifth edition, 1994.
Luconi, F.L., Malone, T.W., and Scott Morton, M.S., "Expert Systems: The Next Challenge," Sloan Management Review, (27:4), Summer 1986, pp. 3-14.
Malone, T.W., Yates, J., and Benjamin, R.I. "The Logic of Electronic Markets," Harvard Business Review, (67:3), May-June 1989, pp. 166-169.
Markus, M.L. "Power, Politics, and MIS Implementation," Communications of the ACM, (26:6), June 1983, pp. 430-444.
Markus, M.L. Systems in Organizations: Bugs and Features, Pitman Publishing, Marshfield, MA, 1984.
Markus, M.L. "Toward A 'Critical Mass' Theory of Interactive Media," in Organizations and Communication Technology, J. Fulk and C.W. Steinfield (eds.), Sage Publications, Newbury Park, CA, 1990, pp. 194-218.
Markus, M.L. "Finding a Happy Medium: Explaining the Negative Effects of Electronic Communication on Social Life at Work," ACM Transactions on Information Systems, (12:2), April 1994, pp. 119-149.
Markus, M.L. and Keil, M. "If We Build It They Will Come: Designing Information Systems That Users Want To Use," Sloan Management Review, (35:4), Summer 1994, pp. 11-25.
Markus, M.L. and Pfeffer, J. "Power and the Design and Implementation of Accounting and Control Systems," Accounting, Organizations, and Society, (8:2/3), February 1983, pp. 205-218.
Markus, M.L. and Robey, D. "Information Technology and Organizational Change: Causal Structure in Theory and Research," Management Science, (34:5), May 1988, pp. 583-598.
Markus, M.L. and Robey, D. "Business Process Reengineering and the Role of the Information Systems Professional," in Business Process Reengineering: A Strategic Approach, V. Grover and W. Kettinger (eds.), Idea Group Publishing, Middletown, PA, 1995, pp. 569-589.
Markus, M.L. and Soh, C. "Banking on Information Technology: Converting IT Spending Into Firm Performance," in Perspectives on the Strategic and Economic Value of Information Technology Investment, R.D. Banker, R.J. Kauffman, and M.A. Mahmood (eds.), Idea Group Publishing, Middletown, PA, 1993, pp. 364-392.
McFarlan, F.W. "Information Technology Changes the Way You Compete," Harvard Business Review, (62:3), May-June 1984, pp. 98-103.
McFarlan, F.W. and Stoddard, D. "OTISLINE (A)," HBS Publishing, HBS Case No. 9-186-304, Boston, MA, revised, 1988.
McKersie, R.B. and Walton, R.E. "Organizational Change," in The Corporation of the 1990s: Information Technology and Organizational Transformation, M.S. Scott Morton (ed.), Oxford University Press, New York, NY, 1991, pp. 244-277.
Neo, B.S., Khoo, P.E., and Ang, S. "The Adoption of Tradenet by the Trading Community: An Empirical Analysis," in Proceedings of the Fifteenth International Conference on Information Systems, Vancouver, BC, Canada, J.I. DeGross, S.L. Huff, and M.C. Munro (eds.), December 14-17, 1994, pp. 159-174.
Neo, B.S., King, J.L., and Applegate, L.M. "Singapore Tradenet (B): The Tale Continues," HBS Publishing, HBS Case No. 9-193-136, 1993.
Norman, D.A. The Design of Everyday Things, Doubleday, New York, NY, 1988.
Nunamaker, J.F., Jr., Applegate, L.M., and Konsynski, B.R. "Facilitating Group Creativity: Experience with a Group Decision Support System," Journal of Management Information Systems, (3:4), Spring 1987, pp. 5-19.
Orlikowski, W.J. and Gash, D.C. "Technological Frames: Making Sense of Information Technology in Organizations," ACM Transactions on Information Systems, (12:2), April 1994, pp. 174-207.
Orlikowski, W.J. and Robey, D. "Information Technology and the Structuring of Organizations," Information Systems Research, (2:2), June 1991, pp. 143-169.
Palmer, J. The Performance Impact of Quick Response and Strategic Alignment in Specialty Retailing, Unpublished doctoral dissertation, The Claremont Graduate School, 1994.
Porter, M.E. Competitive Strategy, The Free Press, New York, NY, 1980.
Porter, M.E. Competitive Advantage, The Free Press, New York, NY, 1985.
Porter, M.E. and Millar, V.E. "How Information Gives You Competitive Advantage," Harvard Business Review, (63:4), July-August 1985, pp. 149-160.
Powell, W.W. "Hybrid Organizational Arrangements: New Form or Transitional Development?" California Management Review, Fall 1987, pp. 68-87.
Rockart, J.F. "The Line Takes the Leadership," Sloan Management Review, (29:4), Summer 1988, pp. 57-64.
Rockart, J.F. and Treacy, M.E. "The CEO Goes On-Line" Harvard Business Review, (60:1), January-February 1982, pp. 82-88.
Schein, E.H. Organizational Culture and Leadership, JosseyBass, San Francisco, CA, second edition, 1992.
Short, J.E. and Venkatraman, N. "Beyond Business Process Redesign: Redefining Baxter's Business Network," Sloan Management Review, (33:1), Fall 1992, pp. 7-21.
Silver, M.S. Systems That Support Decision Makers: Description and Analysis, John Wiley & Sons, Chichester, 1991.
Stalk, G., Evans, P., and Shulman, L.E. "Competing on Capabilities: The New Rules of Corporate Strategy," Harvard Business Review, (70:2), March-April 1992, pp. 57-69.
Stohr, E.A., Jelassi, T., Madnick, S.E., McKenney, J.L., Senn, J.A., and Silver, M.S. "Panel 3: Approaches to the MBA Core Course in Information Systems," in Proceedings of the Eleventh International Conference on Information Systems, J.I. DeGross, M. Alavi, and H. Oppelland (eds.), December 16-19, 1990, Copenhagen, Denmark, pp. 308-309.
Swanson, E.B., Information System Implementation: Bridging the Gap Between Design and Utilization, Irwin, Homewood, IL, 1988.
Tornatzky, L. and Fleisher, M. The Processes of Technological Innovation, Lexington Publishing, Lexington, MA, 1990.
Treacy, M. and Wiersema, F. "Customer Intimacy and Other Value Disciplines," Harvard Business Review, (71:1), JanuaryFebruary 1993, pp. 84-93.
"Trickle-Down Systems," Information Week, May 7, 1990.
Tushman, M. and Romanelli, E. "Organizational Evolution: A Metamorphosis Model of Convergence and Reorientation," in Research in Organizational Behavior, L.L. Cummings and B.M. Staw (eds.), (7), 1985, pp. 171-222.
Valacich, J.S., Dennis, A.R., and Nunamaker, J.F., Jr. "Group Size and Anonymity Effects on Computer-Mediated Idea Generation," in Academy of Management Proceedings, Miami Beach, FL, August 11-14, 1991, p. 447 (abstract).
Vitale, M.R. "Frontier Airlines, Inc. (A)," HBS Publishing, HBS Case No. 9-184-041, Boston, MA, 1983.
Vitale, M.R. "American Hospital Supply Corporation: The ASAP System (A)," HBS Publishing, HBS Case No. 9-186-005, Boston, MA, revised, 1988.
Vitale, M.R. and Konsynski, B. "Baxter Healthcare Corporation: ASAP Express," HBS Publishing, HBS Case No. 9-188-080, Boston, MA, revised, 1991.
von Bertalanffy, L. "The Theory of Open Systems in Physics and Biology," Science, (111), January-June 1950, pp. 23-29.
Walton, R.E. Up and Running: Integrating Information Technology and the Organization, Harvard Business School Press, Boston, MA, 1989.
Wang, C.B. TechnoVision: The Executive's Survival Guide to Understanding and Managing Information Technology, McGrawHill, Inc., New York, NY, 1994.
Weill, P., Broadbent, M., and St. Clair, D. "I/T Value and the Role of I/T Infrastructure Investments," Strategic Alignment, Oxford University Press, Oxford, UK, 1994 (in press).
Weill, P. and Olson, M.H. "Managing Investment in Information Technology: Mini Case Examples and Implications, MIS Quarterly, (13:1), March 1989, pp. 317.
Zuboff, S., In the Age of the Smart Machine: The Future of Work and Power, Basic Books, New York, NY, 1988.
Zuboff, S. and Bronsema, G. "The Expense Tracking System at Tiger Creek," HBS Publishing, HBS Case No. 9-485-057, Boston, MA, 1984.
----------------------------------------------------------------------------------------------
Does the information system leverage the infrastructure?
Mark S. Silver is Associate Professor in the Information Systems Department of the Stern School of Business at New York University. Prior to arriving at NYU, he was a member of the faculty at the Anderson Graduate School of Management at UCLA. He received his Ph.D. from the Wharton School of the University of Pennsylvania. Silver is the author of Systems that Support Decision Makers: Description and Analysis. His current research interests focus on studying the effects Decision Support Systems have on managerial decision-making processes and on analyzing the restrictiveness of information systems. M. Lynne Markus is Professor of Management and Information Science at the Claremont Graduate School. Her current research interests include organizational change and reengineering, the value of investments in information technology, and the role and skills of information systems professionals. Markus was a member of the faculties of UCLA's Anderson Graduate School of Management and MIT's Sloan School of Management. She has received research grants from the NSF, the Office of Technology Assessment, and The Advanced Practices Council of SIM International. She is the author of Systems in Organizations: Bugs and Features and numerous journal articles.
Cynthia Mathis Beath is Associate Professor of Management Information Sciences at the Edwin L. Cox School of Business, Southern Methodist University. She received her doctorate in 1986 from the University of California, Los Angeles. Her research interests focus on the relationship between the information systems organization and its clients, and on the joint management of information technology by this partnership. She is currently investigating the shared management of the information technology infrastructure and the shared management of software sourcing.
Figure 2
More formally, we find justification for our pedagogical model in general systems theory (von Bertalanffy, 1950; Buckley, 1966; Churchman, 1979). As Ackoff (1993) 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 inter-organizational) 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 inter-organizational) 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 synthesisanalysis procedure more consistent with the spirit of general systems theory than straightforward decomposition into component parts, it is consistent with the manager's world view, in which the organization, not the information system, is the center of the universe.INTRODUCING THE MODEL
At this point we ask students how businesses succeed and fail. After some fumbling around, we usually arrive at something that begins to resemble Peter Drucker's (1994) "Theory of the Business." When all goes well, (1) businesses understand their external environments of potential markets and various trends, (2) 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.
Usually, students will concede that the system itself has to be good.
Now, there is much discussion of interface and user friendliness, and a few ITliterate 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.THE MODEL
Figure 3
System Effects
The External Environment
Organizational Structure and Culture
Business Processes
IT Infrastructure
Features of The Information System
Fit Between Information System 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 (Markus, 1983), managerial assumptions (Zuboff, 1988), users' cognitive technology frames (Orlikowski and Gash, 1994), or users' incentives (Markus and Keil, 1994) are likely to be resisted (DeLuca, 1993), 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 system development to produce a system that fits well enough to promote positive effects and system success. The Implementation Process
USING THE IT INTERACTION MODEL:
The IT interaction model can be used in two fundamentally different ways:
PROACTIVE AND REACTIVE ANALYSES
When designing an information system, the model can be used proactively in the early stages of development to anticipate consequences and to design system features accordingly. One way to do this is by first studying the elements of the existing organizational environment and then contemplating the consequences of the planned system, taking into account both intended effects to be targeted as well as undesirable side-effects to be avoided. Following these analyses, the major design choice between incremental improvement and radical change (transformation) is made. And, then, throughout the implementation process attention must be given to the various model elements. In the case of incremental improvement, this means ensuring an adequate fit between the existing environment and the system. In the case of transformation, it entails fitting some elements of the environment while deliberately clashing with others (Markus and Keil, 1994; Gersick, 1991; Tushman and Romanelli, 1985). Moreover, in all cases, one must ensure that the implementation process itself is appropriate and effective. In particular, when the information system is transformative, implementation must support and facilitate the organizational transformation, which often requires changes in other aspects of the organization in addition to the information system itself.A Living Case: A Proactive Illustration
We have used the model as a foundation for a variety of student projects including systems analysis and design assignments (based on predefined case descriptions) and field-based analysis projects (where the teams found their own sites). One approach we found especially worthwhile for the students was to engage the class in a term-long living case where the teams all served as IT consultants to the same client. For each section of the core course, we selected a different unit in the business school that had expressed a need for IT support. These units included the planning office, placement center, and admissions office. Early in the term we devoted one class session to introducing the interaction model and another to a presentation by the client. The formal charge to the students was to "advise the client about IT-related problems and opportunities," but the client briefings typically focused on a particular issue where the client felt IT could be brought to bear. The students were strongly encouraged to apply the model in making their recommendations. During the term, while the class sessions were devoted to readings and cases on topics such as management of IT resources or different types of applications, students scheduled follow-up interviews with members of the client organizations and others whose input was desired. Class time was allocated as needed to address issues of importance to more than one team. At the end of the term, each team submitted a written report and presented an oral summary to the class and the client. OTISLINE: A Reactive Illustration
The OTISLINE ("Otisline (A)," 1988) 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.THE ROLE OF THE MODEL IN THE COURSE
We can summarize the role of the model in the course as follows. The IT Interaction Model is both a foundation for, and an integration of, virtually all the material we cover during the term. We have used the model this way with a variety of core course structures; the appendix provides a sample outline for one such course.
Each of these topics is reflected prominently in the model, yet interwoven with the others as it is in the business world. Consider some examples:OTHER PEDAGOGICAL ISSUES
In this section, we briefly discuss several additional pedagogical issues that have not already been addressed: at what point in the course the model should be introduced, the independence of the model from the particular sequence of topics, and the relationship between the model and other MBA core courses.OBSERVATIONS ON THE MODEL'S EFFECTIVENESS
Based on our experiences at several universities, we believe that the IT Interaction Model is a useful mechanism for addressing a number of practical teaching concerns as well as for achieving our main course objectives. With respect to the pedagogical issues, the model unifies what is often perceived as a "topics" course, the model offers a formal foundation for what students sometimes consider a "soft" or "nonrigorous" subject, the model provides a consistent framework for case analyses, discussions, and group projects, and the model fosters critical business competencies. Since introducing the model several years ago, the feedback we have received has shown a marked reduction in student concern about these matters.CONCLUSION
The IT Interaction Model is best thought of as a stylized view of the dynamics of information systems in organizations. It represents a distillation of the theoretical and empirical research literature into a pedagogical model while at the same time incorporating the concepts, models, and theories that are traditionally covered in the MBA core course. This type of synthesis is rarely, if ever, found in the existing textbooks.
REFERENCES
Table 1
Components of the IT Interaction Model:
Some Examples, Elements, and Descriptors
The External Environment:
Business Processes:
Firm Strategies:
IT Infrastructure:
Organizational Structure:
Information System Features:
Organizational Culture:
The Implementation Process:
Table 2
Reactive Analysis of an Information System
Acknowledgments
Author Biographies