CHARACTERIZATION OF CONSULTANT ACTIVITIES
IN ERP PROJECTS
A Case Study
Emiliano Lutteri and Barbara Russo
Department of Computer Science, Free University of Bolzano, Piazza Università 1, Bolzano, Italy
Keywords: ERP implementation project, Enterprise resource planning, ERP upgrade project, Consultants activities.
Abstract: Enterprise Resource Planning (ERP) systems are very common worldwide, but their implementation and
upgrade projects are expensive, complex and often unsuccessful. A great role in their implementation is
played by the consultancy firms, which provide manpower and qualified knowledge. Often, IT managers, on
the preparation stage, need to know how the project will be organized, how the resources will be distributed
and which effort will be necessary from the employees to perform a successful project. Through a case
study we aim to define a way to measure the business value of the consultancy and understand if it is
possible to build a model to achieve this result.
1 INTRODUCTION
An Enterprise Resource Planning (ERP) system is an
enterprise wide packaged application software with
full integrated business processes for enterprise
management. Today, ERP systems have become a
basic business need for many organizations.
Unfortunately, many implementations have
terminated before completion and didn’t achieve
their business objectives even a year after the
implementation. One of the reasons of this failures is
the lack of competence on the ERP deployment and
on the maintenance of the company. Typically, these
activities are outsourced to external consultants and
vendors and their contribution is crucial for
implementing an ERP system. External expertise
and internal competence are both critical resources.
IT managers base their decision on existing
benchmarks for the evaluation of proposals of ERP
implementations that often emphasize the consulting
services. Therefore, with this work we aim at
defining a way to measure the business value of the
activities of consultants and also to build a first
model to achieve this result.
In section 2, we briefly review the literature on
ERP implementations. Section 3 describes the
research settings, question and methods, Section 4
introduces the findings. Discussion, limitations and
future works are respectively described in section 5,
6, and 7.
2 LITERATURE REVIEW
ERP systems are very common platforms
characterized by their modular structure; each
module handles a specific set of business processes
of the company (Bingi et al, 1999). The
implementation of an ERP system is an extensive,
lengthy and costly process, specifically in related
services such as consulting, training and system
integration (Parr et al, 2000; Parr and Shanks,
2000,Esteves and Pastor, 2001.)
Implementing ERP Systems is a complex process
in technical and organizational aspects. Firms need
experienced people for their process implementation
(Esteves and Pastor, 2002). Often they didn’t have
enough resources in house, and so they outsource
part of the implementation to external consultants.
(Wang and Chen, 2006; Holland and Lightet al,
1999) Consultants are involved into ERP
implementation projects to provide additional skills,
knowledge, or simply manpower not available at the
customer, (Haines and Goodhue, 2003). In this
respect, Chan (1999) hypothesized that an ERP
implementation should rely on a composite team that
includes vendors, consultants and customers. In
addition ERP maintenance might require a similar
effort due to system complexity, and the large
number of stakeholders involved (Salmeron and
Lopez, 2010).
293
Lutteri E. and Russo B..
CHARACTERIZATION OF CONSULTANT ACTIVITIES IN ERP PROJECTS - A Case Study.
DOI: 10.5220/0003508902930300
In Proceedings of the 13th International Conference on Enterprise Information Systems (ICEIS-2011), pages 293-300
ISBN: 978-989-8425-55-3
Copyright
c
2011 SCITEPRESS (Science and Technology Publications, Lda.)
2.1 Implementation and Maintenance
Projects
The first projects implemented during the life cycle
of an ERP system are Implementation and
Maintenance Projects. The latter includes
Enhancement, Roll-out and Upgrade projects.
In any of the representations of the lifecycle of
an ERP system existing in literature (PuiNg et al,
2002), Implementation and Maintenance are clearly
separate stages. Implementation projects are crucial
for their impact on the company’s organization
because they introduce innovation and change in the
overall asset of the business activities and involve
the majority of the professional roles. Maintenance
projects need significant investments and they must
be carefully designed before being undertaken.
Enhancement projects, present often a lower
complexity, but they improve existing ERP systems.
The roll-out projects are often used to implement
the same functionalities of the whole system, in
further domains of the company. They are used to
expand the company’s business, using the same
organizational model designed and tested for the
implementation projects. The upgrade project
concerns entire upgrade of the system that is
modified to adapt it to new features implemented in
the new software version, or to adapt them to new
technologies or architectures, in order to improve
business, competitive advantages, and system
integration (SeePui et al., 2002). A key element of
the implementation of these different types of
projects in ERP consists in the activities of the
consultants. Their expertises, their ability to interact
with the project team, and the way they transfer their
knowledge of the application to customers, have
been identified as possible factors of success of the
project.
Conversely, an upgrade project, in which, often,
the software customizations, already developed
during the previous release, have to be rewritten into
the new version, could require a greater effort of
software development activities and a lower
customizing activity (parameter), because in these
projects, usually, the processes are not modified.
2.2 Theoretical Model of ERP Life
Cycle
In our work, we refer to the theoretical model
proposed by Markus and Tanis (2000) organizing
the various events that guide the completion of an
ERP project in four stages (Chartering, Project,
Shakedown and Onward & Upward), the same
phases can be used in implementation projects and
upgrade projects as described by Nah and Delgado
(2006) in their work.
2.3 The Role of Consultants
Researchers have highlighted the prominent role of
external consultants in technology implementation.
(Kraemmergaard and Rose, 2002, Bingi et al., 1999,
Plant and Willcocks, 2007). Resolving conflicts and
smoothing the relationship with consultants is of
foremost importance (Wang & Chen, 2006) as well
as facilitating knowledge transfer from the
consultant to the company (Al-Mashari et al., 2003)
so as to decrease the dependency on the vendor /
consultant. Much of the knowledge owned by the
consultants concerns ERP customization. (Wu and
Wang, 2006). Somers and Nelson (2004) identify
key players and activities across the ERP project life
cycle. External consultants, top management and
end-users are the key people that will significantly
impact the process and outcome of an ERP
implementation (Wang & Chen, 2006, Wang et al,
2007).
Involving these people with both business and
technical knowledge into the project team is
essential to achieve success.(Tsai et al., 2010)
In this work, we differentiate between external
and internal consultant meaning with the latter
internal staff that act as consultant.
2.4 Critical Success Factors
The definition of success in Information System and
specifically for ERP system is multidimensional and
dynamic. It depends on so many factors that cannot
be uniquely defined. Shanks et al., (2000)
differentiate between success in the planning and
implementation phase and success in stabilization
and maintenance phase. In the former case, success
refers to projects on time and on budget and in the
latter to organizational performance.
To predict project success, research in IS has
focused on factors influencing ERP success, called
Critical Success Factors (CSFs) (Nah and Delgado,
2006; Nah et al, 2003, Razmi et al., 2009 Holland et
al., 1999, Salimifard et al. 2010,Wu and Wang,
2007). Critical success factors have been defined as
“those few critical areas where things must go right
for the business to flourish” (Parr et al., 2000).
Nah and Delgado (2006) have identified seven
categories of factors (Table 1).
ICEIS 2011 - 13th International Conference on Enterprise Information Systems
294
Table 1: The Critical Success Factor for implementation
and upgrade projects (Nah and Delgado, 2006).
Critical Success Factor Implementation Upgrade
ERP Team composition, 4.37 4.35
Top Management Support 4.31 4
Communication 4.17 4.12
Change Management 4.13 4
Project Management 4.06 4.04
System Analysis, and
Technical Implementation
3.92 3.75
Business Plan and Vision 3.87 3.63
Each factor has been ranked with a five-likert
scale on the results of a survey to experts (being five
the most critical value). Factors’ influence varies on
the type of project (implementation or upgrade).
3 RESEARCH
3.1 Research Question
The implementation of an ERP system is often very
expensive, and a large part of the cost of
implementing and maintaining an ERP system is due
to the cost of the consultancy. In our research, we
aim at investigating the success of an ERP
implementation with particular focus on the
activities performed by the consultants and their
business value during an implementation or upgrade
of an ERP system. In particular, we focus on the
following research question:
Q1 what activities of consultancy are critical for
the success of an ERP implementation or upgrade
project according to objective measurement
principles?
3.1.1 Success Factors and Measures
In our research, we were able to collect data and
measures, in terms of effort and size, on three CSFs:
“Team composition”, “Project management”, and
“System analysis, selection and technical
implementation”. This three factors are included in
our success model in figure 1.
Team Composition concerns professional roles and
competences of the project team. Project team
should be balanced, cross-functional and
representative of the different areas of interest of the
project (Razmi et al., 2009).
Project Management defines responsibility and
scope of the project. The activities in project
management relate to control and monitor the
implementation of the project and its schedule and
budget.
System Analysis and Selection and Technical
Implementation consist in all those activities
related to integration with existing legacy systems,
to definition of architecture and design of the ERP
system and to the selection of the more suitable
software package.
Then we aim at evaluating the business value of
the consultancy characterizing:
the Team Composition in terms of size of
professional roles involved and in terms of effort of
their activities in ERP projects;
the System analysis and technical
implementation in terms of the effort spent in the
ERP projects;
the project management as percentage of time
spent in this activity as well as the allocated
resources. Many of these CSFs refer to activities
made by external consultants. These measures are
reported as indicator as predictor of success in the
model presented in figure 1.
3.2 Research Methods
This preliminary research work, using a case study,
aim at analyze the various projects, the professional
roles played by the internal and external team, and at
categorize the activities done from each category of
professionals, during the implementation and the
upgrade project performed in Energy.
Referring to Markus and Tanis model, we focus
on the "Project stage". During this stage, we have
also collected the information related to the activities
carried out, through the time sheets daily compiled
by external consultants and by the employees of the
internal IT department.
3.2.1 Case Study: Energy
Using the model in presentation, we intend to
develop our research work analyzing the data
gathered in a real company. This is a local firm, of
medium size, located in Italy, with around 450
employees, which produces, distributes and sells
electricity and gas in one region of Italy. For
convenience, we will call this company Energy.
3.2.2 The SAP Projects in Energy
The business information system of Energy is a SAP
ERP system, deployed in 2002, implementing the
modules of SAP R3. During 2003 was implemented
the project SAP ISU Electricity (Electricity) that has
involved the core business processes related with the
distribution and sales of electricity. During 2005,
CHARACTERIZATION OF CONSULTANT ACTIVITIES IN ERP PROJECTS - A Case Study
295
Energy implemented the project SAP ISU Gas
(Gas), derived from SAP ISU Electricity. Then,
during 2006, Energy has implemented the sales
processes on the deregulated national market,
through the SAP ISU Trading (Trading). In 2010,
Energy decided to upgrade their SAP system
released 4.6C toward the new version of the
software named ECC6.0 (Upgrade).The upgrade
project implied a technical upgrade of the whole
software system, then rewriting of all the most
important customizations made in the old version
and finally a strong testing activity of all programs,
functions and processes.
3.2.3 Projects’ Description
The four SAP projects performed in Energy are
described in Table 2, where we summarized data on
size and complexity. In particular, we have classified
them in Implementation, Rollout and Upgrade.
Table 2: The four project under study by type, number of
modules, number of users, number of change requests,
budget and duration.
Project Type Mod Users CR Budg Durat
Nr. Nr. Nr. K€ Months
Electricity Impl 5 100 117 450 10
Gas Enhan. 5 70 14 330 9
Trading Roll. 4 20 19 90 5
Upgrade Upg. 11 220 730 190 5
Table 2 illustrates, the name , the type of the
project, the number of the ERP modules implement-
ted (complexity of the project), and the number of
the New Change Requests (CR) (business
complexity). In the case of the Upgrade project, the
number of CRs indicates the number of programs
that have been changed during the technical
upgrade. The first project, Electricity, is an
Implementation Project. The business processes
were tailored starting from a pre-customized model
for Utilities companies. Although the original
commitment was to reduce as minimum as possible
the customizations (as suggested by (Wu and Wang,
2006)), the number of the CRs implemented is high
(117). This was the first project implemented at the
company and demonstrates poor project success in
scheduling and budget as reported in Table 3.
The second project, ISU Gas, was implemented
starting from the ISU Electricity, because many
parts of the processes were in common. For this
reason the number of new change requests is much
lower (14). This indicates a strong strategy of reuse
to reduce cost and effort. The project was on time
and on budget and, as such, demonstrated a high
degree of success. The third project implemented is
Energy Trading: this was a rollout project directly
derived from ISU Electricity. In our context, this
project was a replication of the first one and as such
has a good degree of reuse (low CRs) but a smaller
complexity of modules implemented. This is
because this project doesn’t include more complex
processes of electricity distribution. Table 3
illustrates the projects and their success according to
the perception of the IT manager of Energy.
Table 3: Success in the four ERP projects.
Project name On time? On budget? Success
Electricity No No No
GAS Yes Yes Yes
Energy Trading Yes Yes Yes
Upgrade Yes Yes Yes
3.2.4 Professional Roles
Analyzing data, we have identified seven different
professional roles in project teams: the System
Specialist (SS) provides technical knowledge about
the software, competence on hardware
configurations and on systems tuning. The Junior
Developer (PrJR) is a programmer with experience
in development, usually less than three years. Senior
Developer (Pr) is a programmer with extensive
experience in development with the programming
languages of the ERP system being implemented
and his skills cover several functional modules of
the system. Junior Consultant (CJR) has work
experience less than 3 years, superficial knowledge
of a limited number of software modules. Senior
Consultant (C) is a practitioner with several years
(minimum 7) of experience and a strong knowledge
about the specific topics of the customer’s firm;
Moreover, they know very well, how the different
modules of the software are working, and they
develop the functional and technical analysis, set the
configuration’s parameters and address the
customizing activities. The Project Manager (PM)
has, for side of the consulting firm, the control of the
external resources involved and he is responsible,
together with the internal project manager, for the
outcome of the entire project.. User (U) is selected
from various operating departments and must be
familiar with business processes and have domain
knowledge of their areas .They are involved at the
analysis and the testing stages.
Table 4 displays the number of the persons
involved and the effort per project by role. The data
regarding the Upgrade project are split among
internal and external team. The percentage is refer-
red to total amount of effort spent in the project.
ICEIS 2011 - 13th International Conference on Enterprise Information Systems
296
Table 4: Effort by team role.
6 PM C CJR Pr PrJR SS U Total
Electricity
Nr 1 6 4 4 2 1 18
Days 34 476 150 369 28 25 1082
% 3,1% 44,0% 13,9% 34,1% 2,6% 2,3% 100,0%
Gas
Nr 1 6 1 4 12
Days 33 252 39 171 495
% 6,7% 50,9% 7,9% 34,5% 100,0%
Trading
Nr 1 4 2 7
Days 2 116 44 162
% 1,2% 71,6% 27,2% 100,0%
Upgrade external
Team
Nr 1 5 1 2 1 2 12
Days 46 129 84 80 10 50 399
% 8,3% 23,3% 15,2% 14,4% 1,8% 9,0% 72,0%
Upgrade Internal
team
Nr 1 4 1 1 2 7
Days N/A 49 46 47 13 155
% N/A 8,8% 8,3% 8,5% 2,3% 28,0%
Upgrade Sum 8,3% 32,1% 15,2% 14,4% 10,1% 17,5% 2,3% 100,0%
Table 5: Effort (in days) per project by activity.
Project PM Cust Dev Test Train Sys Act Supp post Err Hand Tot
Electricity
36 308 392 149 46 25 88 37 1082
3,3% 28,5% 36,2% 13,8% 4,3% 2,3% 8,2% 3,4% 100,0%
Gas
46 184 153 64 10 5 32 494
9,3% 37,2% 31,0% 13,0% 2,0% 1,0% 6,5% 100,0%
Trading
12 88 37 10 1 3 11 162
7,4% 54,3% 22,8% 6,2% 0,6% 1,9% 6,8% 100,0%
Upgrade
49 0 106 242 1 105 17 32 552
8,9% 0,0% 19,2% 43,8% 0,2% 19,0% 3,1% 5,8% 100,0%
3.2.5 Project Activities
We analysed the four projects by the activities
reported in the time sheets (records), differentiating
between internal and external effort. After a deep
analysis of the records, we came up with the
following categorization of activities:
Project management: activities related to
organization, management and control of the project.
Customization: activities to tailor the system on
the customer requirements. This includes analysis of
requirements, parameter setting and tuning.
Development: activities of software develop-
ment needed to satisfy customer requirements that
cannot be satisfied directly from parametric
customizing. It includes analysis, code writing, and
first testing on the development system.
Test: system testing to verify the functionalities
of each module and integration testing to verify
modules integration.
Training: activities performed by external
consultants and addressed to users. They aim at
transferring knowledge about system’s functio-
nalities from external to internal staff.
System Activity: activities needed to install,
prepare, tune and synchronize the different systems
included in the system environment.
Post go live support: activities performed by
internal or external consultants, after the go-live of
the system to stabilize the system in its first
operational phase. The duration of these activities
can give an indication of the success of the project.
Error handling: activities specific for solving
errors detected after the go - live of the project.
Table 6: Electricity: Effort in days by activity and role.
Role PM Cust Dev Test Train
Sys
Act
Supp
post
Err
Hand
Tot
C
11
252
48 69 25 44 27 476
CJR
56 11 42 22 10 10 150
Pr
4 325 30 10 369
PrJR
5 22 28
Sys
25 25
PM
21 3 8 2 34
Tot 36 308 392 149 46 25 88 37 1082
Table 7: Gas: Effort in days by activity and role.
Role PM Cust Dev Test Train
Sys
Act
Supp
post
Err
Hand
Tot
C
11
171
1 30 9 5 24 252
CJR
2 13 15 1 8 39
Pr
152 19 171
PM
33 33
Tot 46 184 153 64 10 5 32 495
CHARACTERIZATION OF CONSULTANT ACTIVITIES IN ERP PROJECTS - A Case Study
297
Table 8: Trading: Effort in days by activity and role.
Role PM Cust Dev Test Train
Sys
Act
Supp
post
Err
Hand
Tot
C
10
88
10 1 3 4 116
Pr
37 7 44
PM
1 1
Total 12 88 37 10 1 3 11 161
3.3 Model Construction
To build up our success model, we first identified
the success factors to put in input of the model,
among these ranked in the work of Nah and Delgado
(2006) (Table 1): but only the factors we could
measure in the projects analyzed in this work. Then
we identified, for each factor proposed, the measures
that we used to characterize them (Size, Roles;
Effort per Activity). For each project we are able to
identify them in time and budget as indicator of
success, as perceived from IT manager (Table 3).
Speculating on the measure values collected against
the values of the success model,we have determined
which measures actually might predict the success of
the project. Otherwise we have knowledge that other
factor could be indicate success in other context, and
this is a limitation of our model.
Project
type
Succesfull ?
System analysys
Team composition
Project Mgmt
Size, Roles, Effort per activity
Effort per activity
Effort per activity
Success factors Measures
Yes
No
Figure 1: The model of success proposed in the study.
4 FINDINGS
Using the model proposed, we analyze the data
regarding the factors identified as critical for the
success. As first “Team composition”, evaluated
through the following measures:
Size of the team in terms of total number of persons
involved in each project (table 4): we note that,
considering only the external team composition , the
size results high (18) in Electricity, and lower in Gas
(12) and Trading (7) and Upgrade External (12): it
seems that a lower size of the team might be
indicator of success. But we have to be aware of the
business complexity of the projects, it was higher in
Electricity than in the other implementation projects.
Roles: measured in terms of effort spent for each
role in the project. We note that in all projects, the
most part of activities is made by Senior Consultants
(C ). As such, their activity is necessary to achieve
success but, focusing on implementation projects, it
seems that more activities are needed from this role.
Analyzing the role of Junior Consultant, it seems
that this role is not relevant for the success.
Effort per Activity: measured in terms of days
spent per activity done. Analyzing table 5, we see
that the activities are distributed among the different
roles, but the most performed activities are
customizing and development. In the Upgrade
project, no customization has been reported as no
functional upgrade was performed. Electricity
project has the highest effort in development and the
lowest in customization among the projects. We
pose the attention on the activities made by each
role, but in particular by Senior consultants.
Analyzing table 6,7,8 we see that the major activity
done from them (C), excluding Upgrade Project ,is
the customizing (Cust.) activity: 53% of his
activities in Electricity, 67% in Gas and 76% in
Trading. Moreover, in the projects Gas and Trading ,
both successful , Customizing is the most activity
done. Conversely in the project Electricity the most
performed activity results the development, probably
because of the high number of CR. Analyzing this
data, it seems that the customizing activity is critical,
and the major actor is the Senior Consultant, who, to
achieve success, has to do the customizing activity,
in a more focused way, without spending time in
other activities.
Then we analyze the activities related with “Project
management” (PM) that is characterized by the
measure of effort in project management activity:
table 4 shows that the role of project manager is
normally played by only one external employee.
Table 5 shows the effort per project by activity: the
PM activity has a similar value among the four
projects, but we note that the minor value (3,3,%)
regards the project Electricity. this is a not
successful project, That’s why to achieve success we
need an higher effort in this activity.
Finally we evaluate the activities related with
“System analysis, selection and technical implemen-
tation" that in our case is characterized by the
measure of the effort spent in "System's activity",
performed by System specialists (SS) or by
Consultants (C). Analyzing the implementation or
rollout projects the values of the system's activity
appear quite similar. This means that this activity is
not relevant to achieve success. The effort spent in
system activity for Upgrade project, conversely, is
very high, and this measure, together with the test
activity, characterizes very well this kind of projects.
ICEIS 2011 - 13th International Conference on Enterprise Information Systems
298
5 CONCLUSIONS
This preliminary work aim at characterizing the
business value of the professional roles, measuring
the activities performed in implementation and
upgrade of ERP projects to understand which roles
are critical for the project to succeed. We propose a
simple model drafted from these initial observations,
based on the success factors of Nah and Delgado,
(2006) and a set of measures that, evaluated on these
factors characterizes the factors in terms of the
overall project success. By analyzing the distribution
of effort over the activities performed in four
different SAP projects, we found that in our context
the key factors of success are Team composition,
Project management and System analysis and
technical implementation. Using our model we
found that to achieve success, the project team
should not be too large, and we have identified as
critical for the implementation projects the role of
Senior Consultant, that is mainly involved in several
activities. Moreover, we observed that his activities
are critical, that’s why his effort should be well
enough provided and focused on the customization
activity. By upgrade projects, where there is no
customizing activity, the critical activities are
Testing, performed by internal and external
Consultants, and System's activity, performed
mainly by system's specialists.
The success has been also determined by the
increasing knowledge reuse and retain acquired by
the internal staff with the implementation of the
projects. This knowledge allowed the manager to
reduce the cost for external staff and establish an
internal Help Desk that automatically manages the
change requests.
6 LIMITATIONS
The findings of this study are specific to one single
ERP System, the SAP System, and one company.
The size of the company, medium for Europe, the
number of the users involved, the characterization of
the specific business (energy) could limit the
generalization of the findings. Moreover, not all the
professional roles considered - as Junior developer
or junior Consultant – can be found in literature. In
addition, the classification of the activities is made
interpreting the activity's description written from
team members on time sheets. As such, data are
subjective and subject to bias. For the Upgrade
project, an automated system for Help Desk has
been implemented and more objective analysis on
the activities and the requests of change can be
derived. This will be matter of future work. In our
projects, we were able to collect data for three CSFs:
Project Management, Technical Activities and ERP
and Team composition. Other factors were not
considered relevant at time of data collection. For
this reason, the model and the related discussion is
limited.
7 FUTURE WORKS
The success defined in this work concerns the
contractual commitment of the suppliers. The project
has been successful if it has been on time and on
budget at go live. According to Markus and Tanis
(2000), the activities performed after go live are
critical and key indicators of long-term success. As
such, Energy has established a Help Desk service
that automatically collects bug reports and new CRs
and provides solutions.. With this data we can trace
the flow of request and the time of occurrences and
fixing of issues Future work will mine this wealth of
information to get a more objective characterization
of the projects during maintenance.
REFERENCES
AlMashari, M., AlMudimigh, A. and Zairi, M. 2003.
Enterprise resource planning: A taxonomy of critical
factors. European Journal of Operational Research,
Vol.146, Issue 2, pp.352364.
Bingi, P., Sharma, M., Godla, J. 1999. Critical Issues
Affecting an ERP Implementation. Information
Systems Management, Vol. 16 issue 3, summer 1999,
pp.7-8.
Chan R. 1999 Knowledge management for implementing
ERP in SMES, Sapphire 99, 3rd Annual SAP Asia
Pacific, 1999.
Esteves, J., Pastor, J. 2001. Enterprise Resource Planning
Systems Research: An Annotated Bibliography.
Communications of AIS, Volume 7 Number 8.
Esteves, J., Pastor, J. 2002. A framework to analyse most
critical work packages in ERP implementation.
International Conference on Enterprise Information
Systems (ICEIS), 2002, Spain.
Haines, M., Goodhue, D., 2003. Implementation Partners
Involvement and Knowledge Transfer in the Context
of ERP implementation. International Journal of
human computer interaction Vol16,No.1,pp.23-28.
Holland, C., Light, B., Gibson, N., 1999. A Critical
Success Factors Model for Enterprise Resource
Planning Implementation. 7th European Conference
on Information Systems ECIS, Copenhagen, Denmark.
CHARACTERIZATION OF CONSULTANT ACTIVITIES IN ERP PROJECTS - A Case Study
299
Kræmmergaard, P., Rose, J. 2002. Managerial Compe-
tences for ERP Journeys Information Systems
Frontiers 4:2, 199–211, 2002.
Markus, M. L., Tanis, C., 2000. The enterprise systems
experience from adoption to success, in: R.W. Zmud,
M.F. Price (Eds.),(2000), Framing the Domains of IT
Management: Projecting the Future Through the Past.
Pinnaflex Educational Resources Inc., pp. 173–209
(Chapter 10).
Nah, F., Delgado,S., 2006. Critical success Factors for
enterprise resource planning implementation and
upgrade. Journal of Computer Information Systems.
Nah, Zuckweiler, Lau, (2003). "ERP Implementation:
Chief Information Officers Perceptions of Critical
Success Factors". International Journal of Human -
Computer interaction, Vol.16(1), pp.5–22.
Parr, A., Shanks, G., 2000. A Taxonomy of ERP
Implementation Approaches. 33rd Hawaii
International Conference on Science Systems HICSS,
Maui, Hawaii.
Parr, A., Shanks, G. 2000. A Model of ERP Project
Implementation. Journal of Information Technology,
vol. 15, n. 4, December (2000), pp.289-304.
Plant, R., Willcocks, L., 2007. Critical success factors in
international ERP implementations: a case research
approach. Journal of Computer information Systems.
Pui Ng, C., Gable, C. and Chan, T., 2002. An ERP-client
benefit-oriented maintenance taxonomy. The Journal
of Systems and Software, Vol. 64.
Razmi, J., Sadegh Sangari, M., Ghodsi, R., 2009.
Developing a practical framework for ERP readiness
assessment using fuzzy analytic network process.
Advances in Engineering Software 40 (2009) 1168–
1178.
Salmeron J., Lopez, C., 2010. Forecasting Risk Impact on
ERP Maintenance with Augmented Fuzzy Cognitive
Maps. Transactions on Software Engineering, 2010.
Salimifard, Ebrahimi and Abbaszadeh, 2010. Investigating
Critical Success Factor in ERP Implementation
Projects. IEEE 2010 2 ,pp. 82–86.
Shanks, G., Parr, A., Hu, B., Corbitt, B., Thanasankit, T.,
Seddon, P., 2000. Differences in Critical Sucess
Factors in ERP Systems Implementation in Australia
and China: A Cultural Analysis. 8th European
Conference on Information Systems ECIS, Vienna,
Austria, (2000).
Somers, T. M., Nelson, K., 2004. A taxonomy of players
and activities across the ERP project life cycle;
Information and Management, Vol 41, No 3,pp. 257-
278.
Tsai, Schaw, Fan, Liu, Lee and Chen, 2010. An empirical
investigation of the impact of internal/external
facilitators on the project success o ERP: a structural
equation model. Decision Support Systems 50 (2011),
pp. 480 – 490.
Wang, E., Chen, J, 2006. Effects of internal support and
consultants quality on the consulting process and ERP
system Quality. Decision support Systems, Vol 42,
pp.1029-1041.
Wang, Chia-Lin, Jiang, Klein. 2007. Improving enterprise
resource planning (ERP) fit to organizational process
through knowledge transfer. International journal of
Information management .Vol 27, pp 200-212.
Wu, J., Wang, Y., 2007. Measuring ERP success: The
key-users_viewpoint of the ERP to produce a viable IS
in the organization. Computers in Human Behavior
Vol 23 (2007),pp. 1582–1596.
Wu, J., Wang, Y. 2006. Measuring ERP success: The
ultimate user view. International Journal of
Operations &Production Management Vol. 26 No. 8,
2006 pp. 882-903.
ICEIS 2011 - 13th International Conference on Enterprise Information Systems
300