Technology as traitor: Emergent SAP infrastructure in a global organization
This paper discusses IT infrastructure development and use in the European fertilizer division of Norsk Hydro. The main element of the infrastructure discussed is a new SAP based solution for this division. However, this solution is not an isolated artifact. Its important aspects are emerging as it is becoming an integrated part of a larger infrastructure.
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.
This paper presents and discusses globalization and IT infrastructure development and use in Norsk Hydro, and in particular the European fertilizer division, called Hydro Agri Europe (HAE). The main element of the infrastructure discussed is a new SAP based solution for this division. However, this solution is not an isolated artifact. Its important aspects are emerging as it is becoming an integrated part of a larger corporate infrastructure which again is linked up with other infrastructures (in other corporations, the Internet, etc.)
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.
Norsk Hydro (NH) is a diversified Norwegian company, founded in 1905. Since 1972 its income has grown from 1 to 96 billion NOK. Besides its original fertilizers business, it produces light metals, oil and gas. The business divisions have enjoyed a high level of autonomy. Independent IT strategies and solutions have been the common practice. Since the late 80's the main goals of corporate IT have been: unified solutions to avoid duplication of efforts among the divisions, infrastructure standards, and sharing competence in systems development.
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 re-engineering started, IT management soon reached the conclusion that the division could not be integrated on the basis of an heterogeneous collection of systems used throughout the division. Every company had its own portfolio of applications. Their basic infrastructure in terms of computers, operating systems, data base management systems, communication networks were delivered from different vendors. Virtual any available technology was in use somewhere. In January'94 HAE launched a new IT strategy project, announcing that the whole division should go for an ERP package, and that this package should be SAP. Based on this package, one set of applications should be common for all units. In August 1994 this conclusion was turned into a decision by top division management. The SAP project started in early 1995, and was planned to be finished by mid ´99. The project was split into three phases: developing and implementing a pilot, validation of the pilot and developing the "final" version and finally implementing that version in the whole division.
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 original re-engineering project was intended to bring about radical change fast. In reality, the organization remained the same. The SAP project, on the other hand, was initially assumed to support the new re-engineered organization. Although the SAP project has been ambitious and permanently close to collapse, it has worked as a vehicle for organizational change. The organization is indeed changing - much slower than what top management believed when the re-engineering started, but much faster than before the SAP project was launched.
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.
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.
To make the SAP project succeed people from all sites had to be involved to provide the project with the required knowledge about how tasks were performed and business was conducted at different sites. For a project of this size and distributed nature, smooth communication is mandatory. Notes applications have been used as e-mail system, project document archives, and discussion data bases. As such, Notes has been a crucial infrastructure making possible the required cooperation between all those involved all over Europe.
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.
When the re-engineering project started, the different units inside the division were all unknown to each other. Tight integration means close collaboration. Close and efficient collaboration requires that those involved are parts of the same community, knowing each other well and having a shared background, culture and identity. Establishing such a shared "platform" takes time and can only happen through collaboration.
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.
Having illustrated how SAP is playing different roles as an actor, it remains to be understood how its agency is played out together with other actors, as one unit in a larger network - as a member of a larger community. In this community, each member acts individually. The effects are not caused by SAP only. They are the result of actions involving others - a network of aligned actors, or a number of actors having joined forces in alliances. As in political theory, actor network theory considers power as being related to the ability to align other actors to your own interests, i.e. making them your allies. For any actor, non-human (i.e. technological) allies are equally important as humans (Latour 1988, Introna 1997).
Actors in the "SAP community" are designers, users, and managers. In the early phase of the re-engineering project, the managers were key actors. IT managers were important in making the SAP decision. As the SAP project evolved, lots of actors entered the stage. First project managers, then consultants were hired as designers and programmers. Later on users and local managers were involved in the four regional projects taking care of specifying local requirements, than the local implementation of the SAP system. These regional projects involved a significant number of people.
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.
During the evolving SAP implementation, alliances were built and changed as new actors were enrolled. In the early part of the project, SAP was a close and important ally of top management to get the change process moving. And SAP was a powerful actor to make this happen.
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.
SAP applications installed in different divisions were considered isolated and independent of each other. Recently SAP applications are linked together and hence emerging as corporate infrastructure. The Technology&Project division (HTP) is building most of Hydro's installations (mostly plants and oil platforms). When doing so, they are buying the equipment and materials needed. This has so far been done by means of the procurement systems of each division. To make these tasks easier, HTP is now developing their own SAP based procurement system. This system will be integrated with the procurement systems in all other divisions, many of these are SAP applications. Further, a corporate Human Resource system is under development, as is a shared module supporting plant maintenance.
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.
A SAP installation in a global organization easily becomes a large infrastructure. It is an infrastructure 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. In one word, it becomes everybody's enemy by resisting all organizational change.
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).
The authors wish to thank Norsk Hydro, and in particular, Jan Christiansen for generously giving us access to all information we needed, Claudio Ciborra for establishing the InfraGlobe project (http://internet.informatics.gu.se) and giving us constructive criticism, and finally the KTK program at the University of Oslo for financial support.
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.