The Institutional Character of Computerized Information Systems
|
|
|---|
Office: Technology and People5 1 (1989):7-28.
ABSTRACT
We examine how important social and technical choices become part of the history of a CBIS and embedded in the social structure which support its development and use. These elements of a CBIS can be organized in specific ways to enhance its usability and performance. Paradoxically, they can also constrain future implementations and post-implementations.
We argue that CBIS developed from complex, interdependent social and technical choices should be conceptualized in terms of their institutional characteristics, as well as their information processing characteristics. The social system which supports the development and operation of a CBIS is one major element whose institutional characteristics can effectively support routine activities while impeding substantial innovation. Characterizing CBIS as institutions is important for three reasons: 1) the usability of CBIS is more critical than the abstract information processing capabilities of the underlying technology; 2) CBIS that are well-used and are based on stable social structures of support (infrastructures) which are more difficult to replace than those with less developed social structures and fewer participants; and 3) CBIS vary from one social setting to another according to the ways in which they are organized and embedded in organized social systems.
It is ironic that we invoke institutional analyses to understand computerization in action. The images of computerization -- new technologies, innovative practices, and a patina of "revolution" -- are diametrically opposed to the stodgy images of institutionalization. The rhetorics of innovation, transformation and revolution emphasize possibilities. These rhetorics deny that historical patterns will continue to shape the future. In fact, computerization has not transformed many organizations as rapidly as some advocates hoped. We argue that innovation need not fail only because of powerful organized resistance. A history of complex social and technical commitments may structure the social organization of computing to make innovation relatively expensive and complex.
These ideas are illustrated with the case study of a failed attempt to convert a complex inventory control system in a medium-sized manufacturing firm.
ACKNOWLEDGEMENTS
The authors appreciate the helpful comments of Paul Attewell, Niels Bjorn-Anderson, Kenneth Laudon and Maria Porcella who helped sharpen our ideas. This research was supported this research under NSF grants DCR-81-17719, DCR-85-08484, and IR 87-09613.
1. INTRODUCTION
Many information systems analysts and organizational theorists focus on the information processing capabilities of computer-based information systems (CBIS) when analyzing their benefits and limitations. They examine how the information processing features of a CBIS makes them into special instruments for enhancing productivity, increasing efficiency, tightening control over resources or workers, and improving strategic advantage (Birnbaum 1985; Braverman 1974; Cash and Konsynski 1985, Galbraith 1977; Gifford and Spector 1985; Gold 1985; Ives and Learmonth 1984; Lawler and Rhode 1976; Pfeffer 1982; Poppel 1985; Simon 1977; Thierauf 1982; Zmud 1983). The literature about what computerization can do for people and organizations is permeated with positive images of interesting social changes which can be catalyzed by CBIS. In this paper we examine why these changes are sometimes difficult to bring about.
The analyses which place the instrumental value of CBIS in the foreground are rich and varied. Some analysts narrowly define CBIS as tools to support specific information processing tasks (Birnbaum 1985; Cash and Konsynski 1985; Galbraith 1977; Gifford and Spector 1985; Gold 1985; Morris et al. 1986; Poppel 1985; Simon, 1977). Other analysts focus on social and political impacts of CBIS implementation and use. Political analysts view CBIS as tools which bring power payoffs such as enhanced decision-making abilities or changes in the distribution of power and influence among different types of staff (Danziger et al. 1982; Kraemer and Kling 1985; Laudon 1974; Lucas 1975; Markus 1984; Robey and Markus, 1984). Marxists argue that managers use CBIS to increase their control over work processes and decrease worker control (Braverman 1974; Mowshowitz 1986; Zimbalist 1979). These accounts assume that rational intentionality can substantially improve the performance of coalitions and organizational units. They also assume that organizational interest groups will be able to control the deployment of the technologies in their physical work settings and usually obtain the outcomes they intend (Pfeffer 1982).
Many empirical studies of actual outcomes of implementing CBIS into organizations show us that anticipated benefits do not materialize easily (Comptroller General of the US 1979; Comptroller General of the US 1978; Kling 1978; Kling 1987; Kling and Scacchi 1982; Markus 1984; Zmud 1983). In extreme cases, a CBIS which fails to meet the preferences of many users can fall into disuse (Brewer 1973; Dery 1981). In other cases, CBIS are not used as they were intended by their designers (Markus 1984). While implementation research has not found a single cause for success or failure, analysts usually point to discrete organizational or technical elements as critical factors: inadequate management, lack of management support, user resistance, or the sheer complexity of the CBIS (Laudon and Laudon 1988).
Managers and other participants in a computerization project can have substantial trouble effectively controlling many aspects of a CBIS implementation. One strategy for understanding the key difficulties of complex implementations is to identify risk factors and undertake probabilistic assessments of success (McFarlan 1981). A second strategy is to broaden the meaning of a CBIS implementation to include "the entire process of organizational change surrounding the introduction of a new information system" (Laudon and Laudon 1988, p. 625). A third strategy suggests that analysts employ an interaction perspective for understanding and planning successful implementations (Markus 1984). The critical focus in these approaches is the interaction between the computerized system and its social/organizational setting: the better the fit between the system to be implemented and the social context in which it will be embedded, the greater its chances of acceptance and use as originally intended. All of these strategies help focus attention on the social context in which systems' implementations take place.
We have developed a set of models, web models, which examine the social context of the settings in which CBIS are adopted, developed, and used (Kling and Scacchi 1982; Kling 1987). Walsham, Symons and Waema (1988) characterize web models in these terms:
"The basic tenet of web models (Kling and Scacchi, 1982) is that a computer system is best conceptualized as an ensemble of equipment, applications and techniques with identifiable information processing capabilities. Each computing resource has costs and skill requirements which are only partially identifiable; in addiction to its functional capabilities as an information processing tool it is a social object which may be highly charged with meaning. There is no specially separable 'human factor' for information systems: the development and routine operations of computer-based technologies hinge on many human judgement and actions, often influenced by political interests, structural constraints, and participants' definition of their situations.
The network of producers and consumers around the focal computing resource is termed the 'production lattice'; the interdependencies in this network form the 'web' from which the model derives its name. The production lattice is a social organization which is itself embedded in a larger matrix of social and economic relations ('macrostructure') and is dependent upon a local infrastructure. According to web models, these macrostructures and local infrastructures direct the kind of computer-based service available at each node of the production lattice, and since they evolve over time computing developments are shaped by a set of historical commitments. In short, web models view information systems as 'complex social objects constrained by their context, infrastructure and history' (Kling and Scacchi, 1982)."
Web analyses are action-oriented and examine the political interplay of coalitions in structured -- but somewhat fluid -- settings (Kling, 1987). The main organizing concepts were a "focal computing technology" which was the center of analysis, the infrastructure which supported its development and operation (including production lattices), its context of development and use, and a history of organizational commitments which structured these arrangements. We did not have a clean way of separating social arrangements which comprised the computing milieu from other social arrangements in the relevant "context." In this paper we introduce a new concept, the social organization of computing, to help make that distinction clearer. We will indicate how some of the structuring of "the social organization of computing" becomes specially rigid and institutionalized. The original formulation of web models treated resource dependencies as key explanatory elements. In contrast, institutional analyses hold that organizations may not change, even when they would improve their resources, power, etc. in response to shifting dependencies with other participants or their "environment." We do not abandon resource dependency explanations, but we seek to expand the richness of web models by incorporating institutional analyses where appropriate.
2. EXPLANATIONS FOR IMPLEMENTATION FAILURE
A guiding insight of "organizational process" theories is that organizations are more "productive" than loose coalitions and markets when they routinize many repeatable activities so as to more easily produce (and reproduce) their basic services and products (Cyert and March, 1963). Routinization makes organizations predictable in the short run. Routinization can characterize any organizational unit, not just the core production units. General Motors doesn't simply build cars with a variety of routinized practices: its approach to subcontracting for parts, setting up dealerships, organizing ad campaigns, negotiating labor contracts, and opening factories overseas are likely to follow some standard guidelines, or "standard operating procedures (SOPs)." SOPs may be formal rules and regulations, informal practices which people carry out for the many activities which are not subject to formal rules, and may even be the routine informal practices which people routinely carry out when they work around formal rules.
The public policy literature points to SOPs as a critical element of organized social systems which acts as a constraining mechanism in bureaucratic organizations. SOPs act as obstacles to change when they are deeply embedded in an organization and difficult to control (Edwards 1980). Public policy analysts argue that when a new policy requires change in an organization's SOPs, there is less likelihood that it will be implemented as its designers intended. One example is the Social Security Administration (SSA) whose staff saw it as a payments program and who were accustomed to evaluating individual claims. When Medicare became law, the SSA acquired new responsibilities for health care containment. Since SSA administrators had little interest or expertise in the planning and budgeting of health care, they focused on denying claims in response to unnecessary or uncovered health care. The Senate Finance Committee criticized this practice and they took a more active role in containing costs. But SSA administrators still emphasized those activities which closely fit their SOPs.
We do not argue that SOPs do not change, or that organizations are locked in forever by their earliest commitments. Older organizations (and older subunits) change slowly except under special conditions. Radical increases or decreases of resources, substantially restructured arrangements for accountability and substantial changes in staffing with people drawn from different social backgrounds or training can all lead to dramatic alterations some organizational behaviors. These are extreme conditions. Many advocates of change programs such as managers, legislators, consultants, regulators, and some academics, want organizations to change particular behaviors without magnificent new budgets or large infusions of new staff with a "fresh view." We argue that substantial changes under these "normal" conditions of relatively stable resources and staffing are often very difficult.
Two major streams of information systems research focus processes that constrain CBIS implementations: the political action approach and the socio-technical design approach. The study of political dimensions in systems implementations examines distributions and possible redistributions of power and influence in organized social systems (Keen 1981; Danziger, Dutton, Kling, and Kraemer 1982; Kling 1978; Kling and Iacono 1984; Markus 1984). The analyses explain why groups support or oppose specific computerization efforts in terms of perceived gains or losses of power.
The socio-technical design approach examines the social processes of system design and conceptualizes computerization as both a social and a technical intervention (Johansen and Baker 1984; Kling 1984; Mumford 1982; Pava 1983). The literature on socio-technical design identifies a participatory social process which would enable those who will use a new technology, i.e., the end-users, to influence its design. From this perspective, implementations fail when the preferences of end-users have not been taken into account in the design of a new system.
These two streams of research have made important contributions to our understanding of implementation processes. The political action analysts taught us how issues of power shaped the implementations of CBIS. The socio-technical analysts showed us how end-users often have critical working knowledge of key organizational practices which good CBIS should account for. However, these approaches cannot explain failed implementations when power shifts are not an issue, when the target group for the implementation had little power, or when end-user preferences have been taken into account in a participatory process.
Individual political explanations of implementation failures are tautological when a failed implementation is the primary evidence of political conflict and resistance. Political action analyses usually ignore the structural features of organizations which can be slow to change or the inter-group dynamics of designing new systems. And they make it seem that powerful interest groups can force change rapidly when they will gain power and can easily deter change when it would be detrimental. We want to retain a political focus on distributions of power within and between organizations because much organizational activity revolves around the interplay of groups vying for control, influence and resources. But we wish to avoid treating intentional-rationality as the major explanation for implementation success and failure (Pfeffer 1982).
Analyses of implementation failures from the socio-technical design approach present somewhat different dilemmas:
1) they emphasize end-user participation prior to the implementation and ignore participation during the post-implementation phase of CBIS use (Kling and Iacono 1984b);
2) they emphasize the social relations between system designers and end-users and exclude resource controllers and other powerful participants within the organization;
3) they focus on design choices implemented in software and ignore the social and technical choices implemented in computerized work environments (Kling and Iacono forthcoming); and
4) they focus on normative prescriptions for participation because they are morally sound workplace practices rather than because they are empirically justified.
We argue that conceptions of complex CBIS (i.e, those developed from complex, interdependent social and technical choices over time) should take into account the social structure of the ensemble of computing equipment and its supporting infrastructure. Some elements of the ensemble are tangible, like the physical distribution of equipment around an office. Other elements of the ensemble are intangible. One cannot "see" the history of commitments that lead to present configurations or the ideologies which give meaning to current configurations and accessible alternatives.
We argue that resistance to implementations can result from the "inertia" of this social structure. We can better explain a wider range of implementation failures when we do not have to rely solely on the purposive rationality of organizational actors since many organizational participants are often unaware of specific system decisions, what outcomes will result from these decisions, and what actions they could take to effect the changes that they prefer.
In this paper we characterize complex, interdependent CBIS as having important "institutional" dimensions. At this point, we will briefly characterize "institutions" as organized social arrangements which persist and are taken-for-granted by participants, even when they do not work well and some powerful organizational actors seek to make substantial changes. The organized technical and social elements of a CBIS have important institutional dimensions when they are not all fluid and easily subject to change by specific coalitions or interest groups. The inflexibility of some organized computing arrangements may impede those who desire large-scale changes. When routines become outmoded and no longer useful to the organization, many managers and users may push for large-scale changes in their computing arrangements.
The organizational routines which facilitated efficient activities and stable environments in the past may prevent the changes which key participants may believe are critical to the organization's continuing survival. We call this kind of organized rigidity, "institutional inflexibility." Rather than focusing blame for failed implementations on resistant end-users on "insensitive" system designers, the focus is on the social arrangements and practices which support the development and operation of the CBIS.
3. THE SOCIAL ORGANIZATION OF COMPUTING
We do not know all the factors that constitute a highly usable and stable CBIS environment. But we will report data from a case study which illustrates the difficulties one organization's members faced when confronted with an important CBIS conversion project(1). Neither the political action approach nor the socio-technical design approach alone could effectively explain the failure since end-users had participated in the decision-making and the project was supported by powerful actors in the organization. We found that the ways in which key social and technical elements were organized and structured impeded the conversion project.
We conceptualize some of these elements as the "social organization of computing." We define social organization of computing as the patterned organization of a mix of computing technologies and social arrangements to support them across organizational units, space, and time. This abstract conception can be made concrete by identifying the different organizational units and participants who interact with a given CBIS or kind of computing technology (e.g., spreadsheets on microcomputers). One identifies:
1. equipment configurations -- the locations of different kinds of equipment (including software) in different organizational units and physical locations;
2. skills and roles -- participants' skills and the different roles that the groups play in providing data, using data, etc.
3. infrastructure -- the support groups and their skills, and the conditions under which their services are accessible to the participants who use the computing technology (e.g., pricing policies, restrictions on access to equipment).
4. important spatial and temporal variations in the organization of computing equipment and infrastructure.
"Social maps" like these organized lists indicate how a computing technology is socially organized in a particular setting. They combine both tangible elements, such as the distribution of equipment and intangible elements, such as skill mixes and patterns of administrative control. Since the actual capabilities of computing technologies to deliver usable information depend upon associated skills, resources, and adjunct equipment, the social map helps indicate which capabilities are accessible to whom, and when. Because it includes some intangible elements, one cannot create such a map by a simple visual inspection. One must learn about the politics and work practices of the organization through other modes of social inquiry, such as interviewing, conversation, written documents, etc.
Computer users usually experience the social organization of computing as part of the social practices in their everyday work world. For example, students who use a university's computer center during daytime weekday hours when consultants and teaching assistants are available often have much more help, but use more congested facilities than students in the same courses who use the same facilities after midnight. The social organization of their computing environments changes between the day and night. Similarly, students who carry out computer work at home on their own micros face a different world of support and time pressure than do students in the same course who use similar equipment in labs where teaching assistants can help students during tightly scheduled 90 minute sessions. In this second example, the location of equipment and assistance and administrative control patterns are key features in the social organization of computing. These two highly simplified examples suggest how the social organization of computing influences the ways that people work and the kind of work that they can do, even when their computing equipment is effectively identical.
The social maps portray a "static snapshot" of the social organization of computing in a particular setting. The social organization of computing changes over time in most settings which we have studied as well as our own university workplaces. It has a dynamic quality which these social maps don't readily communicate. New equipment may be introduced for specialized purposes, and only some staff trained in its use. This may lead to some facilities being highly congested while other facilities have slack capacity. Or some groups may computerize a larger fraction of their administrative records over time, and slowly change the job of their group secretary from a receptionist/typist into a sophisticated computer user.
The static configurations of equipment, skills, support resources, etc. have often been built up slowly over time to meet many different organizational preferences, which are not tightly coordinated. To amplify our last example: the salary scales and job descriptions of many organizations have not yet taken account of the ways in which many professionals and managers have restructured secretarial jobs to require substantial computer skills. Managers and professionals usually computerize with the staff they supervise and rarely attempt to alter personnel classifications and salary scales simultaneously. Similarly, managers who committed their organizations as Hewlett-Packard shops or IBM shops by the 1970s could not have anticipated that their staffs would be using specific proprietary applications with peculiar quirks later on, such as PROFS or HP-Desk (their respective "office" packages) for electronic mail in the 1980s. The social organization of computing one finds today in a particular setting is the product of choices which had many consequences that were not foreseen by key participants when they were first made. This is no surprise, since no one has perfect foresight. However, the social analyst of computing cannot ignore the way that earlier commitments persist and taken for granted even when they are no longer effective.
The social organization of computing which surrounds a complex CBIS is very difficult to characterize concisely. Even the static social maps that we have described above can become quite large and unwieldy. The "map" of the social organization of computing in a particular setting portrays a particular configuration of equipment, resources, practices, and control patterns. These configurations have important historical and dynamic dimensions, as well as the static components and relationships we have discussed above. In an earlier formulation, we segmented these static and dynamic dimensions into three major categories: social, political, and historical (Iacono and Kling, 1988). This factoring is both useful and artificial. Political processes allocate resources, such as money and people, but also social values, such as status and legitimacy. Political processes are social; but we identified them as a separate category because some social analysts of computing focus on cooperative group relationships and ignore intra-group and intergroup politics. We also identified an explicit "historical" dimension because many analyses of computerization discount the way that the social organization of computing in support of a CBIS develops over time in ways that can shape its future, as well as its present. However "historical" has meaning in describing the long-term development of the technical configurations of equipment, the social organization of computing, and the politics of computing in a particular setting. "Historical" is not an independent and parallel category. Because of these dilemmas, we have abandoned this simple tripartite factoring. We will occasionally discuss the "political" or "historical" characteristics of a computing configuration primarily as a way to focus attention.
The computing configurations that develop in any given work setting are not purely instrumental or motivated by exclusively efficiency concerns. Each configuration has social and political meanings for CBIS users. Status differences between professionals and clerks may be reflected in the quality of the workstations in their offices. Practices that give managers newer or larger capacity work stations in private offices while clerical workers share older machines in open bull-pens are rooted more in traditional social practices than in conscious efforts to maximize productivity or efficiency.
In the next section, we will characterize the social organization of computing where it is highly institutionalized. This paper examines how attention to the institutional aspects of the social organization of computing sheds light on the developments of a CBIS in one rich case study. This paper raises also many questions which merit future investigation.
4. CBIS AS SOCIAL INSTITUTIONS
Top managers and other participants cannot rapidly reorganize and improve CBIS which are troublesome. From a rational perspective, such difficulties should be surprising since "skill and will" should be sufficient to effect social change. But larger scale CBIS have important institutional dimensions which limit the abilities of key actors to rapidly transform some of the abstract information processing capabilities of CBIS into concrete systems which serve their interests. The development of specialized computing arrangements facilitates many routine behaviors but constrains very novel behaviors. This specialization and routinization stabilizes social arrangements, but also impedes organizational actors who seek large-scale changes.
The SSA payments system illustrates institutional inflexibility. It produces about 40 million checks per month and was developed in the 1950s in Autocoder; it remained relatively intact through the early 1980s. The SSA has tried to overhaul the payments system at least three times in the last 15 years without success, although a new Systems Modernization Plan that may be completed in the 1990s is in progress (Laudon and Laudon, 1988). Even though some new laws have been passed during the late 1970s (e.g, eligibility requirements) which change the way in which payments are legally distributed, none of these laws had actually been implemented in software for at least five years.(2) We do not have adequately detailed accounts of the earlier efforts to change the SSA's payments systems to understand where the difficulties lay. But the persistence of the SSA's outdated payments system architecture from the 1950s indicates that large scale CBIS can be exceptionally difficult to replace(3).
Characterizing CBIS as institutions is important for three reasons:
1) CBIS vary from one social setting to another (even when they are identical "off the shelf" systems) due to the variety of ways in which social organizations of computing emerge in different settings;
2) The actual usability of CBIS in specific social settings is the critical factor in assessing social benefits, not the potential capabilities of the technology as it may be used by special individuals; and
3) CBIS that are well-used and have stable social structures for supporting and using them will be much more difficult to change or replace than those with less associated social structure and fewer participants.
When analysts emphasize the social and political choices that organizational actors have made over time, they are placing its institutional character in the foreground. Many of these institutional dimensions are intangible and taken-for-granted. Long after some interest groups have lost power or influence in the organization, their interests and visions may still be embedded commitments to equipment, SOPs and organizational arrangements.
Institutionalization theory extends back to Selznick's treatment of organizations as institutions (1957). He distinguished between a rational means-oriented organization and a value-laden institution. Organizations were dispensable once specific goals were fulfilled while institutions strived for permanence. Perrow (1979) built upon this distinction by elaborating on the important interactions between an organization and its environment. Organizations become institutions as they become valued in and of themselves: their disappearance would cause serious problems for participants beyond rational goals or functions. An institution holds social meaning beyond mere instrumentality.
Meyer and Rowan (1977) view institutionalization as a variable. The degree of institutionalization determines the extent to which actions are part of comparatively stable structures or emergent structures. They define institutionalization as: "...the processes by which social processes, obligations, or actualities come to take on a rule-like status in social thought and action" (Meyer and Rowan 177:341).
Laudon (1985:732) proposed an institutional model of system development. He characterized institutions as "a set of widely shared values and interests pertaining to areas of strategic and social importance. These values and interests are served by specific organizations through the allocation of statuses and roles, and they are internalized by individuals through lengthy socialization carried out by organizations." He went on to characterize institutional models as those which "explain organizational behavior in terms of internalized values, interests, and structures." For Laudon, values which most participants in a social system take for granted, such as "professional management" in Federal agencies, are institutionalized and can influence the adoption and development of CBIS.
All conceptions of the term "institution" share a focus on social practices which persist, even when they are not very workable, efficient, or effective. Our conception of "institutionalized behaviors" is much more varied than Laudon's, since key values and structures can become "rule-like" in small social units, like the departments of an organization. For example, accounting departments are much more likely to value accurate data, while production departments in manufacturing are more likely to value meeting quotas by regular shipping dates. Moreover, we focus more on SOPs than on values, even though we believe that values can shape action under special circumstances.
According to Scott (1987), institutional theory is in its adolescence(4). He identifies four major varieties of institutional theories which have influenced sociological investigations. In this paper we are not trying to definitively support our own approach to institutionalization against alternative approaches. Rather we are interested in illustrating how a focus on institutionalized practices and structures sheds light on CBIS implementations that fail. In the PRINTCO case that we describe below, we will examine some of the tangible and intangible dimensions of a social organization of computing that is highly institutionalized. Before we turn to the case in detail, it is worth examining how the social organization of computing develops institutional features.
4.1 Technical configurations
Technology can play a critical role in computerized work settings. The manipulation of information may alter the ways in which work is accomplished and the social relations in the work setting. Moreover, some problems of work can be reduced or even eliminated through improved technologies. But technologies are still only one element in the web of computing (Kling and Scacchi, 1982) and the overall organization of work. Some problems of organizational performance cannot be readily resolved through the continual acquisition of advanced technologies. Organizational performance hinges on the skills of workers, their products, market conditions, etc. as well as on information systems. It is an open empirical question whether highly computerized work settings (e.g., where most people have multifunctional work stations, networks, and leading edge software) are more productive or more competitive than their less computerized counter-parts. For example, text processors can help newspaper reporters write stories and organize notes; but computers don't have a "nose for news" or the ability to meet and interview key informants. Special computerized contact lists can help salesmen locate likely prospects and know something about their preferences. They can help provide compelling cost data. But they can't automatically develop trust and convince a reluctant customer or close a sale.
From an institutional perspective the ways in which work is organized across work groups in an organization influences the SOPs of participant groups. Different user groups often share some interdependent work schedules and routines. In manufacturing work environments, products are shipped as the result of the collective activities of many diverse departments and divisions. The interdependence of work routines implies that the contribution of some component, policy or practice hinges on its dependency upon other components, policies and work-group practices. For example, when a fast machine replaces a much slower machine, one expects speedier production. However, increased demand on the new machine may result in some groups of users waiting in line for access (Schwartz 1975). Their lost waiting time may exceed the gains of speedier technology. Further, when the speedier equipment does expand productivity in one work group, it can lead to log-jams elsewhere. Thus, improvements in some components of an ensemble of computing technologies do not necessarily improve overall performance.
4.2 The Politics of the Developmental Trajectory
The development and use of CBIS are not without conflict. Analysts who push the theme that computing fosters cooperation and rationality gloss over deep social and value conflicts that social change due to computerization may precipitate (Giuliano 1982; Strassman 1977). In practice, organizational participants can have major battles about what kind of computing equipment to acquire, how to organize access to it, and the standards to regulate its use (Kling 1983; Kling and Iacono 1984b; Kling and Scacchi 1982).
When CBIS are characterized as institutions, organizational politics play an important role. Powerful groups can attempt to influence the developments of a CBIS even when they can not control the outcomes they desire (Kling and Iacono 1984b). Data Processing (DP) departments specialize their work over time as they routinely fulfill the computing preferences of particular groups over the preferences of other groups. They are likely to hire new staff who primarily share their world views -- in preferring particular application domains (e.g., finance), languages (e.g., COBOL), equipment vendors (e.g, IBM), etc. However, specialization and routinization reduce the ability of DP departments to engage in work activities which depart from their skills and SOPs at a later time. Consequently, an engineering department which seeks computing support for computational programs written in Pascal or C which run under Unix on a DEC-Vax will usually find systemic difficulties in obtaining meaningful service from a DP shop which develops financial applications on large IBM 308x mainframes under VM in COBOL. (The reverse is also likely -- that finance staff would have difficulty in obtaining high quality data processing service from an engineering oriented computing staff who prefer different kinds of applications, programming languages, and machines.)
Institutions develop a character based on the interests they have served in the past, and the world-views which bind their participants together. Incremental changes in computing arrangements usually improve the fit between a CBIS and its organization. As a CBIS fits an organization better, it is much harder for powerful actors could easily replace it. Participants organize their work lives around the belief that activities which have become routinized will persist. They come to depend on existing social and technical arrangements for working and for achieving personal goals. For these users, and for other important actors in the organization, the particular social organization of a CBIS can become indispensable.
4.3 History of Organizational Practices
In a completely fluid organization a history of social practices will have no bearing on the present: organizational life can be recreated at any time. This kind of completely fluid arrangement is not really "organized" and does not characterize many organizations which last for years. A social order organizes people into positions of responsibility/authority, power and control. Individuals are constrained in using CBIS as they prefer by a variety of organizational practices, within their own work groups or to help coordinate their work with others. Even when the social context of use appears at first glance relatively simple, other agencies may require compliance to their demands or negotiation with peers. Having access to equipment or the use of certain systems may have symbolic as well as instrumental value (Kling 1978).
Institutional analyses emphasize the social use of CBIS and social control over the computing arrangements. When work groups share an information processing resource, such as a CBIS, the resource managers are likely to have negotiated particular arrangements with different groups at different times. These arrangements cross-constrain shared resources. Over time, large changes become potentially more costly and difficult to alter since commitments in the past may limit the range of future configurations. In an institutional analysis, the past is more than prologue to the present: it structures the scripts that characterize the present.
Below, we present a case study in which key actors in one organization attempt a conversion process that was favored by end-users and supported by top management. When we last visited the organization in 1984, four years after the beginning of the conversion, they still had not been successful.
5. THE CASE OF PRINTCO
We present summary case data from one manufacturing organization, PRINTCO, to illustrate the importance of an institutional conception of the social organization of computing(5). Our data from PRINTCO are based on 44 detailed interviews which we conducted over an eighteen-month period with 40 respondents in a variety of roles, departments and levels of authority. All of our respondents were either users or resource controllers of the Material Requirements Planning(6) (MRP) system, the core module of the manufacturing division's inventory control system.
PRINTCO is a medium-sized manufacturing firm (about 800 employees) which designs, makes and markets several lines of medium-speed dot matrix line printers for the mini-computer and small business computer marketplace. The firm has positioned itself as a low-cost producer in a highly competitive market. PRINTCO began shipping printers in 1975 and maintained a fairly constant demand of 12,000-15,000 printers a year during the late 1970s despite market fluctuations. During the 1980s the firm grew rapidly to become a major producer of dot matrix line printers.
In 1977 key actors adopted and began operating a simple MRP system which they purchased from a nearby manufacturing firm. They wanted better control over their investments in purchased parts. They wanted parts to be on hand when needed but not sitting in inventory many months in advance so that costly inventory would build up. The MRP system helped the material control staff reduce inventory costs (and increase inventory "turns").
In the late 1970s PRINTCO grew by diversifying the variety of printers produced. They started new product lines, and also increased the variety of ways in which they would customize printers for special orders. The new products complicated the logistics of managing inventory. The material control managers began looking for more sophisticated MRP software to help resolve manufacturing logistics problems, like capacity planning, tracking multiple simultaneous revisions of products, and accounting for planned orders. An informal committee found an MRP package that satisfied their preferences. But it ran on a Data General minicomputer, a DG S350 Eclipse, rather than on their IBM System 34. So they purchased a DG Eclipse. The new MRP package was also written in BASIC -- a new language for PRINTCO's manufacturing division -- since all of their administrative information systems were written in RPG-II.
The conversion began in 1980 and the DP staff believed that it would take one year. After 18 months, staff had not completed the conversion. Unexpected problems plagued the project. The computer vendor (Data General) provided PRINTCO with telephone support, but little assistance on site. The DP manager had problems hiring more programmers with the necessary skills to work on the conversion. They wanted programmers with both RPG-II and BASIC skills, but paid relatively low salaries for programmers. Many of the original systems, including the MRP system, were not well documented and information gaps further complicated the conversion project. Some of the programmers had patched the MRP system over the years had left the company. The current DP staff feared making large scale changes because they were unsure about how some of the modules interacted.
MRP users around the firm complained about DP because they had waited a long time for a payoff. The DP staff's morale was low. They had invested tremendous effort and resources, but no longer believed they could convert to the new MRP system. The senior vice president of manufacturing saw an impending crises. He formed a data processing steering committee to guide and direct the DP manager. The steering committee gave the DP manager specific schedules, but he failed to meet them.
The steering committee hired a new DP manager after a six-month search in which they found few acceptable candidates. His technical background was weak, but his managerial skills were stronger. He promptly ended the conversion project. Members of the steering committee had become resigned to sell the hardware and lose their investment in the software. The new DP Manager and the committee decided to continue working with their existing IBM System 34, enhancing the MRP system as best they could and possibly leasing another System 34, if necessary. DP upgraded the existing disk and added memory. Additional ports enabled 13 people to log on simultaneously. The new DP Manager established short-term and long-term priorities for departmental work at the steering committee's direction. In addition, the committee required and approved written user requests for new programming tasks.
Unfortunately, the new DP Manager did not follow the direction of the steering committee and tried to mobilize support for purchasing a more sophisticated computer (an IBM System 38). The steering committee saw little progress on the enhancements of their MRP system. After 10 months, the steering committee fired the new DP manager.
Because of the long and arduous work invested in hiring the prior DP Manager, the steering committee decided not to search outside the firm for a third DP manager. Instead they promoted the manager of engineering services to the role of Operations Director, a new title for the DP manager. Almost immediately, they decided to buy an IBM 4331(7) and found new MRP software to satisfy their preferences. They started a new conversion project. The preferences of manufacturing staff mobilized the original conversion effort. DP staff avoided requests from other user departments during this time. Staff in other departments began searching for other ways to satisfy their computing needs.
A few departments obtained DEC LSI-11 micro-computers from test equipment cast off by other departments. They upgraded them into usable computing equipment with the help of their own skilled staff. Other departments then requested and received new LSI-11 micros. Because of problems in DP, no one had paid much attention to the proliferation of micro-computing. Soon 6 to 10 LSI-11's were scattered around the firm. One staff member in the test equipment area became the informal "expert" in operating, programming and using the micro-computers.
PRINTCO had hired consultants and new programmers to help in the conversion to MRP II on the IBM 4331. DP staff began working on other projects so that other users would stop complaining. DP had become a larger more successful organization.
6. AN INSTITUTIONAL ANALYSIS OF PRINTCO's MRP CONVERSION FAILURE
We have identified several major problems in PRINTCO's failure to convert from their original MRP system to a more sophisticated MRP system. These problems are the product of key actors foregrounding the potential information processing benefits of the new technologies to the extent that they ignored the social organization of their current computing environment. They were not simply replacing one MRP system for another, they were also attempting to replace the existing social organization of computing in their firm with an altered configuration. Although their computing environment was small and somewhat informal, it was usable and stable, i.e. it was highly organized in very specific ways.
How can we characterize the social organization of computing at PRINTCO when they first began their conversion? We have selected some episodes to illustrate how intangible dimensions of the social organization of computing can be highly organized and constrain substantial change. None of these issues were taken into consideration prior to the conversion project. It is only through our analysis of the case that we could extract some explanation for the continuing failure of the conversion project at PRINTCO.
6.1 Specialization
The most powerful organizational actors were located in manufacturing and finance. As a result, they controlled the direction of data processing at PRINTCO and were their best-served customers.
Since the implementation of the original MRP system, the data processing department had become specialized in altering reports from existing systems written in RPG-II. The DP staff became skilled in producing the routine MRP reports for manufacturing and occasional reports for finance. The programmers were demand driven and spent their time responding to constant requests for major and minor enhancements. These enhancements were relatively simple, concrete, predictable, and generated immediate results, compared with converting the MRP system.
Programming support and computing operations became specialized around these services running a small set of CBIS and making minor enhancements. The existing MRP was custom tailored to PRINTCO's manufacturing operations.
6.2 Work Prioritization Schemes of Support Staff
The first DP manager had served as a one-man DP shop during PRINTCO's earliest days. He spent most of his energy programming even after he added several more staff. Over the years, he never fully accepted the role of manager. He preferred to spend his time as a programmer/analyst rather than manage his staff. As a result, the staff were left to set up their own work priorities. And because of his early independent stature, none of the Vice Presidents ever made him accountable to any formal schedule.
Requests came into DP informally. The ordering of projects and distribution of programming time often depended on informal contacts between programmers and users. Short-term, routine projects received the most attention from staff and long-term, non-routine projects received little attention or effort. The conversion from the original MRP to a more sophisticated one was a novel effort which did not fit the routine established work patterns of this small DP shop. Staff could easily keep themselves busy with their routine work and put off the more difficult conversion work.
The programmers and end-users worked together in very simple face-to-face negotiating contexts. Programmers would comply with these requests on a first-come, first-served basis with no planning or prioritization schemes other than what the programmer felt s/he could do first.
After the DP manager was replaced, the new manager instituted some prioritization schemes for ordering programming work based on the decisions of the members of the newly formed steering committee. The manager gave work to the programmers according to their skill and availability, not according to their informal ties or rapport with end-users. It was hoped that these changes could move the DP department from a simple operation to one that could handle more complex work tasks and larger more novel projects.
6.3 Skills of Computing Staff
PRINTCO's programmers had learned to write and modify simple RPG-II programs on the job. The new MRP software was technically more sophisticated than the old MRP software and was written in a different language, BASIC. Since the new software would not run on the IBM System 34 mini-computer, manufacturing managers also purchased a new Data General minicomputer. However, none of the programmers had ever used BASIC or the operating system of the new minicomputer. They attended several BASIC programming classes but their learning curve was slow. Key actors tried to hire people who could program in both BASIC and RPG-II to expedite the conversion. However, they could not locate and hire new programmers with programming skills in both languages.
PRINTCO's managers purchased the new MRP software from an outside vendor because none of the current DP staff had appropriate software development skills to develop a newer more adequate MRP system. Substantial development skills had been unnecessary in the past since the programmers had worked only on maintaining their present CBIS, the MRP system and some finance systems. And they had never before attempted to hire new staff with specific software development skills. PRINTCO's managers presumed that their DP staff had all the skills necessary for most computing tasks or could easily acquire them. They had not realized that the skills and work routines of the department were very specialized and limited.
6.4 Laissez Faire Attitudes
Key actors at PRINTCO had developed a laissez faire attitude toward DP staff and the resources they might need to develop an adequate social organization of computing for the conversion. Once funds were allocated for purchasing equipment, the more powerful actors ignored the tempo development for over a year. The original DP manager had never been a powerful organizational actor who could fight for the resources he might have needed to complete his project on schedule. It was only after the project foundered, that some of the key managers tried to more tightly control DP through the steering committee and hiring a new DP manager. The steering committee was a new approach, and actually was a break with prior SOPs in giving the DP department substantial autonomy.
6.5 Control over New Developments
Before starting the conversion project, key manufacturing staff members focused on equipment decisions and negotiating the purchase. They based their decisions on the preferences of users in manufacturing who wanted a sophisticated on-line MRP system. The informal selection committee invested time and energy into selecting equipment. Once the equipment was purchased, they returned to their own routine work. After a year had gone by, some managers started asking critical questions about the conversion.
They discovered that there were more problems than progress. The conversion effort was expensive and showed no results. The laissez faire attitude of upper managers toward DP had not proved successful. Key actors who had originally thought of their new MRP system as a tool for manufacturing staff attempted to gain control over many aspects of the computing environment. They formalized their own membership in a steering committee (Lucas 1986). Within the framework of the committee, they finally began to focus on changes in the social organization of computing that might enhance and support the conversion.
6.6 The Micro-computer Revolution
Other staff in the organization, especially staff in test-engineering, had to develop their own computing environments. Many of these staff had the skills to develop an adequate infrastructure of support for their own work groups even though they had very little money to spend on equipment. They were effectively cut out of discussions about the conversion project both at the early stages and later when the steering committee was organized. Consequently the firm never took advantage of the skills and expertise that had developed around computing in the engineering departments.
Staff in engineering sought their own microcomputers. These staff viewed their micros as tools which helped them develop small scale CBIS independently of the ineffective DP shop. The micro-revolution lasted a year, before control over computing equipment and programming was recentralized under DP.
During the conversion project, two parallel computing environments were developing independent of each other. Each required investments of time and money from the organization. Each was left to run its own course with little direction and modest resources.
6.7 Summary
We were impressed by the number and variety of actions taken by Printco's upper-middle managers in attempting to convert their MRP system: they changed DP managers several times, changed computers, and restructured the reporting relationships of DP. In Starbuck's (1983) telling image, they generated a lot of action. But these sorts of actions substantially strengthened the infrastructure for computing support at PRINTCO. They were inadequate for creating a DP milieu that would attract programmers with appropriate developmental skills to effectively convert their software. Appropriate changes would have required building a more exciting software development environment and substantially raising the salaries of programmers -- shifts with many repercussions(8). PRINTCO's managers acted in ways they knew (standard operating orientations), such as minor reorganizations and changing managers. These kinds of would not shake up their organization -- as would many new CBIS in an exciting development environment and new programmer's salary scales. They fit PRINTCO's institutional history, but they were ineffective.
7. INSTITUTIONAL ANALYSES OF CBIS
The social organizations of computing which support key CBIS are highly institutionalized in most complex organizations. The use and control of the CBIS are shared among interest groups with different preferences, stakes, and historical commitments. The institutional dimensions of computing add complexity and inertia which make novel changes in technology which are not "upwardly compatible" slower and more costly than many participants would wish.
At PRINTCO, key actors made the decision to purchase a new MRP system based on its technical capabilities and potential benefits to users in the manufacturing division. Their computing environment had many organized work practices, commitments, specializations and routines which they did not take into account when they made the decision. Routine work specializes the social organization of computing. Staff at PRINTCO specialized in producing reports from existing systems in RPG-II. They performed these activities well. A combination of specific skill levels, the organization of their work prioritization schemes, and commitments to certain users in manufacturing led to computing arrangements which supported their routine work but did not support software development. Their commitments to uncommon combinations of technologies (MRP written in RPG-II and BASIC) made it difficult for them to hire programmers with new development skills.
Staff stabilize and routinize their work environments and create highly organized computing milieus in the process. The case of PRINTCO illustrates an important paradox: a useful and stable CBIS can be problematic when key organizational actors try to change it in adapting to new conditions. Even when CBIS are fairly primitive and social relations are informal, as it was at PRINTCO at the time of the conversion, elements of the computing environment had became highly organized and taken-for-granted. Critical social dimensions that could have been taken into account by organizational actors include: the skills and work expectations of computing staff; the work prioritization schemes that had developed between computer staff and end-users; who controls new developments in the computing environment and the deployment of resources; organizational practices about training users and computer staff; the degree of specialization in terms of computing software and hardware; and past commitments to the specific work groups which effectively exclude other groups from decision-making.
We argue that computing arrangements that are highly institutionalized will arise wherever there is shared control and interest groups vying for the resources of a CBIS. An institutional analysis is critical for understanding how CBIS are likely to be used in more complex work settings where constraints and limitations are part of the everyday work world. It is a paradox that the more stable and usable a current social organization of computing is, the more difficult it will be to make substantial changes. This does not mean that implementations of new CBIS are impossible. Rather, the social organization of computing must be taken into account prior to the setting of realistic expectations of performance and schedules. In practice, we observe that new generations of CBIS and other replacement computer technologies are often implemented and effectively used on a much slower time scale than many key participants expect.
It is ironic that we invoke institutional analyses to understand computerization in action. The images of computerization -- new technologies, innovative practices, and a patina of "revolution" -- are diametrically opposed to the stodgy images of institutionalization. The rhetorics of innovation, transformation and revolution emphasize possibilities. These rhetorics deny that historical patterns will continue to shape the future. In fact, computerization has not transformed many organizations as rapidly as some advocates hoped. We argue that innovation need not fail only because of powerful organized resistance. A history of complex social and technical commitments may structure the social organization of computing to make innovation relatively expensive and complex.
Institutionalization has many ironies. Innovators like to see their innovations widely adopted for indefinite periods. Moreover, there are many economies of scale when innovations are institutionalized (Kraemer, Perry, King, and Dunkle, 1988). But the technologies and innovative practices of one era have often acted as a brake on subsequent innovation. For example, once an organization develops technical standards, they often remain in place for decades, despite the availability of technically better alternatives. COBOL is still a mainstay business programming language after 30 years, despite the wide availability of fourth generation database languages. MS-DOS and IBM-PC compatible micros remain the business standard, despite the availability of MacIntoshs with easier to learn interfaces and IBM's promotion of a more complex OS/2 operating system. In cases like these, the immense installed base of earlier technologies means that substantial conversions are also very costly, in changing equipment, skills, visions of "appropriate computerization," and organizational practices. We would be surprised to see COBOL and MS-DOS comparably entrenched in 30 years, since organizations do shift their technical commitments.
Similarly, the social organization of computing in organizations does shift over time. The widespread use of microcomputers has moved the locus of control on some systems from central information systems departments to end users. These shifts of control are coupled with shifting ideologies about what computers are good for and how computerization projects should develop. But again, such changes are relatively slow in many organizations. Social theories of computerization have to accommodate social processes of change and of stasis. We are not optimistic about the prospects of creating good dynamic theories of computerization since organization-level theories of structural/political change and stasis are not well developed either. Even so, this is terrain opened up by changing technologies and technologies of change.
REFERENCES
Birnbaum, J. "Toward the Domestication of Micro-electronics." Communications of the ACM, Vol. 28, 1985, pp. 1225-1235.
Braverman, H. Labor and Monopoly Capital: The Degradation of Work in the 20th Century. Monthly Review Press, New York, 1974.
Brewer, G. Politicians, Bureaucrats, and the Consultant: A Critique of Urban Problem-solving. Basic Books, New York, 1973.
Cash, J.I. and Konsynski, B. "IS Redraws Competitive Boundaries." Harvard Business Review, Volume 63, March-April, 1985, pp. 134-142.
Comptroller General of the United States. Data Base Management Systems--Without Careful Planning There Can Be Problems (Report No. FGMSD-79-35). Washington, D.C., U.S. General Accounting Office, 1979.
Comptroller General of the United States. Inadequacies in Data Processing Planning in the Department of the Interior. (Report No. FGMSD-78-41). Washington, D. C., U. S. General Accounting Office, 1978.
Comptroller General of the United States. Social Security Needs to Better Plan, Develop and Implement its Major ADP Systems Redesign Projects. in Kling and Scacchi, 1982.
Committee on Government Operations, U.S. Congress. Air Traffic Control Systems Failures. in Kling and Scacchi, 1982.
Cyert, R. and J. March. The Behavioral Theory of the Firm. Prentice Hall, Englewood Cliffs, NJ: 1963.
Danziger, J.; Dutton, W. H.; Kling, R.; and Kraemer, K. L. Computers and Politics: High Technology in American Local Governments. Columbia University Press, New York, 1982.
Dery, D. Computers in Welfare: The MIS Match. Sage, Beverly Hills, CA, 1981.
Edwards, G.C. Implementing Public Policy. Congressional Quarterly Press, Washington, D.C., 1980.
Galbraith, J. Organization Design. Addison-Wesley, Reading, MA, 1977.
Gifford, D. and Spector, A. "The CIRRUS Banking Network." Communications of the ACM, Vol. 28, 1985, pp. 788-796.
Giuliano, V. "The Mechanization of Office Work." Scientific American, Vol. 247, No. 3, 1982, pp. 148-164.
Gold, B. "CAM Sets New Rules for Production." Harvard Business Review, Vol. 63, March-April, 1985, pp. 134-142.
Iacono, S. and Kling, R. "Computer Systems as Institutions: Social Dimensions of Computing in Organizations." Proceedings of the International Conference on Information Systems. Minneapolis, Minnesota. December, 1988.
Ives, B., and Learmonth, G. P. "The Information System as a Competitive Weapon," Communications of the ACM, December 1984.
Johansen, R. and Baker, E. "User Needs Workshop: A New Approach to Anticipating User Needs for Advanced Office Systems." Office: Technology and People, Vol. 2, 1984, pp. 103-119.
Keen, P.G.W. "Information Systems and Organizational Change." Communications of the ACM, Vol. 24, 1981, pp. 24-33.
Kling, R. "Automated Welfare Client-tracking and Services Integration." Communications of the ACM, Vol. 21, 1978, pp. 484-493.
Kling, R. ``Assimilating Social Values in Computer-based Technologies" Telecommunications Policy. (June 1984): 127-147.
Kling, R. "Defining the Boundaries of Computing Across Complex Organizations." In R. Boland and R. Hirschheim (eds.), Critical Issues in Information Systems Research. John Wiley, London, England, 1987.
Kling, R. and Iacono, S. Behind the Terminal: The Backstage Organization of Computing in Organizations. PPRO Working Paper. University of California, Irvine, 1983.
Kling, R. and Iacono, S. "Computing as an Occasion for Social Control," Journal of Social Issues, Vol. 40, No. 3, 1984, pp. 77-96.
Kling, R. and Iacono, S. "The Control of Information Systems Development after Implementation," Communications of the ACM, Vol. 27, 1984, pp. 1218-1226.
Kling, R. and Iacono, S. "Computerization as a Social and Technical Intervention into Work Organization: The Case of Desktop Computing." Revue International de Sociologie, forthcoming.
Kling, R. and Scacchi, W. "The Web of Computing: Computer Technology as Social Organization." Advances in Computers, Vol. 21, 1982, pp. 1-90.
Kraemer, K.L. and Kling, R. "The Political Character of Computerization in Service Organizations: Citizen Interests or Bureaucratic Control." Computers and the Social Sciences, Vol. 1, 1985, pp. 77-90.
Kraemer, K.L., Perry, J., King, J.L. and Dunkle, D. "Institutionalization of Technological Change in Public Organizations." PPRO Working Paper. University of California, Irvine, August 1988.
Kraemer, K.L., King, J.L. and Dunkle, D. and Lane, J. Managing Information Systems: Change and Control in Organizational Computing. San Fransisco, Jossey Bass. 1989.
Laudon, K. C. Computers and Bureaucratic Reform. Wiley, New York, 1974.
Laudon, K. C. Dossier Society. Columbia University Press, New York, 1986.
Laudon, K. C. "Environmental and Institutional Models of System Development: A National Criminal History System." Communications of the ACM, July 1985, Vol. 28, pp. 728-740.
Laudon, K. C. and Laudon, J. P. Management Information Systems: A Contemporary Perspective. Macmillan Publishing Company, New York, 1988.
Lawler, E. E. and Rhode, J. G. Information and Control in Organizations. Goodyear, Santa Monica, CA, 1976.
Lucas, H.C. Jr. Why Information Systems Fail. New York, Columbia University Press, 1975.
Lucas, H.C. Jr., (ed.) A Casebook for Management Information Systems. (3rd ed.), McGraw-Hill, New York, 1986.
Markus, M.L. Systems in Organizations: Bugs and Features. Pitman Pub. Co, MA, 1984.
Mautz, R.; Merten, A.; and Severance, D. Senior Management Control of Computer-based Information Systems. Financial Executives Research Foundation, Morristown, NJ, 1983.
Meyer, J. and B. Rowan. Institutional Organizations: Formal Structures as Myth and Ceremony. American Jrnl. of Sociology. 83:340-363, 1977.
Morris, J.; et. al. "Andrew: A Distributed Computing Environment" Communications of the ACM, Vol. 29, 1986, pp.184-201.
Mowshowitz, A. ``The Social Dimensions of Office Automation." Advances in Computers, New York, Academic Press. 1986.
Mumford, E. Designing Secretaries. Manchester, England, University of Manchester Business School Press, 1982.
Olson, M. and Ives, B. "An Empirical Study of User Involvement on System Usage and Information Satisfaction." Communications of the ACM, Vol. 29, 1986, pp.232-238.
Pava, C. Managing New Office Technology: An Organizational Strategy. New York, Free Press, 1983.
Perrow, C. Complex Organizations: A Critical Essay. (2nd ed.), Scott, Foresman and Company, Glenview, IL, 1979.
Pfeffer, J. Power in Organizations. Pitman Publishing, Marshfield, MA, 1981.
Pfeffer, J. Organizations and Organization Theory. Pitman Publishing, Marshfield, MA, 1982.
Poppel, H. "Who Needs the Office of the Future?" Harvard Business Review, Vol. 63, March-April, 1985, pp. 146-155.
Robey, D. and Markus, M.L. "Rituals in Information System Design," MIS Quarterly, March 1984.
Schwartz, B. Queueing and Waiting: Studies in the Social Organization of Access and Delay. University of Chicago Press, Chicago, 1975.
Scott, W. R. "The Adolescence of Institutional Theory" Administrative Science Quarterly, 32: 493-511, 1987.
Selznick, P. Leadership in Administration: A Sociological Interpretation. Harper and Row, New York, 1957.
Simon, H. A. The New Science of Management Decision. Prentice-Hall, Englewood Cliffs, NJ, 1977.
Starbuck, W. "Organizations as Action Generators." American Sociological Review. 48 (February): 91-102.
Strassman, P. Information Payoff: The Transformation of Work in the Electronic Age. New York, Free Press, 1985.
Thierauf, R. Decision Support Systems for Effective Planning and Control. Prentice-Hall, Englewood Cliffs, NJ, 1982.
U.S. Congress, Office of Technology Assessment. The Social Security Administration and Information Technology - Special Report OTA-CIT-311. U.S. Government Printing Office, Washington D.C. October 1986.
Walsham, G., Veronica Symons, and Tim Waema. "Information Systems as Social Systems: Implications for Developing Countries" Information Technology for Development 3(3) (1988).
Zimbalist, A. (ed.) Case Studies in the Labor Process. Monthly Review Press, New York. 1979.
Zmud, R. Information Systems in Organizations. Scott-Foresman, Glenview, Ill, 1983.
Zucker, L. Institutional Patterns and Organizations: Culture and Environment. Ballinger, Cambridge, Ma: 1988
1. 1 We have published some aspects of this case study of the development of a material requirements planning system in a medium sized manufacturing firm, PRINTCO, in several prior publications (Kling and Iacono, 1984b; Kling, 1987). This article is not primarily about PRINTCO; rather we use the case of PRINTCO to illustrate some of our key concepts and arguments.
2. Walter Doughtery of IBM, Yorktown Heights, reported this situation in a lecture to the Department of Information and Computer Science, University of California, Irvine, October 27,
1983.
3. Like the Internal Revenue Service (IRS) still relied upon systems designed in the 1950s for their operations in the early 1980s. However the IRS seems to have modernized (and decentralized) some of their major information systems in the mid-1980s. The contrast between the IRS and the SSA suggests that large organizations are not necessarily locked into an unchanging iron cage by their computerized information systems. We suspect that IRS role as a major collector of revenue for the Federal government in contrast with the SSA's payments system as a payout system may have made some difference in the willingness of Congress and top administrators to fund major system changes. This resource dependency argument is speculative. But it suggests that both resource dependency and institutional explanations may have important roles in explaining the success/failure of CBIS implementations under different conditions.
4. Institutionalization theory -- which examines social stability -- is, ironically, still developing and dynamic. See Zucker (1988) as well as Scott (1987) for accounts of recent developments.
5. For a chronology of system developments at PRINTCO, please refer to Kling and Iacono (1984b).
6. A material requirements planning system is a complex form of inventory control. It produces lists of components to manufacture or purchase based on: (a) a schedule for producing finished goods; (b) bills of materials which indicate which parts and sub-assemblies are connected to each other; © detailed data about the time to manufacture or purchase different components; and (d) the current inventory of parts and sub-assemblies on hand in the stock room.
7. The IBM 4331 was larger than the System 38 which the steering committee rejected. And it was a potential platform for a substantially more sophisticated computing environment.
8. PRINTCO was paying its programmers about 60% of the salaries expected by programmers with adequate development skills. Some of the more immediate repercussions would be faced by current programming staff (who were good at maintaining existing systems), as well as managers who might earn much less than some young programmers.