irene@apertura.ntnu.no eric.monteiro@idi.ntnu.no perms@svt.ntnu.no

Abstract

1. INTRODUCTION

The widespread interest and efforts in establishing enterprise resource planning (ERP) systems in large business organizations is due to their potential re-organizational benefits. More specifically, ERP systems are presented as a response to pressing problems related to the basically functional and hierarchical organizations. As SAP, the world’s leading vendor of ERP systems, argues:

"SAP R/3 overcomes the limitations of traditional hierarchical and function-oriented structures like no other software. [All the functions] are integrated into a workflow of business events and processes across departments and functional areas" (www.sap.com).

Hence, ERP initiatives assume that the functionally segregated organization results in a corresponding segregation and lack of integration between the different information systems in use. As Davenport (1998, p. 123) argues, we "need to understand the problem [ERP systems] are designed to solve: the fragmentation of information in large business organizations". Hence, ERP systems are perceived as a contribution towards a more process-oriented organization (Knights and Willmott, 2000).

For sure, the early enthusiasm for ERP systems has subsided as experiences are gained and reported (Parr, Shanks and Darke, 1999; Hanseth and Braa, 1999; Markus, Tanis and van Fenema, 2000; Markus et al., 2000; Truex and Ngwenyamo, 2000; Westrup and Knight, 2000). Still, there are few in-depth, longitudinal cases that analyze the unfolding, socio-technical dynamics of large-scale ERP projects. This study reports from the largest SAP project in Northern Europe. It describes and analyzes the efforts of the Norwegian based but internationally oriented oil company Statoil of introducing SAP throughout its operations involving more than 15.000 users. The project started in 1996 and is to end in 2001 has a budget of $ 0.5 billion.

Our aim is to analyze one element of this effort, namely the intentions and consequences in terms of centralization and decentralization. More specifically, we study how this traditional dichotomy gets recast by large-scale ERP projects. We examine how an emphasis on the formation and circulation of ‘best practice’ and uniform, standardized solutions foster a form of organizational centralization while, on the other hand, explicitly aiming at decentralization as motivated by current trends in contemporary organization theory towards empowerment and amplified by the heritage of Scandinavian work life tradition. The issue of centralization/decentralization – closely linked to the tension between imposed structure and local flexibility (Bowker and Star 1999) – is at the heart of ambitious, multi-site ERP efforts like that in Statoil and account for their particularly problematic implementation (Markus, Tanis and van Fenema, 2000, p. 43). As Davenport (1998, p. 128) phrases the problem: "determining what should be common throughout the organization and what should be allowed to vary".

The deeply ambiguous manner in which ERP systems simultaneously promote forms of centralization and decentralization can only be addressed through critical, empirically open studies. A characteristic feature of the SAP project in Statoil is the way it from the outset not only had centralizing ambitions but was injected also with intentions of decentralization, empowerment and local adjustment – but gradually got transformed into something else. Why, then, does this take place despite good intentions, management backing and generous financial resources?

Drawing on the case of Statoil, we focus on the following set of issues relevant to scholars, practitioners, management and designers: what are the conditions for successfully circulating ‘best practice’; in which manner does the organization of the project shape the outcome; what are viable, more piecemeal strategies for establishing ERP systems in large business organizations; what are the conditions for preserving a participative, user-oriented shaping of ERP systems drawing on (the espoused version of) Scandinavian work life tradition?

The remainder of the paper is structured as follows. Section 2 contains the theoretical background, basically a reviewing of the background and forms of organizational centralization and decentralization including the role of IT. An outline of the case is presented in section 3 by presenting the company, the ERP project and key actors. Section 4 elaborates on the research design and methodological reflections. Section 5 analyzes instances of the transformations that unfolded as the project’s intentions have been implemented in practice. We analyze why intentions about centralization/decentralization did (or did not) transform into practice, i.e. tracing the initial motivation as well as the unfolding dynamics. Section 6 offers a few concluding remarks outlining the more general lessons to be drawn from our study.

2. CENTRALIZATION, DECENTRALIZATION AND THE ROLE OF IT

The foundation for a centralized organization was laid out in the works of Taylor, Fayol (1949) and Weber through a focus on specialization, standardization and modularization. A particular manifestation of the insights of centralization is the bureaucracy. The way work and responsibility is compartmentalized, the strict adoption of formal decision making and the vertical integration resulting from the command line structure amount to a centralized organization.

The classic bureaucracy has been under increasing pressure and critique (Clegg, 1990). Still, even in more horizontal organizations there may remain elements of centralization. A particularly relevant instance is that of 'best practice'. This is the standardization and circulation of work practices. The organization is accordingly centralized in the sense that the actual shaping of local work practices takes place at the center.

A vivid example of this is found in Leidner’s (1993, p. 46) ethnographic study of McDonalds. Intrinsically a highly decentralized enterprise, the success of McDonald has been its unprecedented "centralized planning, centrally designed training programs, centrally approved and supervised suppliers".

The arguments for empowerment and decentralization are intrinsically ambiguous. On the one hand, it is based in issues of quality of work life in general and individual motivation in particular. On the other hand, it is based on more pragmatic concerns about efficiency, flexibility and quality of services (Heller et al., 1998; Sørensen, 1998; Greenberg 1975). Even if these two arguments are possible to separate for analytic purposes, the thrust of the argument for empowerment and decentralization hinges on their concerted effect.

Building on the human relation tradition, socio-technical systems theory elaborated the insights about the needs and motivation of individuals and groups (Trist and Bamforth, 1951; Trist, 1981). In Norway, this tradition formed the background of the cooperation of exploring new ways of organizing between the unions and the employers' federation (in Norwegian: "samarbeidsforsøkene"). A series of projects were launched implementing self-organizing teams, including the role of the former middle managers and flatter organizational hierarchies. Beyond the immediate outcomes of these projects, they paved the road for a new legislation and work agreements securing employees' participation in decision processes.

The assessment of these experiences has not been unambiguous (Sørensen, 1998). Still, Elden (1979) emphasizes how the projects collapsed as the external research team left. Elden draws from this the more general lesson that principles of decentralization, participation and self-organization cannot be implemented top-down. There has to be a correspondence between the contents of the changes and the form in which they are enacted. A truly and sustainable decentralized, participatory organization, Elden argues, needs to take on board these same principles in the organization development project itself as well. This resonances well with the argument of Argyris and Schön (1996) as they emphasize theories in use, not only the espoused theories.

The debate on how IT does – or is expected to – have centralizing/ decentralizing consequences has a long history in IS research (for an overview, consult e.g. Bloomfields and Coombs, 1992; Orlikowski, 1988, 1992). In a condensed, hence crude, form, we may identify one strand of work that attribute a decisive role to the technological architecture. This typically translates into expecting centralizing effects stemming from a technological architecture characterized by a few main-frames serving a community of connected terminals (70s – early 80s) while the diffusion of networks, work-stations and PCs (80s – 90s) in an analogous way generate expectations of decentralizing effects.

These projections, which draw heavily on a technological determinist mode of thinking, have since been seriously challenged. More elaborate accounts argue that IT has few intrinsic qualities of centralizing/decentralizing nature; outcomes are rather shaped by a range of organizational, political and historical conditions which more often than not tend to reinforce

Traditionally and predominantly, the literature on ERP systems and experience has had a normative bias (see e.g. Bancroft 1996). Still, with the accumulating experiences with ERP implementations, there is a growing attention to the wide range of organizational aspects: the level of standardization (Davenport 1998; Markus et al. 2000), the alignment with existing routines and organizational structures (Hanseth and Braa 1999), the harmonization required in connection with mergers and acquisitions (Truex and Ngwenyamo 2000) or external consultants (Westrup and Knight 2000). One should accordingly be careful in prescribing outcomes in terms of centralization/decentralization up front. Still, ERP systems represent a particularly interesting type of information systems as they to an unprecedented extent mesh elements that (in determinist thinking) simultaneously inscribe both centralizing and decentralizing effects. ERP systems are characterized exactly by their deeply ambiguous promotion of local, cross-functional cooperation and control – but superimposed under one, uniform "process" model aimed at capturing "best practice". This implies that the real challenge, as Davenport (1998, p. 128) notes, hinges on where to draw the boundary.

At both a theoretical and a practical level, this involves the pragmatic, messy socio-technical negotiation between local needs and flexibility and the need to extended control across the whole, "global" organization (Bowker and Star, 1999; Ciborra 2000; Monteiro and Hepsø, 2000; Rolland and Monteiro, 2000). In order to advance our understanding of how the centralization/ decentralization potential inscribed in ERP systems play out in practice, it is necessary to trace how these efforts feed into and forge alliances with ongoing organizational and technical initiatives (Law, 1992; Latour, 1987; Orlikowski, 1992; Monteiro, 2000)

3. STATOIL: HISTORICAL BACKGROUND

Statoil is a fully integrated oil company, operating production fields for oil and gas, transport systems, terminals and refineries. The main part of business is based on activities on the Norwegian continental shelf, but the company is also engaged in rapidly expanding activities in other parts of the world.

Fluctuating oil prices and increased competition during the last years has made the company focus strongly on improved business performance. Throughout the nineties, several improvement projects has been launched, aiming at different sectors and parts of the activities, primarily under the umbrella of "continuous improvement".

The BRA/SAP project was conceived of as an integrated IT and organization development effort, where the ERP-system should be a tool for improving the administrative work processes. The motivation was closely linked to the Business Process Reengineering ideology, as originally stated by Hammer & Champy (1993). The central BRA teams in Statoil made it clear from the beginning that the possible gains from the project only could be fully realized if the company succeeded in changing the organizational mode of working.

SAP was introduced in Statoil as part of an ambitious program for improving the administrative performance of the organization, aimed at contributing to the positioning of Statoil as a leading player in the international energy business. The program, abbreviated BRA (in Norwegian: Better and faster administration) was launched in 1996 and finishes by the end of 2001. The improvement goal is stated as a 50 % improvement in administrative procedures, with a yearly net gain of 1,4-1,8 billions NOK (approx. 200 million USD).

A number of organizational actors are involved in our study. We present them briefly. The SAP project in Statoil has been organized by establishing a BRA organization, consisting of up to 300 people at the most. BRA has been delegated the responsibility by corporate management (KL) for the success of the project. BRA was to have overall responsibility, but relied on site-specific project teams in the ongoing implementation. BRA initially wanted these site-specific implementation projects to report back to BRA, but has since been forced to accept that they would primarily report through their ordinary line organization to the different operational units. Each unit is responsible for one site and is organized within the umbrella of operational management (DRO). Hence, BRA has struggled with legitimizing its own role, mandate and position within the existing organizational structures. DRO perceives themselves as the Statoil. DRO is where the surplus is generated, it represents the core business and tradition of Statoil. Hence, DRO has traditionally exercised a considerable influence in Statoil.

Unions have an influential role in Statoil. The level of unionization in Statoil is high, well above the Norwegian average. The three operational units that have been most involved in our study are the sites Troll, Heidrun and Åsgard. Troll was the first implementation on an offshore installation in operation. DRO considered this implementation as their pilot. The other sites paid attention to the work in Troll, knowing they would be doing this later and knowing that the solutions chosen by Troll probably would become their solutions as well due to the standardization. Heidrun and Åsgard were the next BRA projects in DRO. They were co-located and wanted to coordinate their implementation by establishing only one common BRA-project. The point of departure of these two installations differed a lot. Heidrun was organized in a traditional hierarchy, but had developed and realized a new concept for operations based on the idea of increased efficiency and security through cooperation between disciplines, multi skilled workers, reduced administration and improved work processes. These were ideas that to a great extent were parallel with those of BRA, except of the integrated teams as organizational structure. Åsgard, the newest installation, had established their organization based on the idea of integrated teams from the beginning. They perceived BRA as merely the implementation of SAP with only modest repercussions in roles and work processes.

Alongside and largely independent of the BRA project, several other, high-profiled projects have come and gone. These projects have to some extent competed among each other for attention and recognition. Only for a restricted period of time have they, BRA included, enjoyed full attention within the organization. The most relevant of these has been IBD, "the best industrial operator". Their mandate was aimed at "How can Statoil construct and operate installations to become the best industrial operator?" The core element of their recommendation was integrated teams as stated in their final report from:

"Focus on the tasks, concise objectives, decentralizing and development of multi-disciplinary teams working together with other divisions of the company through networks."

Hence, IBD started prior to BRA and was parallel to BRA for about one year. DRO considered IBD as "their" change program.

4. METHODOLOGICAL CONSIDERATIONS

This is an interpretative, longitudinal case-study conducted during autumn 1997 - autumn 2000 (Klein and Myers, 1999; Walsham, 1993). It is born out of a long-term relationship with the company developed by the second, but more substantially, the third author. This relationship made it possible for the first author to gain access to the ERP project. Our relationship with Statoil is based on a commitment to focus on problem areas (like the present ERP project) that are perceived as relevant and interesting for Statoil. Still, our role rest crucially on our ability to provide a more detailed and critical perspective than, say, consultants (who abound in Statoil) typically represent. Hence, our role is constantly negotiated and challenged.

Empirically, this study draws upon several sources: participative observations; semi- and unstructured interviews; paper-based as well as electronic documentation.

A total of 120 different meetings have been observed over the last three years. These meetings include central project meetings, local project meetings at the different sites as well as management meetings and divisional meetings.

A total of 40 semi- and unstructured interviews have been conducted. Interviews typically lasted 1 - 1 1/2 hours. Notes were taken but they were only some of them are taped and transcribed as this was seen to hamper the interviewing.

Statoil, operating within a sector with a strong tradition for highly codified quality regimes, keeps an extensive record of paper-based and electronic information. We have had access to reports, memos, slide presentations and email discussions.

In addition, we have over the last three years engaged in numerous informal discussions, conversations over coffee and in the corridors of Statoil. The first author has spent 160 days at Statoil over these last three years. The second author, as part of a different but related project, spent 2 days a week over a period of four months in 1998 in Statoil. These informal discussions form a backdrop for our interpretation of the primary sources of data.

5. ANALYZING CENTRALIZATION AND DECENTRALIZATION

In analyzing how the issues of centralization and decentralization got recast when played out on the organizational stage, we present excerpts of the dynamics in the form of four dramas. These four are generated from a simple heuristic vehicle tracing whether (de)centralization did or did not have (de)centralizing outcomes. The underlying motivation is that this may function as an analytical vehicle in tracing how the inscribed potential for both centralization and decentralization get played out. In other words, it analyzes the organizational and technical conditions that ERP initiatives need to align with in order to accomplish changes. By themselves, ERP systems achieve little.

1. Accomplishing centralization - in a few pockets

The BRA project was founded and motivated by strong claims and high ambitions regarding centralization and standardization. The expected benefits of BRA, it was repeatedly argued, would ensue exactly from achieving "improvement and increased efficiency of administrative processes by coordination an integration" (communication package for the introduction of BRA, 1997).

In terms of IT, this translated immediately into the perceived need for a centrally defined, standardized set of administrative tools (Monteiro and Hepsø, 2000). The high ambition about centralization was made painfully clear. One of the managers of BRA in 1997 made it clear that absolutely no decentralization or locally adopted solution would be tolerated:

"We are going to standardize both the product we implement and the process of implementation. Those wanting special adoptions need to participate in the development and include their demands in the common solutions. If by chance we have to do any changes later on, all units have to implement these changes. We will not accept any special solutions for any reason." (emphasis added)

As the project got going, this extreme level of standardization did, quite reasonably (Bowker and Star 1999), got somewhat down-played. Both the process and the result have differed between the sites, but still in January 2000, our informants in BRA insist on keeping up their intentions of centralization and standardization. Even after these modifications, the BRA project is committed to a high degree of centrally defined, standardized solutions.

One of the areas where this ambition has been realized most extensively is probably within accounting and economy reporting. In the earlier system, the opportunity to tailor-make their own reports were extensive. As a result, all operational units had their own way of doing reports. The lack of standardization between the units made it difficult to compare the results from one unit with another. In SAP, the economy system is one module integrated with all the other administrative modules. The parameters in use are standardized between the units. The arguments for this standardization are "identical activity is to be managed identically" and the idea of "best practice". This, the argument goes, is the most rational and cost effective way of doing things, increases management control and allows the results to be compared across the sites (Ciborra, 2000).

The principal reason why the high degree of standardization was actually achieved within this functional area is both human and technical. SAP provides extensive possibilities for standardizing the key performance indicators - during configuration. All data registered in SAP are transferred to the economy module. This forms the basis for the calculation of the key figures. The IS is hierarchically organized starting at the company level, going to the divisional level of core areas, down to business assets. Prior to SAP, the economists fought for an integrated platform (called the "evolving baseline") based on an existing economy system. When the SAP decision was taken - and the battle lost - the economists adjusted to this and worked for the best possible solution. They elected several of the most senior staff to participate with the development of the SAP system. For the economists, the information systems are closely interwoven with their routine work. Hence, the SAP implementation was given high priority. The economists accordingly became the most active lobbyists for BRA and SAP in the subsequent site implementations at Heidrun and Åsgard.

An interesting site is the operational unit Troll. Here, BRA’s ambitions have to an unprecedented extent been realized. This implementation has accordingly been regarded (by BRA) as a success. The principal reason for this – which came as a surprise rather than as a result of careful deliberations – was the way BRA happened to be able to forge an alliance with an already existing initiative within Troll (Latour 1987; Law 1992).

Troll had decided to implement cross-functional teams, a key ingredient in the BRA project, as part of their own development strategy. They started this process independently and prior to BRA. Troll organized their organizational development process with broad participation with those involved, allowing the operators to establish an understanding of the new organizational model. This enrolled the actors into the project, thus avoiding resistance. In an early attempt to take control, the central BRA project members arranged a meeting with the management in Troll to "clear things up". This, however, did not change Troll's strategy.

Formally, the BRA project and Troll’s internal project were never integrated, having separate project leaders, organizations and budgets. Still, the fact that they coincided in time was crucial in realizing BRA’s ambition of a combined IT and organizational change project. In a sense, Troll’s organizational development project enabled BRA to extend beyond merely an IT project as it provided the necessary ally for BRA to be realized (Law, 1992; Monteiro, 2000).

2. Failing aspirations of centralization: meeting with local opposition

The most important sense in which BRA’s ambition about centralized, standardized solutions failed, is the proliferation of site-specific specializations as discussed above. BRA had seriously underestimated the problems of making the traditionally fairly autonomous and self-confident sites accept a standardized solution, resulting in a shift of influence from BRA centrally to the different, local and site-specific BRA projects that evolved without tight coordination (Bowker and Star, 1999).

This shift of influence from the central BRA project – initially an extremely high-profiled, consistently backed by top management and generously funded – to the sites is instructive to study more closely as it embeds a deeper understanding of Statoil.

In short, BRA’s problem may be attributed to its difficulties of legitimating its own role. Statoil, growing from 1 (!) to 15.000 employees in less than 30 years, is a company where informal networks are particularly important. Status is symbolically gestured by your "number": employees are assigned numbers sequentially as they join the company. Seniority has always had a snob appeal in the company and people are quite aware of their position in the sequence.

BRA, launched as a radically different mode of operating, mainly attracted younger and junior members that were intrigued by the concepts. One of the BRA project members recalls the atmosphere of the initial stages in 1996:

"We were many newcomers. Many of us wanted to do something new and leave some traces. Many of us had little experience from the company. This worked both ways. We lacked the internal network, but we had no history that restrained new ideas."

Relatively few senior people joined, clearly indicating BRA’s place in the informal hierarchy. The massive import of external consultants did not boost the reputation of BRA as a lot of people where "shaking their heads" when talking about them.

Local autonomy at the sites has a long-standing tradition in Statoil. A typical expression of it that we heard in many variants goes like this:

"central, top-down decisions in this company are only considered as advice or suggestions for action"

There are also formal reasons that feed into this local autonomy. As oil production sites are always joint ventures with a collection of companies, the responsibility of sites cannot by to Statoil alone, it necessarily has to be to the group of companies operating the site. Hence, the different sites need to develop a certain degree of local autonomy.

An instance of the difficulty of standardization across sites is the so-called work-center. The work-center is a SAP application handling the resources, the people available for different kind of work. It was an essential element of BRA’s ambition of reorganizing work around cross-functional teams. BRA attempted to inscribe this principle into the work-center application by removing all options to specify resources related to subject or professional background (Law, 1992). Troll, already committed to similar ideas, accepted BRA’s inscription but both Heidrun and Åsgard fiercely objected. Åsgard argued that for some types of work it was absolutely essential to be able to specify the resources required.

Heidrun, on the other side, objected to the use of IT to enforce integrated teams as organizational structure. SAP in itself, of course, did not inscribe any special organizational form. BRA decreased the flexibility of the technical solutions to make the chosen standard of organizational structure the only possible. Heidrun had not had enough time to discuss their future way of organizing. Implementing a system that would enforce a disputed structure would be a provocation to the employees. Heidrun could not accept this reduced flexibility at that time. Åsgard and Heidrun had different interests and different arguments for resisting on the solution Troll had implemented. But the interest of making a new work-center solution was common, and the expectations to this new solution were identical. Heidrun and Åsgard forged alliances around this issue with the other sites to mobilize against BRA. They wanted to get acceptance of implementing a different solution than Troll. BRA finally accepted the arguments after a hard fight. To make the standardization go on, there was a possibility of making Troll implement the new solution as well. Troll produced heavy arguments against: it would cost too much both of directly work and of motivation for another change so close upon their implementation (Bowker and Star, 1999; Rolland and Monteiro, 2000). The result was a reduced level of standardization, were Troll has one work-center solution, and Heidrun and Åsgard another one.

3. Failing decentralization: the logic of tangible results

The ambition of BRA was to enroll and recruit members from the different local operational units. This was perceived as important to adhere to a Scandinavian work life tradition regarding user participating advocating and mandating participation (Sørensen, 1998). Statoil has a tradition for democratic processes and close co-operation between the management and the unions. This, seemingly, does not harmonize with the ambitions for standardization outlined above. The intention of BRA was to have the local users highly involved in the development and implementation within the various site-specific, local projects. As explained earlier, BRA never managed to engage senior people from the sites. But as the BRA project organization mushroomed – involving around 300 people at its peak – the initial ambitions of local grounding gradually faded as new, enthusiastic members were recruited. There was a feeling of excitement, a melting pot of appealing ideas. As one of the pioneers in BRA explained:

"We were quite a bunch. This project was full of possibilities. We were eager to use the opportunities. Lots of consultants and lots of newcomers with plenty of ideas and energy to make Statoil a new and exciting place to work."

This implied, over time, that more and more of the decisions were taken within the central BRA project organization (Ciborra, 2000). As the project proceeded, this resulted, not surprisingly, in a critique from the sites that BRA lacked practical experience and relied mostly on abstract concepts. One man knowing the practical life from DRO told us:

"So far is what we have heard from BRA only on a theoretical and aggregated level. The arrows they have painted, the general expressions and ideas seem reasonable enough, but when it comes to a practical level, they do not know what they are talking about. It is easy to tell that several of their principals do not make sense in practical life. "

This unintended centralization of BRA, failing to link up with the local sites properly, was reinforced by the fact that the majority of those recruited into BRA had a technical IT background (Rolland and Monteiro, 2000). The relative lack of organizational insights underscored the problems of a lacking local support. As the milestones approached, the practical logic of the project forced it to focus on the SAP implementation aspects of BRA. The BRA project, being the largest SAP project in Northern Europe, attracted diligent attention from the media and was desperate to make sure that they had some tangible results to demonstrate their success. And in this sense, they did succeed as they managed to "go live" with the first SAP site implementation in 1997 without major, technical problems on schedule, spawning happy celebration. The pressure to deliver made BRA very sensitive to questions about the degree to which this had entailed major reorganization of the way work was done.

As the project developed, the central BRA organization took on a life of its own. They developed into a highly hierarchical organization, nothing near what they espoused. As one of the member puts it:

"I left BRA when it became 6 levels in their hierarchy"

To make the implementation of integrated teams as organizational structure easier and faster the management wanted to stimulate the process. In the spring of 1998, a committee consisting of both managers and unions decided that every organizational unit organized as integrated teams would have a higher salary class, a so-called grade H. Grade H was meant to be an incentive of gaining integrated teams. In spite of the good intentions of motivation, grade H became the aim instead of being the mean for integrated teams. As a local manager expressed it:

"We can not avoid being into this, if we would maintain the traditional organization and therefore have less salary to offer than the other units, we will probably loose the competition of the best people and get problems with recruitment."

For the opponents of the new organization, the important question became how to satisfy the system to make them qualify the local organizational practice for grade H. The offshore workers on Heidrun asked for several months why they should be organized in integrated teams. They said they never got any answers. The impression they had was that no one had a good answer to this question either. Integrated team was then understood as something decided by the top management, that they had to implement without any positive consequences for them. The principles endorsed at Heidrun is aimed at breaking down the organizational barriers between units in an move to improve efficiency and flexibility (Clegg, 1990. The arguments for changing this concept to a new one have been difficult to find. The concept was clearly intended as a move towards empowerment and decentralization. Still, it is largely perceived by the shop-floor workers as an expression for centralization simply because it imposed in a top-down manner.

Hence, BRA suffered from similar problems as the early work life projects in Scandinavia in the 70s and 80s (see section 3) with a discrepancy between what is preached and what is practiced (Elden, 1979; Argyris and Schön, 1996). Similarly, even though the ambition of a more "holistic", "process oriented" organization was a characteristic feature of BRA, the way training programs for SAP were organized reproduced the opposite, namely functional separation. Hence, the economist, operators and site managers all had distinct training sessions.

4. Accomplishing decentralization: a new management regime

Due to external turbulence, a new management regime was established during the spring and summer of 1999. Both the board and the CEO was flushed out in this upheaval which was spawned by poorly run project causing budgets estimates to burst severely. A number of well established "truths" were re-questioned by the new management, including BRA's commitment to an extreme level of standardization. The indications from these changes - mediated by the expectations sensed by our informants - demonstrate that the new regime is more skeptical to standardization and centralization than the former one. Hence, the local opposition to an exaggerated level of standardization we have outlined above has recently found top-management support.

One new, big change programme has been launched. This programme is about core area organization, implying a geographical division where the core areas are largely self-supported with all competence needed independent of the centralized staff. This programme, discussed at the central meeting between management and the unions (the BU meeting) in March of 2000, clearly shifts power and decisions down and out in the direction of the local installations.

So far, it is not easy to track results of empowerment and decentralization related to BRA. Decentralizing is about development of skill and knowledge, about learning, acceptance and internalization of new ideas and new ways of doing things. This necessarily requires time before results can be expected.

The implementation design has been top-down so far in BRA. Decentralization, Elden (1979) argues, requires a more evolutionary process. It is still time to do something as all sites are still working on the improvement of the new solutions. At Heidrun, some of those helping the operators during the start-up weeks on SAP are still on the installation to increase the competence of the operators on the use of SAP and the new roles related to the new work-processes. They have not yet implemented integrated teams, but are discussing the positive and negative consequences to make sure they chose the best organizational structure from the actual situation on this site. Through these discussions about the actual situation, the different concepts and the expected consequences, local understanding of the possibilities is increasing. Hence, the long-term implications with regards to decentralization is less obvious than the meager, short-term ones.

6. CONCLUDING REMARKS

The still ongoing BRA project demonstrates how abstract notions for a new way of working need more than heavy top-management support and generous funding. Statoil is not unique in having developed highly entrenched and institutionalized ways of organizing and performing work (Bloomfields et al., 1997; Ciborra, 2000). This simply will not yield without a considerable resistance. The way BRA set out to enforce centralized solutions challenged the identity of the operational sites as responsible, competent actors.

Even principles that could be seen to emphasize local autonomy, as cross-functional teams, were perceived as centralizing, simply because they were enforced top-down. This strongly reinforces the lesson that what is preached needs to be followed by in practice (Argyris and Schön 1996), that local autonomy cannot be implemented top-down (Elden 1979).

In practice, this implies that large-scale organizational development projects like BRA cannot be too rigid. The need to involve the actors presupposes a more evolutionary approach that makes participation and local grounding viable.

The BRA project demonstrates how the practical logic of delivering tangible outputs - invariably and despite the best of intentions when praising slogans like "IT and organization = synergy" – transforms it into a predominantly IT-development project. The organizational changes, less tangible in nature, are accordingly too lofty to guarantee the project’s reputation as a "success". The Norwegian mass media reported regularly from BRA from early 1997; it has always been highly profiled. This media pressure did raise the stakes considerable prior to the first implementation in the summer of 1997. And they succeeded - but only in the sense of "going live" with SAP on schedule.

The BRA-project in its early phase was ambiguous, both because of the organization development targets and the technical possibilities of SAP. The BRA project could present both a centralized and de-centralized policy in its interaction with the Statoil organization. As the project gained momentum, this space shrunk. As a consequence of the need for a set of standard SAP applications, a number of efforts had to be standardized and centralized. When the main centralization efforts had been undertaken and a number of Statoil SAP applications had been developed, these new applications had to be implemented. The cost of centralization and standardization is always systems that are not tailored to meet local or decentralized requirements. Consequently, to meet these decentralized requirements, BRA had to open up the strict standardization policy. For SAP to prosper in Statoil, further decentralization is required. This process of changing peoples attitudes, skills and actions can not be handled with BPR- thinking. It is a long-term process of collective reflection and knowledge creation in relation to the work processes that the BRA project was supposed to deliver.