國立中央大學
資 訊 管 理 學 系
碩士論文
ERP 導入前決策對導入風險影響之研究
The Relationship between ERP Pre-implementation
Decisions and Implementation Risks in ERP
Projects—
A Survey on Taiwan’s Manufacturing Firms.
指導教授: 何靖遠博士
研究生: 林雅梅
中 華 民 國 九 十 二 年 七 月
Decisions and Implementation Risks in ERP
Projects—A Survey on Taiwan’s Manufacturing Firms.
Author: Ya-mei Lin Adviser: Dr. Chin-Yuan Ho Department of
Information Management National Central University
No.300, Jung-da Rd., Jung-li City, Taoyuan , Taiwan 320, R.O.C
Abstract
About half of ERP implementations fail to meet expectations. (Stefanou, 2000) Thus,
we include the concept of risk management to categorize problems through
experienced companies survey. It can make the adopting firms aware of risks what
they might encounter during the implementation under the specific selection and
project. What we want to say in the study is how to prevent the risks from realization
by managerial actions, rather than how to decrease the risks.
A mail survey is conducted over the CommonWealth Top 1000 Manufacturers in
Taiwan. Out of 138 respondents, 98 firms that have implemented ERP systems
considered valid empirical data for us to test our hypotheses.
The research findings show that the ERP implementation risks can be categorized into
five types, they are ERP systems design, user involvement and training, IT planning
and integration, skill mix, and management structure and strategy. If the functions of a
firm’s chosen ERP software cannot meet its motivation, the misfit will contribute to
the implementation risks. The source and scope of ERP play a moderating role, and
budget control has an interaction effect between the motivational misfit and
implementation risks. While the schedule, the size, top management support, and the
structure
have
no
significant
interaction
on
the
pre-implementation misfits and ERP implementation risks.
Keywords: ERP; Pre-implementation decisions; Misfit; Risk
relationship
between
Contents
1.
INTRODUCTION ................................................................................................. 1
2.
LITERATURE REVIEW ...................................................................................... 4
2.1
ERP Implementation Process and Pre-Implementation Decisions ........ 4
2.2
Selection Process and Derived Motivations and Selection criteria ....... 7
2.2.1
Selection process............................................................................ 7
2.2.2
Motivation.................................................................................... 10
2.2.3
Selection criteria .......................................................................... 14
2.2.4
Summary...................................................................................... 15
2.3
ERP Implementation Risk.................................................................... 17
2.3.1
The Definition of Risk ................................................................. 17
2.3.2
Measuring The Implementation Risk Of ERP Project................. 17
2.3.3
Risk Management ........................................................................ 19
REFERENCE ...............................................................................................................20
1. INTRODUCTION
Not all of ERP implementations are entirely successful. In fact, about half of ERP
implementations fail to meet expectations. (Stefanou, 2000) Most of them suffered
from over-budget, over-time, user dissatisfaction, threatened lawsuit, failed to
introduce all planned modules, or the big and horizontal ERP systems pulling back
into beta testing. (Hill, 1999) Did it due to the big-time ERP oversold or companies
under-committed?
In the seller part, the keen competition makes the market in chaos. There are
international and local vendors in Taiwan. Besides the ERP solutions from the leading
ERP vendors, such as SAP R/3, Oracle Applications, and J. D. Edwards, the enterprise
applications from local ERP vendors, such as TIPTOP and WorkFlow ERP from Data
Systems Consulting Co., Ltd., and PROYOUNG’s VPROERP, are also adopted by
many domestic manufacturers. There are also traditional package vendors scraped or
extended their former financial or human resource software as so-called ERP package.
The term “ERP” is seriously generalized. ERP vendors will tell you that their software
will solve all your problems, but there will still be gaps. (Hill, 1999) These gaps may
result from the misift between ERP’s best practice and business process or simply
result from the vendors’ overpromise.
In the buyer part, considering the smaller average size of Taiwan organizations, they
should have more effective way to select appropriate ERP software, vendor, and
consultants. Those SMEs may adopt ERP software because of the competition
pressure or the pressure from their suppliers or customers. (Holland et al., 1999)
Comparison with large companies, they pay fewer efforts in selecting and also have
less ability to handle the problems resulting from ERP implementation. (Everdingen
et al., 2000; Adam and O'Doherty, 2000)some firms, such as ODM (original design
manufacturers)/ OEM (original equipment manufacturers), child company (Parr and
Shanks, 2000), or the merged company (Bingi, 1999), may be assigned to adapt some
ERP and ERP vendor that may not suit their firms.
Moreover, managers who planned to implement ERP may be overwhelmed and
confused by research recommendations and, thus, become reluctant to pursue ERP
due to a fear of failure. Most ERP projects fail to live up to expectations. As a result,
scholarly and managerial publications are increasingly addressing the factors that
critical success factors in ERP implementation and the ERP implementation problems.
The results showed the tough tasks and lots of unknown risks of implementing ERP
and were less helpful to companies planned to implement ERP. For these companies,
it is helpful to categorize problems through experienced companies survey because it
can make them aware of risks what they might encounter during the implementation
under the specific selection and project.
In MIS implementation, most of key decisions are made in pre-implementation stage.
These pre-implementation decisions will have the greatest effect on an assessment of
the project’s probability of success or failure should be possible at that time.
(Ginzberg, 1981) However, pre-implementation factors of ERP are often
underestimated or unspecifically treated. Current ERP research concerning the
pre-implementation only covers the survey of motivation and selection criteria for
adopting ERP software (Mabert, 2000; Everdingen et al., 2000) and the way to depict
and select appropriate ERP software. (Sistach et al., 1999; Franch and Pastor, 2000;
Brown et al., 2000; Oliver and Romm, 2000; Stefanou, 2000) Wheather the chosen
ERP software, vendor, and consultants can meet the company’s motivation and
selection criteria or not has not been discussed. Whether these misfits were related to
any implementation problems also has not been discussed. Problems, or risks, in ERP
implementation process are mostly reported by some case studies. (Markus and
Tanis, 1999; Sumner, 2000; Markus et al., 2000; Scott and Vessey, 2002)
This study is to investigate the implementation risks that can be attributed to the
degree how appropriate pre-implementation decisions is, including the selection and
project specifications, and the effect of firm characteristics. On discussing this
relationship a survey is used on Taiwan’s manufacturing firms that have implemented
ERP.
Risks associated with this enterprise-wide ERP software are inevitable but can be
reduced with appropriate managerial actions throughout the implementation process
and the pre-implementation decisions as well. Even though companies may not
satisfy every needs and adhere to every planned selection criteria because of the limit
resource and choices, they can also be aware of the risks arisen from those abandoned
needs and criteria. Thus, they can control the project better through risk management.
Research questions include the following:
1
What categories of problems do Taiwan’s manufacturing firms encounter when
they implement an ERP package?
2
How the functions of a company’s chosen ERP software cannot meet the
planned needs can contribute to ERP implementation risks?
3
How the firm’s chosen ERP software, vendor, and consultants can not meet the
planned selection criteria can contribute to ERP implementation risks?
4
What project specifications can companies do in the early stage to control the
risk resulting from the misfits?
2. LITERATURE REVIEW
Whether the chosen ERP software, vendor, and consultants can meet the company’s
motivations and selection criteria or not has not been discussed. Whether these
misfits were related to any implementation problems also has not been discussed.
Problems, or risks, in ERP implementation process are mostly reported by some case
studies.
In section 2.1, we will discuss the shortage from the past research of implementation
process. We can find that there are few researches concerning how the
pre-implementation decisions contributing to the latter stages. In section 2.2, we will
discuss the shortage from the factor of motivations and selection criteria. We can find
that there are few researches concerning how these motivations and selection criteria
been satisfied. In section 2.4, we will discuss the implementation problems.
2.1 ERP Implementation Process and Pre-Implementation Decisions
In this section, we review four of those process models of ERP implementation
(Bancroft et al., 1998; Ross, 1998; Markus and Tanis, 1999; Parr and Shank, 2000)
and one of MIS development process models (Davis, 1974). Then through the
comparing, we discuss the findings including (1) what pre-implementation decisions
are; (2) how the pre-implementation factors of ERP are underestimated or
unspecifically treated in former research.
Bancroft et al. (1998) proposed an ERP implementation model that was derived from
discussions with 20 practitioners and from studies of three multinational corporation
implementation projects. Bancroft et al.’s (1998) model has five phases. They are
focus, as is, to be, construction and testing, and actual implementation. The focus
phase is essentially a planning phase in which the key activities are the set-up of the
steering committee, selection and structuring of the project team, development of the
project’s guiding principles and creation of a project plan. The “as is” phase covers
analysis of current business processes, installation of the ERP, mapping of the
business processes on to the ERP functions and training of the project team. The “to
be” phase covers high-level design and then detailed design subject to user acceptance,
followed by interactive prototyping accompanied by constant communication with
users. The key activities of the construction and testing phase are the development of
a comprehensive configuration, the population of the test instance with real data,
building and testing interfaces, writing and testing reports and, finally, system and
user testing. The final phase, actual implementation, covers building networks,
installing desktops and managing user training and support. In summary, the model of
ERP implementation extends from the forming of the project team and the
implementation plan to the system going live.
Ross (1998) developed a five-phase model based on 15 case studies of ERP
implementation. The phases are design, implementation, stabilization, continuous
improvement, and transformation. The design phase is essentially a planning phase in
which the key activities are determinations of critical guidelines and decision making
for the implementation. The implementation phase covers all phases of Bancroft et
al.’s (1998) model except the focus phase. In Ross’s (1998) model, the stabilization
phase occurs after the implementation phase and is a period of time in which system
problems are fixed and organizational performance consequently improves. Then, the
continuous improvement phase covers steady improvement in which functionality is
added. Finally, firms expect to reach the stage of transformation in which
organizational boundaries and systems are maximally •flexible.
Markus and Tanis (1999) developed a four-phase model of ERP implementation,
which includes chartering, project, shakedown, and onwards and upwards. The
chartering phase begins before Bancroft et al.’s (1998) focus and Ross’ (1998) design
phases. The key activities are the development of the business case for the ERP
package selection, identification of the project manager, and budget and schedule
approval. Key players in this phase include vendors, consultants, company executives,
and IT specialists. The project phase is similar to Ross’ (1998) project phase therefore
covers Bancroft et al.’s (1998) as is, to be, construction and testing and actual
implementation phases. The key activities of this phase are software configuration,
system integration, testing, data conversion, training and roll-out (Markus and Tanis,
1999). The shakedown phase is similar to Ross’ (1998) stabilization phase which key
activities are bug fixing and rework, system performance tuning, retraining, and
staffing up to handle temporary inefficiencies. The final phase, onward and upwards
phase, is essentially a continuous improvement phase of Ross’ (1998) model.
Parr and Shanks (2000) developed a three-phase model, project phase model (PPM).
The PPM consists of two concepts: implementation phases and sub phases, and
critical success factors. Firstly, the three major phases are planning, project, and
enhancement. The subphases in project phase are set-up, re-engineer, design,
configuration & testing, and installation. The planning phase is similar to Markus and
Tanis’ (1999) chatering phase, which includes the selection of an ERP, assembly of a
steering committee, determination of high-level project scope and broad
implementation approach, selection of a project team manager and resource
determination. The project phase extends from the identification of ERP modules
through to installation and cut-over. The enhancement phase includes the stages of
system repair, extension and transformation. Secondly, the PPM builds on previous
models of the ERP implementation process by augmenting them with CSFs in order
to provide guidance to practitioners in planning and monitoring an ERP
implementation.
Several points need to be made about these four models of ERP implementation.
Firstly, Parr and Shanks (2000) and Markus and Tanis (1999) included a planning
phase, which occurs prior to the actual implementation project and is not to be seen in
Bancroft et al.’s (1998) and Ross’s (1998) models. Secondly, Parr and Shanks (2000)
is the only one relating CSFs to the phases of implementation. However, it does not
show how the CSFs of one phase relate to the following phases. Thirdly, none of
them relates the process losses to the phases of implementation.
In MIS implementation, one popular conceptualization of the phases is Davis’ (1974).
The three phases are definition, physical design, and implementation. By the end of
definition phase, almost all key decisions about the system have been made, including
project
goals,
scope,
and
overall
approach.
The
importance
of
these
pre-implementation decisions to the ultimate success of the system should be
apparent. (Ginzberg, 1981) ERP implementation, in comparison, is a complex
package implementation. (Sumner, 2000) So in ERP implementation, the
pre-implementation decisions include project goals, scope, overall approach, and the
selection of an ERP as well. These pre-implementation decisions will have the
greatest effect on an assessment of the project’s probability of success or failure
should be possible at that time.
After the review of the ERP implementation models and comparison with MIS
implementation model, we define the pre-implementation decisions as the ERP
package selection (Markus and Tanis, 1999; Parr and Shanks, 2000), the selection of
vendors and consultants (Markus and Tanis, 1999), the determination of the steering
committee and the project team and project manager (Bancroft et al., 1998; Markus
and Tanis, 1999; Parr and Shanks, 2000), the project scope and size (Davis, 1974; Parr
and Shanks, 2000), and budget and schedule approval (Markus and Tanis, 1999).0
2.2 Selection Process and Derived Motivations and Selection criteria
2.2.1
Selection process
In the former section, we can find that the selection of ERP software, vendors, and
consultants are out of appropriate consideration. In this section, we discuss further in
the aspect of ERP selection process. We review three ERP acquisition methods
(Sistach et al., 1999; Stefanou, 2000; Teltumbde, 2000) and one framework of
commercial off the shelf (COTS) software acquisition (Finklestein et al., 1996).
Through the review of studies concerning ERP selection processes, we found that
ERP systems procurement has not reached the required maturity. Most of them are
the workshop or conference proceedings, and lack of further following up published
papers.
SHERPA is a more complete method among these researchers proposed. After Sistach
et al. proposed it at 1999, this method had been modeled by a formal language,
NoFun, at 2000. (Franch and Pastor, 2000). And there was following up study on this
method proposed in FirstWorld Class IT Service Management Guide. (Sistach and
Pastor, 2000). The role of SHERPA within a general ERP life cycle up to
implementation and maintenance is shown as figure 2.1.
Figure 2.1. The Five-Phase of SHERPA (Sistach et al., 1999)
The five phases of SHERPA are: (0) study strategy and business processes and decide
to acquire an ERP; (1) search for candidates and first filter; (2) dig into the candidates
and second filter; (3) Analysis and demonstration of candidates and visits to the
providers; and (4) final decision, negotiation and planning.
Phase 0 is a first attempt to organize the work on the IS needs of the organization in
order to help it decide if an ERP is a good solution to satisfy these needs, or
alternatively if it seems better to develop a new proprietary IS, to maintain existing
applications or integrate best-of-breed or vertical software packages. However, we
recognize that this is a complex problem that needs a deeper research and that may
also be addressed through methods for IS strategic planning. Phase 0 is divided in two
sub phases. In the first stage, the project team studies the business, its departments
and business processes to evaluate how well each ERP adapts to the organization. In
the second stage, a committee has to decide if the company has to acquire an ERP.
In Phase 1, based on the knowledge about the company obtained on Phase 0 and on
some minimum requirements about candidate ERPs (maximum cost affordable,
platform, etc.), the project team conducts a market research looking for ERPs suitable
for the organization. The project team has to obtain enough minimum information on
each ERP. In Phase2, the project team needs much more information about the ERPs
obtained in Phase 1. Applying a long list of more detailed selection criteria the project
team should select 2 or 3 ERP candidate solutions. The selection criteria have to be
considered as useful guidelines, not as exclusion criteria. If an ERP solution seems
adequate but implies important changes in the IT infrastructure or in any other part of
the organization or simply does not comply with some criteria, it should not be
eliminated directly.
The purpose in Phase3 is to obtain a much deeper knowledge on each solution,
specifically on its functionality and adaptability to the organization. The ERP
providers have to demonstrate their products to the project team, the company top
management, the mid-level management (department managers) and a selected group
of future final users. Finally, the project team negotiates the contract with the selected
ERP provider, including the estimation of the cost and the schedule for the
implementation and a contingency plan.
Stefanou proposed a three-phase framework of ERP systems selection. (Stefanou,
2000) They are business vision, requirements and constrains to the desire of change,
and ERP selection and ROI/value evaluation. The first phase considers the business
vision as a starting point for ERP initiation/acquisition. The second phase consists of
the detailed examination and definition of business needs, and of the various
constraints. Before proceeding, the desire and commitment to change by all people in
the organization needs to be evaluated. It is a significant force required to fill the gap
between business needs and constraints. The third phase is similar to phase1 to phase4
of SHERPA (Sistach et al., 1999). The key activities of this phase are the selection of
modules of the core system, and the examination of certain selection criteria for
vendor, product, and implementation partner.
To evolve specific criteria for ERP projects, Teltumbde (2000) comprises the
following seven domains of action: (1) Creation of organisational infrastructure, (2)
Constitution of the repertoire of ERP products, (3) Preparation phase, (4) Context
setting phase, (5) Evaluation and selection phase, (6) Approval of the selection, (7)
Mid-course evaluation. Phase 1 to phase 4 is similar to SHERPA phase 0, which
include the constitution of a steering committee and an evaluation team by top
management, list of criteria for a repertoire of ERP products, drawing up people from
businesses with in-depth process knowledge, and iterative process of information
gathering, analyzing, engaging, educating and validating with the broader community
of stakeholders. Phase 5 is similar to phase1 to phase4 of SHERPA (Sistach et al.,
1999). The key activities of phase 6 and phase 7 are top management approval to the
selected product and midcourse evaluation carried out with the involvement of a
larger set of people involved in the implementation.
Since ERP systems are packages, reference was made to an earlier study that
identifies the activities that are undertaken in order to acquire commercial off the shelf
(cots) software. These are: (1) acquisition and specification of requirements, (2)
understanding the available packages, (3) assessment of package compatibility (with
respect to the requirements), (4) selection of the best available package. (Finkelstein
et al., 1996)
Essentially, it is quite the same of the frameworks proposed by Finkelstein et al.,
(1996), Sistach et al. (1999), and Stefanou (2000). What deserves to be mentioned is
the concept of approval in the framework proposed by Teltumbde (2000). In phase 2,
the list of criteria for a repertoire of ERP products is based on the information
collected from various sources. It is validated through communication to the
representative structure and approved by the steering committee. In phase 4, iterative
process of information gathering, analyzing, engaging, educating and validating with
the broader community of stakeholders is carried out, hence, approval of stakeholders
are gained. In phase 6, the team obtains top management approval to the selected
product. In phase 7, the midcourse evaluation carried out with the involvement of a
larger set of people involved in the implementation, hence, approval of these users are
gained.
During the selection processes, the factors that lead to ERP adoption are ascertained
and the selection criteria are set, what will be discussed further in the following
sections.
“Companies engaging in ecommerce or supply chains operate in a sophisticated
business and technological environment and they can be heavily computer-intensive.
In such cases, the effectiveness of ERPS, which span beyond traditional
organizational boundaries, requires collaboration between partners, coordination of
decisions, as well as accurate and real-time information flow in a network of
enterprises.” (Stefanou, 2000)
Brown, et al. (2000) categorized the factors of motivations to two types, including: 1)
business factor; and 2) information technology factor. After a review of prior
literature, Brown, Vessey, and Powell developed 36 items that describe potential ERP
package capabilities. Then, based on factor analyses of the survey responses from
122 senior IS managers, four business factors (data integration, new ways of doing
business, global capabilities, flexibility/agility) and four IT factors (IT purchasing, IT
cost reduction, IT expertise, IT architecture) are identified.
Adam and O'Doherty (2000) studied 14 ERP implementation projects used SAP in
Ireland. Because of the smaller average size of Irish organizations, the result can
reflect the different selection and implementation of SMEs from those of large firms.
In their study of 14 ERP implementation projects, the most common goals pursued the
ERP software were the implementation of a robust transaction processing system
(nine companies) – a ‘world class system’ for two companies. The traditional benefits
of ERP systems, in particular cost reduction benefits, were also sought for nine
companies while for 28% of the respondents year 2000 had been a major incentive to
buy an ERP system, although in no case had it been the only rationale. Three
companies were also seeking improvements in the visibility of their transactions while
four companies bought ERP software under instruction from their foreign
headquarters and put forward no specific goals for the implementation. Finally,
electronic business was a long-term objective for six companies.
Mabert (2000) conducted an ERP survey of U.S. manufacturing firms, which included
the extent of packaged ERP system use in manufacturing firms, the motivation to
pursue such an application, the implementation experience, and benefits obtained. 479
usable responses of 5,000 mailed questionnaires were received, which are randomly
selected set of APICS members employed within manufacturing firms. According to
the responses, the motivations to implement ERP are listed by the average scale as
follows: Replace legacy systems, Simplify and standardize systems, Improve
interactions and communication with suppliers and customers, gain strategic
advantage, Link to global activities, Solve the Y2K problems, Pressure to keep up
with competitors, Ease of upgrading systems, and Restructure company organization.
Reinhard and Bergamaschi (2001) conducted a questionnaire survey of ERP
implementation in Brazil. According to 67 usable responses, with 45 project managers
and 22 users, the pre-implementation motivations are listed by the frequency
managers/users choose as follows: Information Integration (44/22); Need for
management information (42/19); Year 2000 bug (30/13); Search for competitive
advantage (29/20); Evolution of IT architecture (28/10), Process redesign (25/12),
Personnel reduction (16/8), Business globalization (15/8), Imposed by upper
administration (12/10), and Pressure of business partners (4/0).
2.2.3
Selection criteria
Certain packages are regarded as having an exceptional functionality in some of their
modules, as is the case, for example, with PeopleSoft’s Human Resources module.
Other vendors are regarded as specializing in certain industries, supporting
industry-specific best practices, as for example SAP in Chemicals and
Pharmaceuticals, Oracle in Energy and Telecommunications and Baan in Aerospace
and Defense industries (Aberdeen Group, 1997)
Shankarnarayanan (1999) recommends the following criteria for evaluating ERP
software: (i) functional fit with the Company’ s business processes, (ii) degree of
integration between the various components of the ERP system, (iii) flexibility and
scalability, (iv) complexity; user friendliness, (v) quick implementation; shortened
ROI period, (vi) ability to support multi-site planning and control, (vii) technology;
client/server capabilities, database independence, and security, (viii) availability of
regular upgrades, (ix) amount of customization required, (x) local support
infrastructure, (xi) availability of reference sites, (xii) total costs, including cost of
licence, training, implementation, maintenance, customization and hardware
requirements.
Bernroider and Koch (2001) have a more detail discussion on the differences in
characteristics of the ERP system selection criteria between small or medium and
large organizations. They found that there were 12 of the 29 selection criteria items
with strong relationship to organization size. Several aspects dealing with flexibility
(e.g. increased organizational flexibility, process improvement and improved
innovation capabilities) have been rated as less important by smaller organizations, as
these tend to be more flexible from the beginning and do not need to use an ERP
solution for this goal. In addition, the adaptability and flexibility of the software is
higher valued by smaller organizations, as these advantages and maybe unique
business processes need to be preserved. A short implementation time and therefore
lower costs are also given more importance, as resources are a bigger issue.
Internationality of the software and customer and supplier needs are given less
importance
2.2.4
Summary
From the discussion of the above, there are three points need to be made.
Firstly, we found that ERP systems procurement has not reached the required maturity.
We can only find concerning research as the of conference or workshop proceedings.
ERP procurement becomes a strategic and mission critical process for those
organizations considering the adoption of an ERP (Franch and Pastor, 2000).
“Organizations aim at implementing ERPs to enable the overall informational
integration of functional areas across their –re-engineered– business processes, by
replacing with them most of their proprietary legacy systems, and thus reducing their
future needs for in-house bespoke IS development. Usually, an ERP-based IS is set to
become the back office transactional foundations upon which to build the rest of
decisional and communicational ISs, both at intra- and inter-organizational levels.
Thus, in order to reach most or all of the organization functional units and business
processes, the implementation and maintenance of an ERP-based IS usually becomes
a risk and change-intensive project requiring significant economical, temporal and
labor investments. Regard to their current options for software-based management
Information Systems (IS) is the fast and wide proliferation of large packaged
ready-made Enterprise Resource Planning (ERP) systems. All this gives more and
more importance to the task of acquiring ERP software, usually referred to by the
headings of ERP systems procurement, acquisition or selection. In contrast with this
state of affairs, we found that ERP systems procurement has not reached the required
maturity. We can only find concerning research as the of conference or workshop
proceedings. However, obviously, “it is more difficult for an adhoc method to be as
complete and rich as may be a public method developed for being used, reused, and
enriched by many people.” (Sistach et al., 1999)
Secondly, “The characteristics of the ERP software have to match the criteria used by
companies to select information.” (Everdingen et al., 2000) There are few literatures
studied about whether the motivations why a firm pursued ERP software were
achieved or not. In my searching, there is one study testing whether the motivations
for initiating the project were achieved or not. In Reinhard and Bergamaschi’s (2001)
study, they listed 11 items of motivations and tested whether the motivations for
initiating the project were achieved or not in project managers’ and users’ opinion.
These motivations were tested in subjective way, but there should be other objective
way to be used. As long as we can differentiate between motivations and selection
criteria, we may set some positive and negative evaluation criteria to ensure the
motivations are achieved. This is why Day and Barksdale (1994) pointed out the
importance of the purchasing goals.
Finally, none of them discussed how the effect of the proposed processes, although all
of them mentioned about the importance of the selection process. Through these
researches, we are still not sure that how successfully the ERP project can be
improved if we follow some framework they proposed. Teltumbde (2000) pointed
“organizations find it very difficult to perform such evaluation of IT investments,
which is much worse in the case of ERP projects.” One reason is that it is extremely
difficult to estimate all the costs and to assess all the benefits much before the `to be’
processes are configured. (Teltumbde, 2000) The other is the limited choices of ERP
software, vendors, and consultants result in the gap between the evaluation and the
real choice.
2.3 ERP Implementation Risk
2.3.1
The Definition of Risk
Hottenstein and Dean (1992) defined project risk as the likelihood that a project will
fail to achieve its objectives. Risk is the degree of uncertainty concerning loss, and the
higher complexity will result in higher uncertainty. “Risk management strategies are
not necessarily oriented toward the reduction of risk. Rather they are oriented toward
giving the manager tools for successfully managing a project given its risk profile. If a
risk profile is not acceptable, ways might be found to reduce risk at its sources,”
Hottenstein and Dean (1992) pointed.
2.3.2
Measuring The Implementation Risk Of ERP Project
There are two ways to measure the risk of software projects. One is to ask
experienced project managers to identify, rank and rate the risks they perceived.
Boehm(1991) listed top 10 primary source of risk on software projects, based on a
survey of several experienced project managers. They are personnel shortfalls,
unrealistic schedules and budgets, developing the wrong user interface, developing
the wrong function and propertiesgold plating, continuing stream of requirements
changes, shortfalls in externally furnished components, shortfalls in externally
performed tasks, real-tine performance shortfalls, and straining computer-science
capabilities, ordered in decreasing level of combination of experienced project
managers perceived risk frequency and risk impact.
REFERENCE
1
Adam, F. and O'Doherty, P. (2000), “Lessons from Enterprise Resource Planning
Implementations in Ireland – towards Smaller and Shorter ERP Projects,”
Journal of Information Technology, Vol.15, No. 4, pp. 305-316.
2
Bancroft, N., Seip, H. and Sprengel, A. (1998), Implementing SAP R/3, 2nd
edition, Greenwich: Manning Publications.Baron, R. M. and Kenny, D. A. (1986),
“The Moderator-Mediator Variable Distinction in Social Psychological Research:
Conceptual, Strategic, and Statistical Considerations,” Journal of Personality and
Social Psychology, Vol. 51, No. 6, pp.1173-1182.Basil, Preetam, David C. Yen
and Hung-Lian Tand (1997), “Information Consulting: Developments, Trends and
Suggestions for Growth,” International Journal of Information Management, Vol.
17, No. 5, pp.303-323.Bernroider, E. and Koch, S. (2001), “ERP Selection
Process in Midsize and Large Organizations,” Business Process Management
Journal, Vol. 7, No. 3, pp. 251-257.Bingi, P., Sharma M. K. and Godla J. K.
(1999), “Critical Issues Affecting an ERP Implementation,” Information Systems
Management, Vol. 16, No. 3, pp.7-14.
7
Brehm, L., Heinzl, A. and Markus, M.L. (2001), “Tailoring ERP Systems: a
Spectrum of Choices and Their Implications,” Proceeding of the 34th Annual
Hawaii International Conference on System Sciences (HICSS), Maui, Hawaii.
8
Brown, C.V., Vessey, I. and Powell, A. (2000), “The ERP Purchase Decision:
Influential Business and IT Factors,” Proceedings of the Sixth Americas
Conference on Information Systems (AMCIS 2000), pp. 1029-1032.
9
Carr, A.S. and Smektzer, L.R. (2000), “An empirical study of the relationships
among purchasing skills and strategic purchasing, financial performance, and
supplier responsiveness,” Journal of Supply Chain Management, Vol. 36, No. 3,
pp. 40-54.
10 Champion, D.P., Kiet, D.H. and McLendon, J.A. (1990), “Choosing a Consulting
Role,” Training and Development Journal, Vol. 44, pp. 66-69.
11 Davenport, T.H. (1998), “Putting the Enterprise into the Enterprise System,”
Harvard Business Review, Vol. 76, No. 4, pp. 121–131.