Planning for 'Drift'?: Implementation Process of Enterprise Resource ...

1 downloads 0 Views 262KB Size Report
This paper reports the findings of a large-scale case study of implementing Enterprise Resource Planning Systems. (ERP) in a long-established multinational ...
Planning for ‘drift’?: Implementation process of enterprise resource planning systems Joe Nandhakumar School of Management University of Bath, Bath BA2 7AY, UK. Tel. +44 1225 323469 Fax. +44 1225 323902 email: [email protected]

Matti Rossi, Jari Talvinen Helsinki School of Economics, P.O. Box 1210, FIN-00101 Helsinki, Finland, email: {mrossi|jari.talvinen}@hkkk.fi

Abstract

change and the change process is a rational process. This view of change seems to assume that organizations are in a stable position before change initiatives, and after the change, strive to return to a stable state. For example, traditional change models [6] indicate that organizations go through three stages: organization plan for change (“unfreezing”), implement the change (“change”) and gain stability as soon as possible (“refreezing”). Many authors [7, 8], criticize that the traditional perspective of change and management of change is becoming less appropriate in the current turbulent, flexible and uncertain environment. Orlikowski & Hofman [9] argue that technology-related change is unpredictable as current technologies such as Internet-based systems and groupware are more adoptable by end users than the previous systems, allowing them to customize and shape existing features and create new applications. They argue that change is not an event to be managed during a given period of time but an ongoing process. Orlikowski & Hofman [9] therefore claim that it is infeasible to predefine technology-related changes to be installed and predict their organizational implications. The rest of paper is structured as follows. The next section provides a discussion on the theoretical basis for our investigation and improvisational model of change. This is then followed by a case description of technologyrelated change process in a large multinational organization. The organization has streamlined its operations through a major business process redesign initiative and introduced an ERP system. Our findings are discussed in the final section along with implications for theory and practice.

This paper reports the findings of a large-scale case study of implementing Enterprise Resource Planning Systems (ERP) in a long-established multinational company within the telecommunication sector. The company has recently streamlined its operations through an ambitious business process redesign initiative and introduced an ERP system. The study examines the process of change enacted during the implementation of the ERP system over time. The findings indicate that much of the changes emerged as the project team sought to improvise technological features and changes to the context of use to overcome embedded constraints in the existing system, organizational context and in the ERP system itself. The team also took advantage of evolving capabilities and emerging opportunities to continuously enact changes as an ongoing process of project life. The paper argues that the process of technology-related change may be seen as a form of a ‘drift’ involving a series of purposeful actions with un-planned outcomes. 1

Introduction

Information technology-related changes in organizations have always been a central issue to information systems researchers. Managing such change has become increasingly important with rapidly emerging social, economical and technological conditions. As emerging information technologies such as Enterprise Resource Planning Systems (ERP) and Internet-based Information Systems are becoming widespread, such technologies are often seen as enabling complex changes such as global systems integrations and virtual team working (e.g. [1, 2]). Technology-related changes evolve as designers’ and users’ experience with such technologies and are often unpredictable [3, 4]. Much of the literature on change seems to assume that organizational change is triggered by a deliberate initiative by managers in response to exploit opportunities and to improve performance [5]. In such a perspective managers become the primary source of organizational

2

Implementing SAP/ERP system in practice is often seen as a major initiative involving the creation of massive sets of interconnections among business processes and data flows to ensure accessibility of information, which in turn requires extensive organizational change [10-12]. Many authors, such as [13] provide useful frameworks for studying ERP

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

Theoretical foundations

implementations. Research on ERP systems ranges from abstractions of the systems and feature frameworks [14]to implementation studies that attempt to find success factors for ERP projects (e.g. see [12]. The findings of these studies mostly confirm that ERP is just another IS implementation project. There is however a lack of large scale case studies, which is noted by the survey of Esteves & Pastor [15]. One could say that a few of the early studies try to address this issue, but they do not yet have long enough perspective [16, 17]. To address the limitations of IS implementation studies in investigating ERP Boudreau & Robey [18] argue that researchers should use theories and frameworks of organizational change as ‘lenses’ to investigate ERP and to understand the complex change process. They identify three dimensions of process theories that could be used to explain the technology-based change process: theories on form of change; motor of change; and content of change. Boudreau & Robey claim that these dimensions would be useful in guiding research on IT-related organizational change [18]. In this study we investigate the process of technologyrelated change enacted during the implementation of the ERP system. By drawing on Giddens’ [19] structuration theory, Orlikowski [8] proposes that change is inherent in day-to-day practice and is inseparable from ongoing situated actions of organizational members. Orlikowski [8] claims that the organizational change process is an ongoing improvisation enacted by organizational members attempting to make sense of and act in response to their knowledge about the context. Organizations are therefore constituted by human agency and thus exist in their ‘action’ [19]. Every action taken by organizational members, therefore, has the potential to change existing properties, the organizations or to reinforce them. As intentional beings, organizational members plan, develop and implement IT systems and monitor to see whether these perform as intended. Organizational members then become involved in an active strategy in response to the inability of technology to perform as intended, which involves accommodation of revised goals and intention as well as revision to technology and social structure [20]. Such emerging interaction between human agency and technology and other structural constrains may be seen as “drifting” [3]. Change could therefore emerge out of organizational members’ actions and interactions involving accommodation to and experimenting with day-to-day events, limitations, expectations, opportunities, and also action in response to unintended consequences from their activities. When the IT system being implemented is drawn on in day-to-day practices, the technology properties become constituted by designers and users as particular rules and resources. Their daily practices are however shaped by the previous

technology properties they have enacted in the past with the construction and use of previous IT systems. The consequences of organizational members’ action with respect to altering or reinforcing the structural properties however may not always be as intended. Drawing on Mintzberg’s earlier work on deliberate and emergent strategy [21], Orlikowski & Hofman [9], identify three types of changes: anticipated, emergent and opportunity-based. Anticipated changes are planned changes that occur as intended. Emergent changes are unanticipated and arise spontaneously from local innovation. Opportunity-based changes are changes implemented deliberately in response to unexpected opportunities, and are not anticipated in advance. Although implementation of IT may lead to anticipation of changes, there is no fixed sequence in which these changes could manifest themselves. The improvisational model therefore seems to view technology-related change management as an ongoing improvisation, identifying three types of changes, and thereby enabling organizations to take advantage of evolving capabilities, emerging practices and unanticipated outcomes associated with implementing and using new IT [9]. In this paper we draw on the improvisational model and structurational perspective [19] as a theoretical ‘lens’ in our analysis. The careful use of these concepts as sensitizing or orienting devices in an empirical study provided a valuable means of ordering data and modes of explanation. 3

The research study was carried out in a large multinational company (EURMOBIL - a pseudonym), which went through a major re-organization of its operations in the late nineties. The company changed its order fulfillment and logistics operations with the aid of a standardized enterprise wide information system (SAP in this case). The study mainly focused on order-fulfillment project as part of a total Change program. The research approach adopted in this study is qualitative [22] involving a collection of detailed, qualitative data on the implementation process of ERP in a specific organizational context. The study specifically focused on business-to-business logistics and sales process. 3.1.1

Data collection and analysis

The main phase of data collection involved intensive participation in the project from its initiation in late 1997 to mid-1999. During 1998 - 1999 one of the researchers worked in EURMOBIL as a project manager for ERP implementation. The researcher was fully involved in the project, being given charge of the order-fulfillment part of the project. The researcher reported directly to the

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

Research method

logistics manager of the company and to the manager responsible for the entire change program. The researcher had access to the first-hand empirical data: meeting minutes; project status reports; workshop presentations; documentation on benchmarking, training manuals, project handbook; business blueprints; and detailed work documents. Several follow-up visits were carried out until 2002 to interview organizational members. The analysis involved a critical examination of large amount of qualitative data. All documents and other empirical data were carefully examined to identify statements and actions that reflected similar views and meanings with respect to change process. 4

Case description

EURMOBIL (a pseudonym) is a large, longestablished multinational company in the telecommunication sector providing high technology products, such as mobile and traditional fixed line switches, mobile base stations, Private Branch Exchanges (PBX) and terminals for fixed line and mobile networks. The company has more than 50,000 employees in over 100 countries. The company operates on all continents and has its headquarters in Europe. EURMOBIL has four major product segments: mobile and fixed line network operations, enterprise solutions and consumer products. Telecommunications switches, both mobile and fixed line, developed for the telecom network operators are engineer-to-order type products, which typically involve extensive customization for the clients. Their sales and implementation cycles range typically from 6 months to three years. Each switch is composed of components built in several plants and by up to hundred sub-contractors. Each switch is custom engineered according to local standards, capacities and so on. Each station is also assembled in a EURMOBIL facility to test whether all of the parts fit together and the system works before deploying it to the customer. In mobile network business high volume comes from mobile base stations. Mobile base stations are also very much of “high-tech” products, however they are highly standardized and can be deployed as “plug-in” enhancements into networks, where the basic infrastructure (e.g. more standardized mobile switch) is in place. The delivery of base stations grew very rapidly

throughout the nineties and the logistics involved constituted a major problem for the company. Mobile phones are mass market products, which are sold to end users through retail channels and they have a very short life-span. Traditionally EURMOBIL handled the sourcing and storage of raw materials and semifinished goods and individual suppliers (there were several hundreds of them) delivered the goods directly to individual plants. Similarly, each national organization was largely independent and had autonomy to procure goods in response to customer orders. This worked well locally, but there was no balancing of the load across borders and divisions. With the boom in the telecom industry and tightening competition, however the management of EURMOBIL saw that there was a need for a new global vision and standardized operations across the globe. During 1997, EURMOBIL began streamlining the logistics and customer response processes and standardized the processes across divisional and national borders, largely in response to convergence of the telecom and IT industries and the rapidly growing volume of EURMOBIL’s product shipments. The enterprise resource planning (ERP) solution was designated to replace a number of legacy systems that were used in various locations and tied together with custom built bridges. It was hoped that this would give the company a much better view of its inventory and delivery levels on a global basis. Another reason for this was to prevent fragmented ERP implementations by each national organization that was seen as very expensive for the company (there were numerous ERP projects going on in different countries and divisions). It was expected that all of these separate installations would be replaced by a common SAP ERP platform. Also each project had different objectives, performance measures and local solutions to problems, which were common to the entire organization. This initiative represented a tremendous change for the company which had traditionally operated so that each national organization and even individual factories had greater freedom to decide how to run the local operation. The new model underlying ERP was in sharp contrast with this, because it was based on a common platform, which would implement globally standardized processes. The whole implementation was seen as a major change program, which would have repercussions throughout the whole organization.

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

The project team responsible for ERP implementation was organized into several functional groups, a technical group and an implementation pilot group. In addition there were executives and management teams (see figure 1 below) who were responsible for the overall coordination of the project. The functional groups addressed the business processes of Human Relations (HR), Finance, Consumer Supply Chain and Business-toBusiness Supply Chain. The technical support group was formed from EURMOBIL’s SAP Competence Centre. The competence centre was in charge of technicalities and rolling out new installations, as well as training, of the organization to use SAP. Top level sponsorship for the change program was provided by senior company executives who had sought

EURMOBIL headquarters, fixed line networks HQ and mobile networks HQ. This was seen as a neutral ground for all parties involved. It also ensured that all the parties had to travel to the location, which was both positive and negative. To ensure the commitment and the buy in of local operations the project management did a lot of internal selling. We will focus here on the organization of the businessto-business logistics project. The project team was assembled from more than hundred EURMOBIL employees hand picked from all over the world. Almost a hundred external consults were assigned to the project at its peak. Two separate consulting firms were involved. The two firms worked with the fixed line networks and mobile networks divisions, respectively.

LCC & CS Executive team

CS Management

Consumer goods

Define, Design & Build Teams

HR

Legacy system interfaces

Pilot Implementation management

B-to-b fulfilment

SAP Competence Center

Figure 1 Overall organization of the change program to promote the project as a major initiative for the company’s success. For example the CEO claimed, “This is one of the most critical projects for our future success and I expect you to get personally involved to ensure that we, through co-operation, reach a common company approach”. To evade criticism that this project is not just a “headquarters monkey’s” operation removed from the actual practices, the project offices were deliberately positioned in the middle of a triangle formed by the

The original idea of the project was to change all of the fulfillment processes into one standardized model. However, for this to happen, there was a need for a common company account list and shared standardized product catalogues, which were the responsibility of a separate sub-project. It was seen that this would take too much time for solving the mid-term problems of rapidly growing shipments and their handling. This led to the overall long term project model and vision, which is set out in the next section. From the

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

above figure we can see that the project was functionally divided according to SAP module division. The process side of the matrix was defined by three separate subprojects: the Y2K project handled year 2000 country specific solutions, LCC (Logistics Control Centre) and CS (corporate solution) development projects to provide short-term, mid-term and long-term solutions for the global business model and its implementation.

4.1 Inception EURMOBIL employed an outside consulting group who carefully investigated various alternative supply chain organization principles. They spent nine months

logistic centre based model using SAP. In essence this led to starting the LCC project, which was supposed to model the reference processed for the latter phases.

4.2 Planning The program was launched in January 1998 by “a number of initiatives aimed at a more efficient company, which joined forces to reach company's vision and strategic objectives” by developing new, improved business & administrative processes and system tools, using SAP R/3 as the enabling software, and providing the mechanism to support implementation globally. The choice of ERP package was therefore fixed and it was not

CS Program Management

B-to-b program manager

B-to-b program Council

B-to-b program office

Product Management

Sales & Marketing

Sourcing & Supply

Projects & Implement.

Customer Services

Project managers - Y2K - LCC - CS - Systems & Process Integration - Change Management & Communication

Figure 2 Organization of the business-to-business fulfillment project looking at implemented solutions in other high-tech industries, such as computer manufacturing. Especially the build to order model of Dell and their supply chain optimization was carefully studied. Subsequently, EURMOBIL was given a very good overview of the technical solutions of several case companies. As discussed earlier it was decided that there would be only one logistic model for the entire company and this would be defined as the final product of the CS project. However, in practice it was decided to reuse one specific plant’s model of fulfillment as a starting point. This U.S. plant had already a working local implementation of a

an issue. The work started with definitions of new fulfillment processes. The process designs were developed using Intellicorp’s Live Model process design tool, and were based on structures and planning approaches of SAP’s ASAP [23] implementation methodology. These tools were common and not proprietary to any specific SAP consulting partner. The model chosen was vendor managed inventory, with a logistics provider responsible for managing the operation. The initial plan was to build a central logistics distribution center and route everything through this hub.

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

Also all of the outgoing shipments would be going through this central logistics hub. This model was very well suited for the complex building and fulfillment process of the switching stations. Later this base would be enhanced to support also HR, maintenance and global accounting practices.

4.3 Planned implementation of LCC

4.4 Y2K project The Y2K project had to be developed in parallel with LCC, as it was badly needed by a few country organizations, which would have been unable to continue their operation past the turn of the millennium. This meant that some of the resources would be away from the main project to help this project. On the other hand this gave a possibility to test the roll-out of ERP on a country by country basis. The problem with this project was that it introduced a ‘drift’ from the global model into very

Functionality

When the blueprints had been frozen, they were used as a plan for the implementation of the model in SAP R/3. This would form the basis for all implementations across 120 countries. Before these could be rolled out there would be a need to develop a technical infrastructure and support for running the system. This was designed so that there would be three service centers, one located in the

process maps for each business process using the process modeling tools. They also started configuring the SAP R/3 using these process maps.

HR Maintenance

Base processes Y2K – Aug 98

LCC

LCC

Base processes

Base processes

LCC - 4Q98

CS – 2Q99

Time

Figure 3 Planned project timeline Nordic region, one in North America and one in Asia, to give a 24 hour support capability and balance the load. There was also a need to develop a comprehensive training and deployment toolkit. Even before these could be developed there had to be serious enhancements of the SAP system (these would eventually lead to the development of the telecom industry solution for SAP itself). The program and thus each project had the authority to ensure that common business processes are instituted across all current business units and areas. The change program started to build a common blueprint for the processes. These were developed based on current best practices of the firm. In practice this means that the project teams and the consulting firms developed detailed

country specific local solutions. This would later turn out to be the basis for resistance of the global model.

4.5 Changed course According to the project handbook: “During the project, any task resulting in the addition of new deliverables, the deletion of planned deliverables, the expansion or contraction of planned tasks, or the changing of the project schedule due to availability of user personnel, will be recorded and managed through the formal scope management procedure.” During the course of the workshops the exact scope of the business-to-business fulfillment project underwent

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

major changes. The project deliverables whilst trying to reflect the final scope suffered as a result of the changes. The definition of certain concepts within EURMOBIL that were still in the process of being defined also affected the depth and extent of some of the deliverables. One example was the debate concerning the exact nature of the logistics hub and how it should be represented within SAP. There continued to be, throughout the program meetings, a lack of clarity regarding the likely customers of LCC and therefore exact business requirements. Some six months into the project several changes took place. First, the company went through turmoil, its revenue collapsed and the CEO was replaced. The old CEO had been the sponsor of the program and this caused subsequent problems for the process. The new CEO came from the mobile network division. At the same time the CIO was demoted from the company management team into a line manager reporting to infrastructure managers. This meant a decrease for the status and importance of the whole project. Furthermore, most of the new management team members came from the very profitable mobile network division. They saw the LCC program as mostly helping the somewhat less successful fixed line network division. This caused a change in focus from the LCC model to CS model. One major change was that the idea of one logistic hub was abandoned and it was replaced with a new model. The implementation was based on a logistic hub adjacent to each of the manufacturing sites and further into a model, where fulfillment processes would not need any logistics hubs, but rather the external logistics provider would deploy the stations directly to their final locations, where they would be assembled. This model was a good fit for the large scale deliveries of “pluggable” base stations by the mobile network division. This meant that most of the process descriptions and blueprints developed up to this point had to be abandoned and the modeling needed to start from scratch again. Also all of the configuration work done so far had to be abandoned. There were internal concerns as well, the model that was chosen, was a better fit for the mobile base station order fulfillment than the traditional switching station software developers. This was quite natural, as the models studied were from make-to-order production instead of engineer-to-order. To make things worse, the process models were largely adapted based on the streamlined processes of the mobile network makers.

4.6 Epilogue At present 100 out of 140 national companies of EURMOBIL are using SAP or are in the process of rolling it out. Interestingly, out of these one third uses the Y2K solution, one fifth has rolled out the LCC solution and the rest is working on a continuation of the CS

project. The HR module has been implemented and is in use in many countries. The development of the global model continues in new projects, which also adds features needed by financial planning. This project “continues to fit these modules of SAP better with the EURMOBIL way of working”. In general EURMOBIL is still trying to get away from the country specific solutions and move towards the global model. However, this happens slowly and seems to work best when accompanied by major changes in SAP R/3 versions. 5

The above case study illustrates that EURMOBIL had everything in place to transform itself into a new “model company”: resources, knowledge, skills, plans/blueprints and tools. In contrast to the traditional perspective of planned changes, when the project was launched many of the changes realized by EURMOBIL were not planned a priori. In fact the whole project ‘blueprint’ was changed at least once during its course. The changes were not implemented with the initial deployment of ERP. Some changes were deliberate and intended - others were emergent and unanticipated. The project team members were actively involved in accommodating revised goals and amending technological and organizational features in response to the inability of the systems to perform as intended. For example, in the late 1990s, it was planned to create a unified process for all divisions in different countries. The project team therefore focused on standardized processes, ledgers and product coding. Subsequently, it was found that they could not proceed with the global ‘unifying model’ as systems in many national organizations were not year 2000 compliant. They therefore had to improvise temporary solutions (Y2K using SAP) to enable many national organizations to continue operation over the turn of the millennium. The Y2K project therefore emerged as the project team sought to enact technology-related changes to embedded constraints in the existing system. This new project also gave an opportunity for testing the system on a country-by-country basis. The findings also indicate that organizational members continuously took advantage of evolving capabilities, emerging opportunities and unanticipated outcomes associated with the implementation and technologyrelated change which was an ongoing process of organizational life. For example, during the ERP implementation the project team felt that the task of simultaneously changing the ‘global vision’ of the company and rapidly rolling out standardized ERP systems was overly ambitious. They decided that a fulfillment model already in place in one of the US plants was using a system that could be used as a template for

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

Analysis & Discussion

LCC for switching stations, which was then used instead of the blue print for new implementation. They also realized that they could reuse much of the design effort that went into abandoned LCC projects for new CS project and speed up the new project and reclaim the investment from the LCC project. Changes around the ERP system at EURMOBIL were not solely enacted by the project team members. Much of the technology-related changes emerged out of evolving socio-cultural conditions and organizational members’ actions at various levels of organization. For example, events at the top management level, such as the appointment of the new CEO from the highly profitable mobile network division (for which division LCC was less significant) and the reduced responsibility of the CIO who championed LCC undermined the importance of the LCC project in the company and led to cancellation of the LCC project. In fact the project brought together a large number of organizational members, who worked over ten years at EURMOBIL in similar positions, the first time to confront their reluctance to proposed changes (in some cases these people met for the first time) and also enabled new opportunities for co-operation. The new system therefore brought new spatio-temporal frameworks of interaction in which various viewpoints conflicted and co-

Existing IT systems (in-construction and use)

Previous organizational properties (norms, rules & resources)

view of its inventory and delivery levels on a global basis. These intentions however might not transcend into known outcomes. The trajectory of the ERP project was grounded in micro-level changes that the organizational members enacted over time. 6

Implications

The paper illustrated the process of technology-related change was enacted during the implementation of the ERP system. The findings indicated that much of the changes emerged as the project team sought to improvise technological features and changes to the context of use to overcome embedded constraints in the existing organizational arrangements. The team also took advantage of evolving technological capabilities and emerging opportunities to continuously make the fit between the organization and the system better. Technology-related change was an ongoing process of organizational life. There were also changes that emerged out of evolving structural conditions and ongoing actions at various levels of the organizational context. The paper argues that the process of technology-related change may be seen as a form of ‘drift’ involving a series of purposeful actions with intended and unintended

New/modified IT systems (in-construction and use)

New/ reproduced organizational properties (norms, rules & resources)

‘drift’ Planned (intended) and Emergent (unintended) Changes Purposeful actions (planned and unplanned) of designers and users

Purposeful actions (planned and unplanned) of designers and users

Figure 4 Technology-related change as drift operated in a ‘power game’ to produce technological drift. The findings indicate that the process of technologyrelated change at EURMOBIL may be seen as a form of ‘drift’ where there was purposeful action such as implementing ERP in response to the need for a better

outcomes. While the improvisational model [9] and ‘situated change perspective’ [8] indicate that technologyrelated change is an ongoing process of organizational life, we have sought to provide further insights into 'enaction' of technology systems themselves (see Figure

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

4). The concept of drift indicates that the change process involves purposeful action involving serendipity and chance. The drift emerged out of organizational members planned and unplanned actions in response to both previous technology and organizational properties they have enacted in the past. The technology-related change process is not strictly a process from one stage to another as the traditional literature on change suggests. Our conceptualization that technology-related change is a form of drift seems to indicate that the technologyrelated change may not be considered as a discrete event which can be managed within a given period of time. The planning stage may not be able to predefine all technology-related changes to be installed and foresee their organizational implications. Also the emergence of new streams that need to be pursued should be taken into account in the planning phase. Management of such projects would therefore be problematic. How do we avoid the appearance of sideprojects, such as the Y2K project which diverts much effort from the main project? If we were to take advantage of evolving capabilities and opportunities then we would have to face numerous possibilities that the project could evolve into. This presents us with several managerial challenges: How do we ensure that the team effort goes into the main project rather than on internal selling and small side projects? Does this actually mean that a large infrastructure project is essentially just one way of organizing the whole MIS function? What policy guidance can be given for handling external events that totally change the course of the project? How much slack should there be in the project to handle possible emergent issues and opportunities? The global unification of processes is a very complex project even for a company like EURMOBIL that has more than a hundred year’s tradition of multinational operations. Any approach to managing such a project should take into account the unpredictability of technology-related changes and drift, and the need for customization and improvisation to accommodate revised goals in response to embedded systems constraints and the need to take advantage of evolving capabilities and opportunities.

[3] C. U. Ciborra, "Drifting: from control to drift," in Planet Internet, K. Braa, C. Sorensen, and B. Dahlbom, Eds. Lund: Studentlitteratur, 2000.

References

[17] S. G. Hirt and E. B. Swanson, "Adopting SAP at Siemens Power Corporation," Journal of Information Technology, vol. 14, pp. 243 - 251, 1999.

[1] T. H. Davenport, "Putting the Enterprise Into The Enterprise System," Harvard Business Review, vol. July/ August, pp. 121-131, 1998. [2] T. Isakowitz, M. Bieber, and F. Vitali, "Web Information Systems," Communications of the ACM, vol. 41, pp. 78-80, 1998.

[4] C. U. Ciborra and Associates, From control to drift: the dynamics of corporate information infrastructures. Oxford: Oxford University Press, 2000. [5] D. Robey, L. Smith, and L. Vijaysarathy, "Perceptions of Conflict and Success in Information Systems Development Projects," Journal of Management Information Systems, vol. 10, pp. 123-139, 1993. [6] K. Lewin, Field Theory in Social Science. New York: Harper & Row, 1951. [7] A. M. Pettigrew, The awakening Giant. Oxford: Blackwell, 1985. [8] W. J. Orlikowski, "Improvising Organizational Transformation Over Time: A Situated Change Perspective," Information Systems Research, vol. 7, pp. 63 - 92, 1996. [9] W. J. Orlikowski and J. D. Hofman, "An improvisational model for change management: The case of groupware technologies," Sloan Management Review, pp. 11-21, 1997. [10] M. Al-Mashari, "Constructs of Process Change Management in ERP Context: A Focus on SAP R/3," presented at Americas Conference on Information Systems, Long Beach, California, 2000. [11] S. Kelly, C. P. Holland, and B. Light, "Enterprise Resource Planning: A Business Approach To Systems Development," presented at Americas Conference on Information Systems, Milwaukee, 1999. [12] C. P. Holland and B. Light, "A Critical Success Factors Model For ERP Implementation," IEEE Software, vol. May/ June, pp. 30-36, 1999. [13] C. V. Brown and I. Vessey, "ERP Implementation Approaches: Toward a Contingency Framework," presented at International Conference on Information Systems (ICIS), Charlotte, North Carolina, 1999. [14] K. Kumar and J. v. Hillegersberg, "ERP Experience and Evolution," Communications of the ACM, vol. 43, pp. 23-26, 2000. [15] J. Esteves and J. Pastor, "Enterprise Resource Planning Systems Research: An Annotated Bibliography," Communications of the AIS, vol. 7, pp. 1-52, 2001. [16] J. W. Ross, "Dow Corning Corporation: Business Processes And Information Technology," Journal of Information Technology, vol. 14, pp. 253 - 266, 1999.

[18] M.-C. Boudreau and D. Robey, "Organizational Transition To Enterprise Resource Planning Systems: Theoretical Choices For Process Research," presented at International Conference on Information Systems (ICIS), 1999.

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

[19] A. Giddens, The Constitution of Society. Cambridge: Polity Press, 1984. [20] A. Pickering, The Mangle of Practice: Time, Agency and Science. Chicago: University of Chicago Press, 1995. [21] H. Mintzberg, "Crafting Strategy," Harvard Business Review, pp. 66-75, 1987. [22] G. Walsham, Interpreting Information Organizations. Chichester: John Wiley, 1993.

Systems

in

[23] H. Brand, SAP R/3 Implementation With ASAP : The Official SAP Guide: Sybex, 1999.

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

Suggest Documents