Implementation of Enterprise Resource Planning System ...
Implementation of Enterprise Resource Planning System -
theoretical research approach and empirical evaluation in
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
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
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
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
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
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
‘'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,
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
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
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
Business Process Reengineering
Initiative Evaluation Selection Modification Training Go-Live Termination Development
Conversion of Data
Big Bang, Incremental or Phased Rollout
Analyze Configure Test Training
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
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
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
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
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.
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.
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.
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,
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.
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),
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-
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
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-
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