Implementation of Enterprise Resource Planning System ...
Upcoming SlideShare
Loading in...5
×
 

Implementation of Enterprise Resource Planning System ...

on

  • 1,642 views

 

Statistics

Views

Total Views
1,642
Views on SlideShare
1,642
Embed Views
0

Actions

Likes
0
Downloads
46
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Implementation of Enterprise Resource Planning System ... Implementation of Enterprise Resource Planning System ... Document Transcript

  • Implementation of Enterprise Resource Planning System - theoretical research approach and empirical evaluation in two cases Abstract During the last decade, implementation of an Enterprise Resource Planning (ERP) system has become one of the major challenges for many enterprises. ERP systems are large software packages, which are meant to cover most, if not all, of the information and information processing needs of an enterprise. Implementation of an ERP system is often a complex and painful process, the effects of which can be great both in good and bad. In this study I (a) create a new tentative research approach to study ERP system implementations, which is based on earlier research and methods. This new tentative research approach is specially designed for implementations of ERP systems and tries to cover the most important aspects of an implementation of ERP system. After creating a new tentative research approach to study ERP system implementations, I (b) use my new tentative research approach to carefully analyse two ERP systems implementation cases. Research method for this paper is a tailored case study. I have chosen two case companies to represent polar types of an implementation. This way I can represent the range of alternatives attached to ERP system implementation process, which I wouldn’t be able to do with a single case study. One of the case companies implemented ERP-systems on the ‘as is’ basis, while other one made a huge effort to tailor it’s ERP system to gain a better fit to company’s processes. Other differences in implementation decisions between the case companies were also noticeable. Both of the case companies used different implementation models and different approaches to implementation process. Yet I was able to find all the elements, at least in some extent, of ERP system implementation presented in my research approach. This supports the validity and appropriateness of new research approach presented in this paper. Keywords: ERP, implementation, research approach
  • 1. INTRODUCTION Common for all information systems development is the search for more efficient and effective use of information and communication technology (ICT). In many cases, this has lead to downsizing and outsourcing the IT function in enterprises (Currie and Selsikas 2001). A major part of IT functions playground has shifted from designing and developing information systems to successful procurement of information systems. This development has transferred responsibility for IT from technical staff to general or line managers (Adler et al. 1992). Changing business environment, tight competition in global markets, the widely spread information networks and business networking are all placing requirements for service capabilities of information systems (Simon 2002). Organizations must be able to integrate their functions and processes and share information fluently without any unnecessary delays to all over the organization and even to outside of organization. In many cases, the answer to these challenges has been implementation of an Enterprises Resource Planning (ERP) system. During the last decade ERP systems implementation has become one of the biggest or perhaps the biggest challenge in enterprises in area of information systems (Akkermans and van Helden 2002). ERP systems are large software packages, which are meant to cover most, if not all, of the information and information processing needs of an enterprise. The larger the system is, more complex and challenging the planning, designing and implementation processes become. ERP systems roots lies in Materials Requirements Planning (MRP) and in Manufacturing Resource Planning (MRP II) systems (Hong and Kim 2002). These systems were used mostly at individual manufacturing facilities and were not integrated to enterprises other information systems (Rajagopal 2002). Today ERP systems are a lot more, than just planning systems and using the term ERP could be looked to be no longer appropriate. Davenport (2000, pp.2) has suggested the term Enterprise System (ES), which would describe better the extent of these systems. However, I find this term troublesome, because the abbreviation ES means Expert Systems in information system literature. I use abbreviation ERPs to represent Enterprise Resource Planning Systems in this research. Objective of this research is to find sound research approach to study implementations of ERPs. For this purpose I have developed a tentative research approach based on earlier models and implementation literature. I have used it to carefully analyse two cases representing polar types of implementation. Findings support that research approach presented in this paper is a valid and appropriate way to study EPR implementations and that it covers the most important parts of implementation project. Also the selected tailored case study as a research method was found to be fruitful way to study implementation projects. 2. RESEARCH OBJECTIVES Many researches dealing with ERPs mention implementation process as the most difficult part of the project (e.g. Davenport 2000, pp.169, Checkland and Holwell 1998). Implementation process of an information system is attached with many great problems and according to some researchers from half to two-thirds of implementation projects fails (Lyytinen and Hirschheim 1987). Information systems implementation processes and problems attached to them are widely studied in literature, but that haven’t affected to success rates of the projects (Sauer et al. 1997, Johnson 1995). On the other hand, it has been said, that reasons for failures lies deep in the relations of organizations, humans, markets and information systems and can only be studied using intensive case methods (Mitev 2000).
  • These viewpoints demonstrate the importance of ERP systems and practical difficulties of implementation projects. Yet there is not much studied information about ERPs implementation projects. From this point of view ERPs implementation project as a subject for research and a case study as a research method are valuable. Objectives of this study are to broaden the knowledge of ERPs implementation processes and different alternatives attached to process. Also a new research approach is created to broaden the previously presented models. Most of the models seem to concentrate to one part of implementation process rather than whole chain of decisions and actions. Purpose of this new model is to provide way to study implementation process all the way from reasons to outcomes and to provide ‘big picture’ to ERPs implementation. To achieve these goals I first create an appropriate research approach and then use this approach to carefully analyse the implementation projects of the case companies. Case descriptions and conclusions provides valuable insights and experiences to ERPs implementation projects and on it’s own behalf of contribute the both theory and practice of ERPs implementation. 3. RESEARCH METHOD Järvinen (2001, pp.10) classify all research methods into two group according to is the research studying the real world or symbol systems which doesn’t have counterpart in the real world. Real world research can further be classified according to is the research studying what kind of real world is or how useful some innovation can be in a real world. What kind of real world is research can further be divided to conceptual-theoretical and to empirical researches. Empirical researches can be divided to theory creating and theory testing researches. My research belongs to theory creating research, if taking notice on what Järvinen (2000) is also saying about theory creating research: ‘Based on observations on a certain part of reality … that part of reality is described’. Eisenhardt (1989) concentrates describing theory creating with case study method. She makes summary of information from previous inductive case studies and represents Pettigrews’s (1988) research, in which one high functioning and one poorly functioning organization was studied. Pettigrew (1988) had selected case companies using theoretical sampling. Theoretical sampling can be used, when researcher wants to replicate study, expand created theory or when researcher wants to fill theoretical categories or to give examples of polar types (Eisenhardt 1989). By representing two polar types of ERPs implementation I can represent larger range of alternatives attached ERPs implementation process. This method enable using intensive case study method to gain comprehensive insight to a research questions, being still able to do some comparison. This way I am also able to challenge the new tentative research approach versatile with minimum amount of cases. I selected two case companies, which represent many ways polar types of ERPs implementation. One of the case companies implemented ERP system on ‘as is’ basis, when other made a huge effort to tailor it’s ERP system to better fit to company’s processes and to broaden the functionality of the package. One used phased rollout approach when other used big-bang approach to implementation (Davenport 2000, pp.173). Cases were selected from different industries to provide variety of point of view to environmental factors. Also other differences were considerable, like the selection of vendor (old vendor vs. new vendor). Interviews were conducted in the spring/summer 2002. Questions were open ended and responses were audio taped. Research incorporated interviews both in the customer
  • organizations as well as in the ERPs provider’s organization. Interviewed persons were four project leaders, one from each organization and two other persons, MASI’s administrative manager who influenced strongly in project and Vice President of Major Blue Company who enlighten the background of the company. Major Blue Company is the provider of Dafo- system delivered to MASI Company and one contract provider of J.D. Edwards One World delivered to Electrolux. By interviewing both parties we can enlarge our view on case and are not limited to one subjective view of the project. This could be looked to be some sort of ‘triangulation’ as ‘the cross-validation achieved when different kinds and sources of data converge and are found to be congruent’ (Kaplan and Duchon 1988). Case descriptions are built up from notes collected and audio tapes recorded during the interviews in customer and supplier organizations as well as from additional material like product brochures and project timetables and thus are interpreted descriptions. Both case descriptions are verified with interviewed parties. 4. ERP SYSTEM IMPLEMENTATION MODEL Definition of ERP system isn’t simple job, many researchers have their own view on system. Klaus et al. (2000) have studied how ERP is defined in literature and revealed the broadness of issue. However I think that Kale’s (2000, pp.13) definition of ERP systems is broad and felicitous: ‘'An Enterprise Resource Planning (ERP) software application package is a suite of pre-engineered, ready-to-implement, integrated application modules, catering to all the business functions of an enterprise and possessing the flexibility for configuring and customizing dynamically the delivered functionality of the package to suite the specific requirements of the enterprise. ERP enables an enterprise to operate as an integrated, enterprise- wide, process-oriented, information-driven, and real-time enterprise.” Implementation of an ERP system is usually big and significant investment costing even over $1 billion in large companies (Davenport 2000, pp.4). In small and medium sized enterprises investments are even more significant when comparing the costs to company’s turnout. In addition implementation process bounds valuable resources, which would be needed running the everyday business. ERP systems can be implemented slowly or quickly, depending on how ambitious the company’s goals are, how pressing any deadlines are, and how well implementation proceeds. A fast implementation can take as few as six months; a slow one can take up to five years or more (Davenport 2000, pp.14). Focus can be mainly in technical or in strategic subjects. Implementation of ERP system and affiliated business change can be handled in many different ways. The major alternatives in implementation are incremental and big-bang approaches, with a phased rollout in the middle. In a phased rollout you can implement either some functionality on a broad scope, or full functionality on a narrow scope (Davenport 2000, pp.174). Models for information system implementation vary. Every vendor has its own model, and large companies have their own practices. Most traditional model is perhaps the waterfall- model. Original model (Royce 1970) included five phases: Analyze, Specify, Design, Build, and Test. Model have been modified, further developed and criticized ever since. However, this model doesn’t suite well for implementation of pre-engineered software packages, as the
  • case is in implementation of an ERP system. Some models specially designed for implementation of ERP systems can be found from literature, but for my opinion, those models doesn’t cover all important parts of ERP systems implementation project, but are rather focusing to some part(s) of it. Some of the models are focusing on buying process (Verville and Halingten 2003), change management (Mandal and Gunasekaran 2003), factors of influence, barriers, facilitators and performance (Rajagopal 2002) or project activities (Al-Mashari and Al-Mudimigh 2003). Umble et al. (2003) suggest thirteen-step selection process and eleven steps for successful implementation process. Shields (2001, p.35) suggest rapid implementation model with 12 major activities in three stages. Markus and Tanis (2000) represents four phases that covers the implementation process from idea adoption to continuous improvement: 1. Project Chartering, 2. The Project, 3. Shakedown and 4. Onward and Upward. One other broad model is from Kwon and Zmud (1987) who say that IT implementation follows six-stages: 1. Initiation, 2. Adoption, 3. Adaptation, 4. Acceptance, 5. Routinization, and 6. Infusion. Even though some of these models are very detailed, their suitability is questionable because all of their stages can’t be found from all implementation projects. Others, on the other hand, cover only a part of implementation processes or are too coarse for detailed report. To be able to carefully analyze an ERP system implementation process to gain big-picture, a new model have to be created. 5. A NEW RESEARCH APPROACH TO IMPLEMENTATION OF ERP SYSTEM According to Järvinen (1980) every discontinuous process has three stages: initiating tasks, process proper, and terminating tasks. If we examine activity before the initiating tasks and after the terminating tasks, we have a five-stage model for a common process. Examining the ERPs implementation project from this point of view and broaden it with other stages or tasks from previous literature we can find eight stages or major functions and two co-stages, which all includes several tasks. A construct including these 8+2 stages is presented in figure 1. All projects start from some initiative. Important thing in initiative is, that it occurs. Initiative originates usually from strategic planning (Motwani et al. 2002), but they can also originate from numerous of other ‘sparkles’, like information systems providers offer, competitors movements, industry movement, improvement project, change in regulations or legislation, or making good use of IT-budget. Many times factors affecting to emergence of initiative are not important in later stages of the project (Teng et al. 1998). After an initiative occurs, evaluation stage follows. This stage can include evaluation of business processes, requirement analysis, evaluation of different alternatives, search for potential system providers, and evaluation of different products. Evaluation of different alternatives is often a complex process, because there are often a limited number of alternatives while trying to satisfy multiple objects that conflict. This problem is further complicated because the inputs required to make the decision involve both quantitative and qualitative data (Erol and Ferrell 2003). Some researchers have constructed methods to assist in evaluation like scoring method (Ptak 2000) and other evaluation procedures (Wei and Wang 2003). Evaluation stage can take from few days to even years, but eventually it is time to make the selection from potential proceeding alternatives. This can also mean project termination or moratorium of project if circumstances are not mature for project to be launched. Decision to proceed or not to proceed with ERPs project is not easy, because in many cases management
  • Figure 1. Business Process Reengineering Exploitation and Initiative Evaluation Selection Modification Training Go-Live Termination Development Conversion of Data Big Bang, Incremental or Phased Rollout Configure Analyze Configure Test Training Analyze Training Test Modification (a) Modification (b)
  • have to carry out multi-criteria selection of hundreds of projects simultaneously (Klapka and Piňos 2002), which are often interdependent of each other (Lee and Kim 2001). If proceeding with project, this stage includes the negotiations for an agreement, in which the offer from competitive bidding (done in evaluation stage) can be focused and timetable fixed. After the agreement is signed, the process proper stage (Järvinen 1980) of the project can start. Until this stage, every project usually proceeds in a linear matter, but from here on, they differ depending on goals and premises. No matter what model is used for implementation, usually the ERPs can’t be installed without some sort of modification. In the literature it has been suggested that the degree of customization depends on size of a company; the bigger the company, more likely to modify (Mabert et al. 2003). Even if the system is not being tailored, even some switches or option has to be selected/unselected. Localizations are also one common task in this stage. Modification stage can proceed in a numerous ways. Shields (2001, pp.35) suggest that modification happens in a loop of analysis-configure-test until desired outcome has reached or time is up. Järvinen (2001, pp.91) suggest that there is at least two alternative ways for modification: ‘We can firstly specify the target state and then try to implement measures to achieve that state or we can in parallel realize both target-seeking and implementation’. I call these alternatives as the stage-model and the parallel-model, from which the later one reminds the model suggested by Shields. I think that even the stage-model can have back coupling or back feeds in a case of problems in some stage. These alternatives are represented in figure 1 as a modification a) and modification b). In the end of the modification stage users are being trained. Training stage is a stage of its own, even if it might occur during the modification stage. This is because the modification concerns the system, and training concerns the users. Education/Training is probably the most widely recognized critical success factor in ERPs implementation (Umble et al. 2003). Training occurs usually just before the ‘go-live’ stage to maximize the effectiveness of training. Go-live stage has it’s own procedures and factors, and is perhaps the most critical stage of implementation when everything is hectic and confusing. Go-live stage is frequently mentioned stage in ERP systems implementation process literature (Shields 2001), but is not studied that much separately. Go-live stage usually contains guarantee period, during which the detected flaws and errors are being fixed. When everything is up and running, customers pays the last payment (depending on contract) and a termination meeting is being hold (or terminating tasks as in Järvinen’s (1980)). In this ‘stage’ it would be worthwhile going through of all that has happened during the project and learn from successes and failures of the project (Scott and Vessey 2000) as well as evaluate outcomes for future implementation projects (Mandal and Gunasekaran 2003). The project team is being pulled down and team members are being relocated or back located. After the project is terminated, the longest stage starts: Exploitation and Development stage. In the end, how well the system is used terminates the benefits gained from the system. Companies have to encourage their employees to use the system to continue to improve (Umble et al. 2003). Development of implemented system means maintenance (see for example Lano and Haughton 1992, and Ng et al. 2002) of the system as well as the further development and broaden the scope and width of the system, like implementation of new modules or introducing it to new users. Above these eight stages two other conditional co-stages exists: Business Process Reengineering and conversion of data. Conversion of data can be easy, if we have previously used centralized database and well defined data structures. Frequently this is not the situation, but the information must be gathered from different locations, like from distinct legacy systems, Access databases, Excel spreadsheets on someone’s desktop computer, or even from
  • manual systems and other ancillary storage areas (Shields 2001, pp.57). When the data has been gathered for many decades, conversion can be a big job and planning it has to be started in time. Conversion stage is conditional, because in some case it might be looked to be unnecessary, if the previous data is not critical or even useful for operations. And sometimes there simply is not any data to convert, for example when establishing new business unit. ERP systems bring their own business processes and the way of work to organization. Groth (1999, pp.304) has even argued that the data structures of information systems bring implicit coordination to organizations. Organization can adopt these so called ‘best practices’ (Swan et al. 1999) or to do a genuine Business Process Reengineering (BPR) effort (Malhotra 1998). According to Davenport (2000, pp.29) most of the benefits of implementation of ERP system can be yielded from more efficient business processes. However, I see this stage conditional, because it is possible to tailor the system to meet the current processes, rather than opposite. This can be justified if, for example, business processes are seen to be superior. Construct developed here suits well in an ERPs implementation project where the big-bang approach is used. To account incremental and phased rollout alternatives, we have to repeat the stages after selection stage and before termination stage as many times as needed. Every sub-project might have their own termination, which can be a precondition for next phase of implementation, but I look that from the entire ERPs implementation point of view, there is only one termination stage, when every module is implemented in all function or business units. However, I admit that this conclusion is questionable. One part of ERP system can already be in the next development stage when just finishing the implementation of the other part of it. Using this construct as a research approach to study ERPs implementation project, I analyze the next two cases. All the eight stages presented here should be found at least in some extend from case companies implementation projects to validate this construct. 6. CASE M.A.S.I. COMPANY M.A.S.I. Company Oy (MASI) is a medium sized company in a fashion industry, which manufactures, designs and contracts out outdoor and youth cloths. MASI is also a largest jeans manufacturer in Nordic Countries. MASI has four business units in Finland and subcontractors in Estonia. MASI is designing and/or manufacturing brands like Basic, Fredrikson, Lee Cooper, Sail & Ski, Tiklas, Very Nice, and some others as well as resellers private labels. Products are sold mainly in Nordic countries, Russia, and Baltic countries. Turnout was 17,5 million euros in 2001 and MASI employed 210 persons. MASI’s history started in 1972 when it’s predecessor Blueman was founded. Blueman made a license-contract with an English Lee Cooper and started manufacturing Lee Cooper jeans. It became rapidly the most popular jeans brand in Finland and company was growing fast, especially because of large export to Soviet Union. Blueman expanded it’s business both by organic growth and by purchasing competitors. In 1988 export to Soviet Union halted and competition in other markets were also very hard. In 1990 Blueman went to bankruptcy and it’s business and brands was acquired by MASI Jeans. Later on MASI Jeans changed it’s name to M.A.S.I. Company. After the recession, MASI has been continually profitable and been able to increase turnout. The rest of Cloth and Fashion industry in Finland hasn’t been as lucky. Industry has frequently new bankruptcies and is almost dying away. In the beginning of 1980’s there was 55 000 jobs in Finland in clothing industry. After the recession in 1995 there was 8 000 jobs left and the number has still been slowly diminished. The costs of labor have been biggest
  • reason for this development. In this kind of environment only the most efficient and innovative companies can survive. Initiative for ERP system project was born already in 1995 when company’s former information system vendor announced terminating the development of system. Old system was highly tailored to fit the needs of the company and was doing it’s job, but technology was old fashioned, user interface was character-based and the system was very closed, which made it hard to develop new e-Business functionality. Evaluation of potential systems started immediately and in the beginning there was five alternatives. Evaluation criterions were functionality, support, further development and reliability of vendor. Very quickly it was discovered, that only two alternatives were considerable, an English Systex and Finnish Dafo. Systex was quite massive and had a lot of functionality for manufacturing, but was not translated in Finnish. Importation of Systex was in the beginning and there was no local support or even earlier implementations. Dafo on the other hand was pretty thin and was mainly targeted to importation and marketing companies and had no functionality for manufacturing. Dafo had already a handful of implementation behind. Selection of the package was a clear decision. Dafo wasn’t perhaps the best possible system, but in those circumstances the only possible one. One supporting factor for the decision is that Dafo has approximately 85% market share in Finnish clothing and fashion industry, and thus is almost an industry standard. An agreement was signed in July 1999 about delivering Dafo system with extensive new functionality and tailoring job. Modification of the system was extensive. The new system didn’t have any functionality for manufacturing, so it had to be developed from scratch. Also many other changes were made to new systems, because MASI wanted to transfer the old systems functionality to new system. Some of the changes MASI made by itself, like a reporting feature that was based on Microsoft Access and parallel database. Training happened in three phases. In first phase personnel was trained to basics of graphical user interface. This training was bought from third party. The actual training to use of Dafo was held by Major Blue, the vendor, in fall 1999. Two instructors hold a training days for each business functions. The most of the new systems was taken into production use in fall 2000 and MASI looked that additional training was needed. MASI’s IT manager hold this training. The new ERP system was so extensively tailored to fit MASI’s existing processes, that Business Process Reengineering wasn’t really needed. Only few things have to be done slightly different in financing, but it can’t be called to a reengineering effort of any kind. Data conversion was started already in 1999 by opening products to new system and information input. Conversion was unproblematic as all the relevant data was found from the old ERP system. MASI had chosen phased rollout alternative for implementation, which was argued by the nature of business. Fashion companies live by the seasons. Preparation for every season starts a year before the season. Some parts of the system MASI was been able to take into use immediately where others were taken into use by incrementally. Because of this phased rollout approach there was many small Go-lives. Pricing was started in the new system already at the end of 1999, but it was considered to belonging to testing. First module used in business operations was calculation of wages in January 2000. Whole system was taken into use in all locations by the spring 2002.
  • Termination of the project was hard to define. System had been taken into use and last payment had been paid. However, termination meeting hadn’t been held, because a lot of work was still to be done. Some of the functionality was still lacking and new projects had already been started. Exploitation of the system is critical success factor for MASI Company. System is continuously being further developed both by Major Blue and MASI. About once a year a new version of the system is being released by Major Blue. Above that MASI has done many new features to the system and even some new modules. The way this has been done is exceptional, because usually the vendors don’t allow any changes to be done to their systems database. Whole implementation process was characterized with communication problems and delays. Timetables were changed numerous of times, but the budget hold. MASI looks that implementation project was barely satisfactory, but it opened new possibilities to develop the company’s organization, processes, and information systems. At the time of interview, a next version of ERP package was being implemented, which was looked to be a huge step forward. 7. CASE ELECTROLUX HOME APPLIANCES FINLAND Electrolux Home Appliances Finland (Electrolux) is a part of Electrolux Group (Electrolux Group) and is responsible for delivering white goods to seven countries: Finland, Russia, Belorussia (White Russia), Estonia, Latvia and Lithuania. Above the white goods, market sector leaded from Finland is responsible also for marketing and delivering casual products and medicine- and hospital-fridges. Company is located in Pakkala and a warehouse is in Pori in Finland. Turnout is roughly 300 million euros. Demand of white goods has remained quite constant in Finland, but the competition has tightened. Big international retailers have entered to markets and are eating the turnover from small players. Even though these retailers are selling products of Electrolux Group, they import the products themselves passing by the local dealer. Demand in Russia has on the other hand varied. In 1998 export halted where the last few years have been time of strong growth. Initiative for ERPs implementation project was the introduction of euro in Finland in the beginning of 2002. IT-manager of Electrolux proposed the project fall 2000. The old system was extensively tailored and was expensive to maintain. Making the system suitable for euro would have required a big shake-up and was estimated to cost as much as the implementation of new ERP system. Objectives of the project were to be able to handle the introduction of euro, lower the maintenance expenses, and to be able to take the advantage of new and forthcoming technology like e-Business systems. Electrolux Group’s recommendation for new system was J.D. Edward’s One World. Electrolux’s old system was J.D. Edward’s World system that was older version with older technology when compared to One World. However, J.D. Edward didn’t have their own agency in Finland but was operating through partners. Electrolux evaluated few other systems besides the One World. Selection of One World was justified with two reasons: One World was Electrolux Group’s recommendation (almost mandatory) and Electrolux had five years experience of J.D. Edwards World system. Selecting other system would have meant building interfaces to over 20 different system of factories, warehouses and reporting and thereby increase in expenses. Agreement was made with Electrolux Groups internal IT department who then acquired the
  • system commissioning. Major Blue participated to project via Electrolux Groups internal IT department and made localizations to the system. The project started in may 2001. Modifications were limited to setting the parameters up and localizations of the system. Old system was heavily tailored and expensive to maintain, and with the new system Electrolux wanted to avoid this situation. Team members worked full days as the timetable was only little more than half a year. Training was hold about two weeks before go-live date just before Christmas. Every group had two to three days training. Even though the system was basically an upgrade from the old one with new technology and same way of work, the change was notable. This was due to extent of tailoring of the old system. Because the system was implemented on ‘as is’ basis the business process reengineering effort was needed. The BPR effort was looked to be modest, any big changes wasn’t required. The system was very flexible and a lot of BPR was avoided by using parameters. Where this wasn’t possible, users have to change their way of work Data conversion was unproblematic, as all the required data was found from the older version of the new system. The One World system was taken into use in all seven target countries at a one time (big-bang approach). Go-live date was 1st of January in 2002. The system itself is located in Stockholm, in Sweden, and it is used mainly with terminal server connection. The old system was also in place and plans had been made in case of failure. The project was finished in March 2002 after the guarantee period. Termination meeting was held and the project was documented. Timetable had hold as well as budget. Also a list of open questions was made. This included some database errors, undelivered reports and some other less important errors. At the time of interview, new system had been in place for five months and a new training period was about to start. Some of the personnel had learned the use of new system very well while others not so well. A new training period was looked to be necessarily to ensure full exploitation of the new system. Implementing the new system on ‘as is’ basis has removed the need for own maintenance and development. However, Electrolux has planned to develop their information systems further and have started some e-Business initiatives. Considering the short timetable for project, Electrolux looks that project succeeded quite well. Biggest problem was seen to be the language differences, as the project covered seven countries and four different languages were used. Resistance of change was not perceived until the system was already in use and some problems emerged. System doesn’t work exactly like the processes, which causes some problems. Electrolux looks that perhaps more attention should have been paid for BPR effort, but so short timetable didn’t provide time for it. 8. CONCLUSIONS These two case descriptions provide insight to the different alternatives attached to ERP systems implementation projects. I have here presented the most significant decisions and tasks incorporated in case companies ERP system implementation projects as well as the biggest problems that emerged during these projects. Both cases showed that implementation of an ERP system doesn’t happen without difficulties. Yet, all interviewed parties looked that projects were relatively successful from customer’s
  • point of view (in a likert-scale from 1 to 5 all answered 4=somewhat satisfied). This is in line with the results from McNurlin’s (2001) study where 92% of 117 companies from 17 countries were somewhat satisfied (4) or satisfied (5) with their ERP projects. Migration paths of the case companies were different. One remained as a client of old vendor where other was forced to change the vendor. Both companies had very strong reasons for their decisions. MASI selected the ERP package used by most of the companies in the industry and Electrolux selected package according to Electrolux Groups recommendation and information system environment. Extend of customisation was also different in case companies and opposite to expectations. Mabert et al. (2003) found out that larger companies customized more than medium or small sized companies. On the other hand, they also discovered that companies who started their implementation earlier tended to customize more. Authors made hypotheses that this evolution is due to improvement of systems and consultants knowledge base. This hypotheses is in line with my study, where Electrolux had customized heavily their previous system, but did no customization to new system from same vendor. MASI on the other hand had to do extensive customization because the system was relatively new and lacked a lot of functionality at the time. Both of the cases shows that even there were compelling reasons to implement ERP system, decisions weren’t made without ulterior motives. Both companies had sawn the coming of e- Business and were preparing themselves for it. From this point of view, ERP systems can be seen as a cornerstone or backbone of enterprise’s information systems, on what all the other systems, e.g. e-Business systems, are built on. 9. DISCUSSION As the case descriptions show, all the stages of the new research approach presented in here was found from both of these very different cases. This confirms that all the stages in the research approach model are correct ones. However, this doesn’t mean that there couldn’t be other stages too unidentified in this research, or that classification of stages would be correct one. All stages include several tasks. It might be possible to divide some stages to achieve more detailed research approach model. On the other hand, if some stages are missing in future research, it would imply that two or more stages should be merged. For example Verville and Halingten (2003) classifies in their forthcoming article buying process to six stages where in this model these activities are covered in two stages – evaluation and selection. However Verville and Halingten admits that their model is nonlinear and some of the processes are done concurrently and are embedded. So, for my opinion, these two stages presented in this paper are enough in this somewhat linear 8+2 model. I also want to note, that model presented here suits well only to successful or finished ERPs implementation projects. If the project isn’t finished or it is cancelled, all the stages can’t be found. As in MASI’s case, termination of the project was difficult to define, because termination meeting hadn’t been hold and some of the functionality of the system hadn’t been delivered. However, after the interviews and validation of case description some sort of termination meeting was hold. Of course, even the implementation project isn’t successful or finished, this research approach can be used to study to a part of implementation project also. Further analysis of this model is left to other researchers. Also, further research is suggested in all of these 8+2 areas of implementation project. Especially Go-Live stage hasn’t been studied solely but rather noted among other relevant stages. Overall, I find this model to be a fruitful research approach to study ERPs implementations and to provide big picture.
  • 10. REFERENCES Adler, P.S., McDonald, D.W., and McDonald, F., Strategic management of technical functions. Sloan Management Review, Winter 1992 Akkermans, H., and van Helden, K., Vicious and virtuous cycles in ERP implementation: a case study of interrelations between critical success factors, European Journal of Information Systems 2002, No.11, pp. 35-36 Al-Mashari, Majed and Al-Mudimigh, Abdullah, ERP implementation: lessons from a case study, Information Technology & People, Vol. 16, No. 1, 2003, pp. 21-33 Checkland, P. & Holwell, S., Information, Systems and Information Systems. Making Sense of the field. Chichester: John Wiley and Sons. Currie, W.L., and Seltsikas, P., Exploring the supply-side of IT outsourcing: evaluating the emerging role of application service providers. European Journal of Information Systems 10, pp.123-134 Davenport, T.H., Mission Critical, Harvard Business School Press 2000 Eisenhardt, Kathleen M., Building Theories from Case Study Research. Academy of Management Review 1989, Vol. 14, No. 4, pp.532-550 Erol, Ismail and Ferrell, William G. Jr., A methodology for selection problems with multiple, conflicting objectives and both qualitative and quantitative criteria, article in press, International Journal of Production Economics Groth, Lars, Future organizational design. The Scope for the IT-based Enterprise. John Wiley & Sons 1999 Hong, Kyung-Kwon and Kim, Young-Gul, The critical success factors for ERP implementation: an organizational fit perspective. Information & Management 40, 2002, pp. 25-40 Johnson, J., Chaos: The Dollar Drain of IT Project Failures, Application Development Trends January 1995, Vol.2, No.1, pp. 41-47. Järvinen, P., Theoretical and empirical evidence for job enlargement and job enrichment, Proceeding of MASC’80, Management Science in Finland 1980, pp.9-16 Järvinen, P., On a variety of research output types, In Svensson, L., Snis, U., Sørensen, C., Fägerlind, H., Lindhroth, T., Magnusson, M., and Östlund, C. (Eds.), Proceedings of IRIS23, university of Trollhättan, Uddevalla, Sweden 2000 Järvinen, P., On research methods. Opinpajan kirja 2001, Tampere Finland Kale, Vivek, Implementing SAP R/3, SAMS 2000 Kaplan, B. and Duchon, D., Combining qualitative and quantitative methods in information system research: a case study. MIS Quarterly 12, 1988, pp.571-587
  • Klapka, Jindřich and Piňos, Petr, Decision support system for multicriterial R&D and information systems projects selection, European Journal of Operational Research 140 (2002), pp. 434-446 Klaus, Helmut, Rosemann, Michael, and Gable, Guy G., What is ERP, Information Systems Frontiers 2:2, 141-162, 2000 Kwon, T. and Zmud, R., Unifying the fragmented models of information systems implementation, in Boland, Hirschheim (Eds.), Critical Issues in Information Systems Research, Wiley, New York, 1987 Lano, K. and Haughton, H., Software maintenance research and applications, In Leponiemi (Ed.), NordData’92 Precedings, Tampere, Finland, 123-143 Lee, Jin Woo and Kim, Soung Hie, An integrated approach for interdependent information system project selection, international Journal of Project Management 19 (2001) pp. 111-118 Lyytinen, K. and Hirschheim, R., Information systems failures: A survey and classification of the Empirical Literature, Oxford Surveys in Information Technology, Oxford University Press 1987, Vol. 4, pp.257-309 Mabert, Vincent A., Soni, Ashok, and Venkataramanan, M.A., Enterprise resource planning: Managing the implementation process, European Journal of Operational Research 146 (2003), pp. 302-314 Malhotra, Yogesh, Business Process Redesign: An Overview, IEEE Engineering Management Review, vol. 26, no. 3, Fall 1998 Mandal, Purnendu and Gunasekaran, A., Issues in implementing ERP: A case study, European Journal of Operational Research 146 (2003), pp. 274-283 Markus, ML and Tanis, C, The Enterprise system experience – From adoption to success, In Zmud, R., (Ed.), Framing the Domains of IT Management, Pinnaflex, 2000, 173-207 McNurlin, B., Will Users of ERP Stay Satisfied, Sloan Management Review, Winter 2001, Volume 42, Number 2, p.13 Mitev, N., Toward social constructivist understandings of IS success and failure: introducing a new computerized reservation system, Proceedings of the twenty first international conference on Information systems, Brisbane, Queensland, Australia, December 2000, pp.84- 93 Motwani, Jaideep, Mirchandani, Dinesh, Madan, Manu, and Gunasekaran, A., Successful implementation of ERP projects: Evidence from two case studies, International Journal of Production Economics 75 (2002), pp. 83-96 Ng, Celeste See Pui, Gable, Guy G., and Chan, Taizan, An ERP-client oriented maintenance taxonomy, the Journal of Systems and Software 64 (2002), pp. 87-109 Pettigrew, A., Longitudinal field research on change: Theory and practice. Paper presented at the National Science Foundation Conference on Longitudinal Research Methods in Organizations, Austin 1988 Ptak CA., ERP tools, techniques, and applications for integrating the supply chain, St. Lucie Press 2000
  • Rajagopal, Palaniswamy, An innovation-diffusion view of implementation of enterprise resource planning (ERP) systems and development of a research model. Information & Management 40, 2002, pp.87-114 Royce, Winston W., Managing the Development of Large Software Systems, Proceedings of IEEE WESTCON 1970 Sauer, C., Southon G., and Dampney C.N.G., Fit, failure, and the house of horrors: toward a configurational theory of IS project failure, Proceedings of the eighteenth international conference on Information systems, December 1997, pp.349-366 Scott, Judy E. and Vessey, Iris, Implementing Enterprise Resource Planning Systems: The Role of Learning from Failure, Information Systems Frontiers 2:2, 213-232, 2000 Shields, M.G., E-Business and ERP, John Wiley & Sons, Inc., 2001 Simon, S.J., Successful Implementation of ERP Systems for Multinationals: Using Control and Coordination Artifacts, In Prashant C. Palvia, Shailendra C. Jain Palvia and Edward M. Roche (Ed.), Global Information Technology and Electronic Commerce 2002, Ivy League Publishing Ltd 2002, pp.393-407 Swan, J., Newell, S., and Robertson, M., The illusion of ‘best practice’ in information systems for operations management, European Journal of Information Systems (1999) 8, pp. 284-293 Teng, James TC, Fiedler, Kirk D, and Grover, Varun, An Exploratory Study of the Influence of IS Function and Organizational Context on Business Process Reengineering Project Initiatives, Omega, International Journal of Management Science, Vol. 26, No. 6, pp. 679- 698, 1998 Umble, Elisabeth J., Haft, Ronald R., and Umble, Michael M., Enterprise resource planning: Implementation procedures and critical success factors, European Journal of Operational Research 146 (2003), pp. 241-257 Verville, Jacques and Halingten, Alannah, A six-stage model of the buying process for ERP software, Industrial Marketing Management 5560 (2003) 1-10, article in press Wei, Chun-Chin and Wang, Mao-Jiun J., A comprehensive framework for selecting an ERP system, article in press, International Journal of Project Management