This infrastructure is designed and controlled by managers and IT personnel, but also an actor shaping its environment as well as its own future. Like any actor, the technology builds alliances with others. However, the alliances might change over time. In the case reported here, SAP first got allied with top management, playing the role as a powerful change agent. Later on SAP got allied with local managers and users, helping them bringing the change process under their influence and into speed they preferred. Currently, SAP is changing its role as it gets installed and integrated into a larger corporate infrastructure. As such, it becomes everybody's enemy by resisting all organizational change.
The notion of infrastructure has become popular in the information systems community in later years. However, infrastructures seems to be assumed similar to information systems, i.e. as completely designed and controlled by humans (Broadbent and Weil, 1997; Broadbent, Weill, and St. Clair, 1995). We will in this paper draw on two theories going beyond this view on technology - the "economics of infrastructure and standards" and actor-network theory.
The case of large infrastructures reminds us that the management of infrastructure goes beyond the boundaries of centralized, hierarchical control of a resource. Infrastructures differ from "systems" in being a shared resource for a larger community rather than an organizational unit. Further, one infrastructure builds upon and is integrated with others into networks with no limits. As such, infrastructures cannot be designed and managed according to principles of (isolated, stand alone) information systems. They are developed and changed by several independent actors without any explicit coordination. The main coordinator is the shared infrastructure itself. Further, large infrastructures cannot be changed instantly - only piecewise. At the same time as it is subject to such a change process, it has to work as usual. This requirement severely constrains the design of the new elements, implying that the existing infrastructure - the installed base - has strong influence on the future development of the infrastructure (Grindley 1995, Hanseth 1996). While resisting change, and having reached a certain level of distribution and use, it gains momentum and drives its own further growth (Hughes 1987). It becomes an actor, and a designer.
Some infrastructures might appear "designed." Taking the Internet as an example, one might consider it designed as the protocol standards are. However, whether the protocols are designed in a traditional sense can be debated, as illustrated by the struggling behind the new version of IP (Hanseth et al. 1996). Looking at the physical network, its structure is highly emergent (Ngwenyama, 1998), being built by a vast range of operators and companies linking their networks to the existing Internet. Looking at how information is made available and the way it is structured, one will see an even more uncoordinated process. Also corporate infrastructures are often emergent as they are typically established through side effects of and spill-over from the implementation of increasing numbers of information systems as well as their closer integration. Through such processes, a complex infrastructure emerges and the information systems become less independent.
When infrastructures grow and their use increase, they indeed become large irreversible actor-networks. Within management and engineering literature, technology is primarily seen as something to be designed, i.e. as completely controlled by and a product of human activity. In other literatures, more focused on macro level processes, the usual story is how technology changes the world. More than any other technology is IT seen as such a revolutionary force. In these stories technology is the master - or designer - and society its material being "designed." We will apply actor network theory which is one approach explaining how humans are shaping technology (under some constraints - of course) at the same time as technology influence the development of society beyond what was intended by the designers without completely determining its path (Callon 1991; Latour 1987, 1991).
In actor network theory, technological and social elements are considered tied together into networks, based on the assumption that technologies are always defined to work in an environment including non-technological elements - without which the technology would be meaningless and it would not work. In the same way, humans use non- human objects (technologies and other artifacts) in all our dealings in our world - our existence in the world is based upon the existence of these objects. Accordingly, neither humans nor technological artifacts should be considered as pure, isolated elements, but rather as heterogeneous networks. When any actor acts, this very actor is always such a network, not a single element. In the same way, elements in a network are not defined only by their "internal" aspects, but rather by their relationships to other elements, i.e. as a network. This further implies that elements in such a network are not initially defined as human, social or technological, they are referred to by a common term - actant. These assumptions do not deny any differences - or borders - between what is human or social and what is technological. However, these borders are seen as negotiated, not as given.
According to actor network theory, stability, technological and social order, are continually negotiated as a social process of aligning interests. As actors from the outset have a diverse set of interests, stability rests crucially on the ability to translate (re-interpret, re-present or appropriate) others' interests to one's own. Through translations one and the same interest or anticipation may be presented in different ways thereby mobilizing broader support. A translation presupposes a medium or a "material into which it is inscribed." Translations are "embodied in texts, machines, bodily skills [which] become their support, their more or less faithful executive" (Callon 1991, p. 143). Design is then a processes where various interests are translated into technological solutions as well as organizational arrangements and procedures to be followed to make the technology work properly. In this process, existing technology will be re-interpreted and translated into new ways of using it. To make the technology work, all these elements must be aligned. As large actor-networks are aligned, they may become irreversible, and hard to change (Callon 1991, Hanseth and Monteiro 1997).
In spite of the fact that viewing SAP installations as isolated information systems seems to be shared by virtually everybody in Hydro, we believe, and will show in this paper, that it would be beneficial to consider SAP within Hydro as an information infrastructure, or as an actor in an actor network. The reason for this is, first, that some of the installations are becoming so large that they are getting the character of an infrastructure. This is the case for the SAP installation in HAE. Second, each installation is becoming integrated with other SAP installations as well as other systems and infrastructures, in particular the Bridge infrastructure. Thus, SAP in Hydro is a large and complex emergent infrastructure, and not a designed one.
Institutions for building consensus were created to achieve these goals. Consensus was reached about the need for a common protocol (TCP/IP), and a corporate standard, called Hydro Bridge, for desktop and communications applications. Today, there are about 20,000 Bridge users. The Bridge has grown and includes now Hydro's global network as well as a wide range of applications.
Throughout the 90's collaboration and knowledge sharing between divisions as well as outside organizations (like engineering companies in the oil sector) have been increasingly focused. Lotus Notes and the rest of Bridge are seen as important tools supporting this.
Currently Hydro is building a considerable SAP infrastructure. The approach has been bottom-up as decisions are distributed to the divisions. Thus, the infrastructure is emergent rather than deliberately planned and designed. The first SAP applications were installed in France in 1990. SAP was settled as corporate standard in 1994. The decision was based on cost considerations. Having one license for all divisions was cheaper than if the divisions where buying different systems or even buying SAP individually. At that time - and still - SAP applications are seen as separate, individual information systems, and not as an infrastructure. The divisions decide completely on their own how to implement and use SAP.
Hydro Agri Europe (HAE) is the largest division and is the owner of the most ambitious SAP project. HAE includes 19 production sites and in total 72 sites throughout Europe. Since the 80's Hydro has bought several fertilizer companies all over Europe. In line with traditional Hydro management policy, the companies bought were run "hands off". In 1992 the prices were very low bringing the whole division into a crisis. In this situation the division management launched a very ambitious re-engineering project, aiming at integrating the independent national companies into one operational unit.
But what the envisioned changes required was grossly underestimated. Local managers and virtually all the employees did not see the need for integration. They focused on caring for their territories. Thus, no change took place.
In parallel with the integration activities in Europe, Hydro has set up or bought new factories and sales offices outside Europe. Closer cooperation between the European division and other units is considered continuously more important.
When the validation started, five regional project teams were set up to take care of this. The project for the Scandinavian division had more than 100 members.
The validation identified more than 1000 "issues," each of them requiring changes in the system. In total this meant that the design and implementation of the "final" version required much more work than expected.
When the SAP project started, the original re-engineering project was subsumed into it. The original objectives from the re-engineering project were, however, still alive - now expressed as "One single integrated European learning organization."
The focus of the re-engineering work is on establishing "common processes" across the whole organization. When these are in place they are assumed to serve as a platform for closer integration.
The change model in the SAP project was a two stage rocket. First, establishing common work processes supported by a common SAP solution throughout the division. In the second stage the common processes should subsequently serve as a platform for further integration. The common work processes are assumed to make coordination between the different units easy, while some processes might be extracted out of the individual units and located to only one site, taking care of the process for the whole divisions.
A technology like SAP is more than a pure software package to be tailored to specific needs. It also embeds established ways of using it as well as organizing the implementation project. This "formative context" (Ciborra and Lanzara 1994) is inscribed into the larger actor network SAP software is a part of. This network comprises SAP documentation, existing SAP implementation, experience, competence and practices established in the SAP "development community." The SAP implementation has been a guiding tool for selecting activities to address, and in which sequence they should be addressed. It has also been a tool and a medium for representing, "designing" and implementing new work processes. As the process unfolded, SAP made issues appear: should these processes be common across all Europe? Should a shared European function be established taking care of these jobs? Several tasks have been found which could be centralized into one European unit. As the SAP implementation has a complexity almost beyond what can be managed even when the organizational changes are at the minimum, most issues are postponed until the SAP implementation is considered finished. However, for a couple of the issues identified, new integrated services are being implemented. One such service is the Single Distribution Center (SDC).
SDC is a new unit through which all transactions between marketing and production units are channelled. It was established as a legal company, located in Paris, although it was without any staffing. This operation was established since a more well structured way of dealing with internal transactions was needed, but most of all because this unit "logically" was required by SAP to avoid a tremendous amount of transactions which would slow down the system and confuse those involved or responsible. SAP is weak on supporting distribution and logistics. SDC compensate for that weakness. In this way that change is very much designed by SAP. SDC has been in operation since November'97.
We will look a bit closer at three roles SAP has played as change agent in HAE, namely as designer of the Bridge infrastructure; its role in diffusing Lotus Notes and in the integration of HAE.
The implementation of Bridge in HAE turned out to be strongly influenced by SAP. Shortly after the decision to go for SAP, the IT responsible for IT concluded that Hydro itself did not have the resources and competence to take responsibility for the required data processing and operations services. HAE then decided to outsource these functions to a major facilities management global company.
The SAP transaction processing would run on computers physically located in a large processing center in UK. When the decision about outsourcing SAP processing was taken, it was also assumed that it would be an advantage if the same service provider also delivered the required network services connecting the client software on local PC's to the servers. So it was decided to outsource that as well. Moreover, they also believed it would be beneficial to have just one provider responsible for the whole chain from the servers running through the network to the hardware equipment and software applications used locally. A contract was signed covering three areas, called processing, network and (local) site management. This contract meant that the design and operation of the Bridge network was handed over to the service provider, as was the responsibility for installation and support of all elements of Bridge locally (PC's operating system, desktop applications, the Notes infrastructure and applications, Internet software and access, etc.).
So far the outsourcing has been a mixed blessing. The network and processing services are fine, but site management (i.e. local support) is problematic. The major problems seem to be related to the fact that the actual global service provider has organized its business in independent national subsidiaries, and is not able to carry out the required coordination across national borders. In addition, some problems are related to the fact that the site management contract specifies that users should call the help desk in UK when they need support. The threshold for doing this is quite high for large user groups not speaking English, although the help desk should have people speaking all major European languages. When getting in contact with the help desk, problem solving is experienced to be much more difficult than when getting assistance from local support personnel. In this way SAP has made the support of Bridge far more complex than desired.
Notes has been widely used by virtually all SAP projects in Hydro, and SAP projects have been the first users of Notes in may divisions. In that way SAP has been an important agent for making Notes widespread. The initiatives for using Notes have been taken by IT personnel familiar with the technology and optimistic about its potential contributions to Hydro's overall productivity and efficiency. As all SAP projects are large and involve numbers of different user groups, knowledge about and practical experience with the technology become widely spread. SAP projects seem to be the most intensive users of Notes, and accordingly SAP one of the most important actor in making Notes diffuse in Hydro.
SAP has been the most important shared activity involving people from most parts of the division. Through the project people all around Europe have become acquainted with each other, learning about each others' ways of working and doing business - "best practices" are identified and tried transferred to other locations. Through this process the different units get ideas about how to improve their own work far beyond what is addressed by the SAP project and they discover new areas where cooperation and integration would be beneficial. Collaboration on other issues has been initiated - and also supported by Notes applications.
When the SAP system got installed, even more actors appeared on the arena. An important one has been the provider to whom the computing services were outsourced. Central servers, local PC's and the networks entered the scene as SAP's underlying platform. And as the users started adopting SAP into their working practices, these practices also started to play an active role in the project. These practices included other tools and systems. To make SAP work smoothly, all these had to be aligned somehow. As SAP approached its use environment, it became increasingly embedded into the socio-technical web constituting Hydro Agri Europe.
Two alliances are worth mentioning here. First, an alliance between the user groups and SAP. The user groups were to specify local requirements. These included identifying the needs for each office. Such specific needs were due to established local practices - which could be changed into common ones. Others, however, were outside Hydro's control. These include differences in national legislation concerning accounting, taxes, environmental issues, different transport systems in different nations/regions (railway, ships, trucks, river boats, etc.). In addition there were differences in business cultures and market structures in different nations or regions. These local aspects must be accounted for in the design. And in this process locals played a key role. They took control over the design process, and also turned SAP into an ally helping them getting control over the overall change process. The early alliance between SAP and division management was broken. This made the change process slower just as the locals initially wanted. Through this process the SAP solution was customized for each individual site, it changed from one shared, universal solution into one variant for each site. These variants had much in common and they were linked together. The SAP solution had changed from one coherent common system to a complex, heterogeneous infrastructure.
To enable smooth integration of SAP and better utilization of resources, shared processing centres are needed, as well as a shared infrastructure of development and maintenance resources. The lack of such an infrastructure has been acknowledged as a problem since most SAP applications development has been provided by consultants, being hired for a project and leaving when it is finished.
Some divisions are developing Notes interfaces to all their applications - including SAP - for infrequent users. Data from SAP applications are extracted and made available through the Web based Intranet, data are exchanged between SAP applications and applications such as spreadsheet (1-2-3) and other Bridge applications. Some SAP applications are also integrated with extensions tailored for specific sectors. One such is an accounting module, called IS-OIL, supporting join venture production of oil fields. When different SAP installations are linked together with each other and with SAP extensions like IS-OIL, the process of moving from one version of SAP to the next becomes hard. Those responsible for the different parts will continuously wait for each other in order to align versions. Moving from one version to another is in addition very expensive and comprehensive. These problems are also acknowledged in the SAP literature (Bancroft et al. 1998).
As this complex SAP infrastructure is emerging SAP becomes increasingly harder to control, i.e. a more independent actor. Which role this actor will play is hard to predict. One role, however, is becoming visible. It is becoming hard to change; it may turn into a powerful actor resisting all organisational change. And to integrate HAE into one unit as envisioned requires radical change beyond what is supported by the current SAP solution. The future challenges are already perceived: "We have done things difficult for ourselves. We have customized it too much". The customization, however, seems to have been the price to pay to enrol local users and managers into the project, and to counter to the objections that SAP was a significant step back in functionality compared to existing local systems.
The difficulties in changing SAP installations are experienced by all divisions having reached this stage. At Hydro Agri North America, after two years of use, the users finally understand the technology and are becoming able to see how it might be used to improve their work. However, when proposing changes the response is that the SAP application is so complex that it costs all too much to change it. Experiences are similar in the oil division: "SAP is like concrete - it's very flexible until it sets. Then there is nothing you can do to change it."
These experiences are all related to isolated SAP installations. As more SAP installations are put in place and integrated into a corporate infrastructure, the individual modules become important actors influencing the future development of the others in unpredictable ways.
The changing roles of the SAP installations are basically due to its emergent infrastructural character. The SAP installations have been seen as ordinary information systems, and to be designed as such. In the beginning of the project, the SAP implementation had a form of a systems design activity. However, this form vanished. The change from system to an emergent infrastructure can be outlined as a four step transformation. First, the set of SAP applications got a flavour of infrastructure due to its big size, the number of units and functions to be supported, and the number of users, managers, and developers involved. The second step was the crumbling of the SAP application as one common universal and system for all units. During the validation and the following implementation process, major customization of the application to different local needs took place. During this customization, the application changed from one universal and common application towards one for every single organizational unit. A large number of overlapping and interconnected applications - a complex heterogeneous infrastructure. The third step was the integration of SAP and the Bridge infrastructure, and through this even with the Internet. Finally, the SAP installation in HAE is becoming integrated with others.
So what? Going deeply into discussions about what kind of design strategies should be derived from an actor-network perspective seeing technology as an actor in general, or even to deal with powerful irreversible infrastructures is beyond the scope of this paper. However, one can make a few comments on how to deal with infrastructures and their irreversible installed base. A twofold strategy could be possible: on the one hand it is important to fight against the power of the installed base by building an infrastructure in a way that makes it possible to avoid being trapped into it. This means making it as flexible as possible. Flexibility can be obtained through general strategies like modularization and simplicity. In the context of infrastructures this means that one should develop independent systems for smaller units and define simple interfaces between them, rather than one common universal system which includes all functions needed by anybody. When modularizing infrastructures to make them flexible, gateways are key tools (David and Bunn 1988, Hanseth and Monteiro 1998).
The other part of the proposal is somewhat the opposite. Make the installed base your ally by designing the new infrastructure in a way that build upon the installed base as it is, rather than establishing a new one. The development and diffusion of the Web demonstrates the success of this strategy in the way the Web protocol (HTTP) and its data format (HTML) are designed to build upon the Internet's basic protocol (TCP/IP) and its format for multimedia information (MIME).
Bancroft, N.H., Seip, H. and Sprengel, A. Implementing SAP R/3 How to introduce a large system into a large organization, Manning, Greenwich, 1998.
Broadbent, M. and Weill, P. Management by maxim: how business and IT managers can create IT infrastructures, Sloan Management Review, Spring, 1997:77- 92.
Broadbent, M., Weill, P. and St. Clair, D. The role of IT infrastructure in business process redesign, CISR WP278 Sloan School of Management, May, 1995.
Callon, M. Techno-economic networks and irreversibility. In Law J., editor, A sociology of monsters. Essays on power, technology and domination, pages 132- 161. Routledge, 1991.
Ciborra, C.U. and Lanzara, G.F. Formative contexts and information technology, Journal of Accounting, Management and Information technology, 4, 1994.
Dahlbom, B. and Janlert, L. E. Computer Future, Mimeo, Department of Informatics, University of Gøteborg, 1996.
David, P.A. and Bunn, J.A. The economics of gateways technologies, Information Economics and Policy, 3,1988.
Grindley, P. Standards, Strategy and Policy Costs, Oxford University Press, 1995.
Hanseth, O. Information Technology as Infrastructure, Ph.D. Thesis, University of Gøteborg, 1996.
Hanseth, O. and E. Monteiro. Changing irreversible networks. In: Proc. ECIS `98, 1998
Hanseth, O., and E. Monteiro. Inscribing behavior in information infrastructure standards. Accounting, Management and Information Technologies, Vol. 7, No. 4, 1997, pp. 183-211
Hanseth, O., Monteiro, E. and Hatling, M. Developing information infrastructure standards: the tension between standardization and flexibility, Science Technology and Human Values, Vol. 21 No. 4, Fall 1996, 407-426.
Hughes, T.P. The evolution of large technical systems. In Bijker, W.E., Hughes, T.P., and Pinch, T. The social construction of technological systems, pages 51- 82. MIT Press, 1987.
Introna, L. Information, Management and Power, MacMillan, 1997.
Latour, B. Science in action. Open University Press, 1987.
Latour, B. The Prince for machines as well as machinations. In B. Elliott (ed.). Technology and Social Change, pp. 20-43, Edinburgh University Press, 1988.
Latour, B. Technology is society made durable. In J. Law, editor, A sociology of monsters. Essays on power, technology and domination, pages 103-131. Routledge, 1991.
Ngwenyama, Ojelanki, K. "Computerizing Dynamic Distributed Work Environments: Groupware and Emergent Organizational Processes." Forthcoming, MIS Quarterly.
Weill, P., Broadbent, M. and St. Clair, D IT value and the role of IT infrastructure, in J. Luftman (ed.) op.cit. 1996.