Memory as an Elephant: How prior Events Determine

User Attitudes in ERP Implementation

Lene Pries-Heje

Software Software Development Group, IT University of Copenhagen

Rued Langaardsvej 7, 2300 Copenhagen

Abstract. Assimilation of a standard ERP system to an organization is difficult.

User involvement seems to be the crux of the matter. However, even the best

intentions for user involvement may come to nothing. A case study of a five

year ERP implementation process reveals that a main reason for this miss may

be that the perception of usefulness in any given phase of the implementation is

heavily dependant on preceding events – the process. A process model analysis

identifies eight episodes and nine encounters in the case showing that users atti-

tude towards an ERP system change between acceptance, equivocation, resis-

tance and rejection depending on three things: (1) Dynamic between user and

consultants, (2) Dynamic between different user groups, and (3) Understanding

of technical, organizational and socio-technical options.

1 Introduction

Organizations may have very diverse technical and strategic reasons for adopting

integrated Enterprise Information Systems [1], [2], and success is not a monolithic

concept; rather it is multidimensional and relative [1]. However use is one of the most

frequently reported measures of system implementation success [3]. We therefore

assert that a successful implementation must be coupled with high quality of use in

order to fully realize the benefit of the ERP system. Quality of use defined as “how

well an end user understand a piece of software and how effectively the user can

exploit the capabilities of the software” [4]. Although research shows that most or-

ganizations implementing ERP systems may expect difficulties using the system for a

shorter period after go-live [2], some organizations continue to struggle with the use

of the system for years after go-live[5]. The poor quality of use can be caused by:

- The capabilities of the ERP Package being unable to meet the organizational re-

quirements[6], [7].

- Poor design decisions regarding configuration of the ERP Package, customiza-

tions and integration with other systems [1], [8]

- Human factors: Unforeseen human enactment of the software [4] and resistance to

change[9].

Having users participate and being involved in ERP implementations are considered

essential for success ([10], [9], [8]and will result in a better fit of user requirements,

Pries-Heje L. (2007).

Memory as an Elephant: How prior Events Determine User Attitudes in ERP Implementation.

In Proceedings of the 1st International Joint Workshop on Technologies for Collaborative Business Processes and Management of Enterprise

Information Systems, pages 64-74

DOI: 10.5220/0002426800640074

 SciTePress

achieving better system quality, use and acceptance [11]. “User participation” refers

to the behaviours and activities that users perform in the system implementation proc-

ess. User involvement” refers to a psychological state of the individual, and is defined

as the importance and personal relevance of a system to a user [12]. However we

should not assume that having users participate will automatically result in personal

involvement and commitment to the result. To better understand how user involve-

ment during an ERP experience is changing over time, and how it is affecting the

attitude toward the new system, this paper uses a longitudinal case-study and a proc-

ess-oriented view inspired by Newman & Robey’s [13] model. The analysis show

how the user involvement and perceived usefulness of the system change over time as

the dynamic between the participating users and consultants changes and knowledge

to re-design the system and the organizational work processes is generated.

2 Research Question and Method

A longitudinal case study within the interpretive tradition of information technology

studies [14] is conducted. The aim of the research is to better understand how and

why the user involvement and the perceived usefulness of the system change over

time. Especially how the dynamic and the communication between the users and the

developers are influencing the outcome. In line with the assumptions of interpretive

research I focused on the participants’ subjective descriptions of the implementation

process and their expressed feelings and thoughts about their involvement and the

perceived usefulness of the ERP package. The first initial analysis of the interviews

revealed that actions and events in the case were strongly influenced by prior events,

and that user involvement and the perceived usefulness of the system had changed

over time. Thus a process model inspired by Newman and Robey’s model [13] was

used to guide the analysis to focus on the social dynamics between the users and the

developers (consultants) during the implementation.

The study was carried out in the Danish headquarter of an international engineer-

ing company called Alfa (pseudonym). In January 2001 Alfa started up the process of

selecting and implementing a standard ERP system, and in October 2003 they went

live. The case study covers a 5½ year period from January 2001 to summer 2006.

Data collection was carried out through interviews with the ERP project program

manager, users serving as team leaders during the implementation, managers and end-

users from all functional areas within project scope, a consultant participating in the

project on the vendor side, and the vendor’s solution architect. All 16 interviews were

semi-structured and lasted 1½ to 2 hours. The interviews were taped and transcribed.

An initial interview with the project program manager were conducted in February

2005 and the rest of the interviews from November 2005 to August 2006. It has not

been possible to follow the project from the start although it had been preferable.

Thus to cover the implementation from the beginning and up to date, the interviews

have been conducted with a retrospective focus.

One of the difficulties using the interview material is, that the interviewees’ inter-

pretations of the history as well as the immediate situation often is influenced by

difficulties or conflicts taking place at the time of the interview. Written project

documentation has therefore been used to verify the interviews where possible. Alfa

has provided elaborate documentation including detailed requirements specification,

documented workshop evaluations of the candidate systems, business cases, gap

analysis, issue-log and change requests.

The data analysis were an iterative process going back and forth between coding

and collecting data to allow gaps to be identified and addressed, and different inter-

viewees interpretations to be commented and reflected on by others. A hermeneutic

interpretive approach [14] has been used going back and forth between the field mate-

rial and different interpretations. Going through the transcribed interviews the initial

analysis made it clear, that end users and IT-experts had very different interpretations

of the usefulness of the new systems, and that the end users perceived the usefulness

of the system to have changed over time. Therefore another round of analysis was

conducted using a process model inspired by [13].

The process model focuses on sequences of events over time in order to explain

how and why particular outcomes are reached. The constructs in the process model

are antecedent conditions, episodes (a series of events that stand apart form each

others), encounters (mark the beginning and end of an episode), and outcome over the

course of time (see figure 1). The historic context of the ERP implementation is ex-

pressed through the antecedent conditions. During each episode the antecedent condi-

tions of the episode may be challenged and the users may choose to respond by

changing their involvement and attitude toward the new system. In this paper the

process model is used to analyse how and why user involvement and the user’s atti-

tude toward the ERP implementation is changing over time. I have adopted Newman

and Robey’s four categories of episodes which are: (1) episodes led by the IT-expert

– focus on the technology, (2) episodes led by the users - focus on the business, (3)

episodes of joint development, and (4) “wait and see” episode when both party are

uncommitted. As possible responses to each episode four categories of user attitude

are used: (1) acceptance of the system, (2) equivocation, (3) resistance, and (4) rejec-

tion. Category 1, 2 and 4 are included in Newman and Robey’s original process

model, however I found, that a fourth category were necessary; rejecting a system or

parts of a system may not be an option for the users, but resisting or enacting the

system in order to minimise the use or the consequences is a milder but still powerful

way to express non-acceptance.

3 Implementation of an ERP System at Alfa Engineering

The case organization Alfa is an engineering company with more than 80 years of

experience - a leading supplier of systems, consultancy and engineering services to

the pharmaceutical and biotechnological industry. The organization has 1200 em-

ployees in Europe, China and USA. Employees typically have a degree from a tech-

nical university. Most of the work in Alfa is conducted in large projects lasting sev-

eral years and costing billions of US$. Thus Project Managers are quite powerful and

influential.

The ERP project started in January 2001 at Alfa’s headquarter in Denmark. A

Project Manager with extensive ERP Project Management experience was hired to

manage the project. From the very beginning it was clear, that this was a common

project for management and employees in Alfa. It was never questioned that users

should participate throughout the project and in all aspects of the project. A project

organisation was set up and user representatives from all functional areas included in

the project scope were appointed.

Alfas core business is project administration and project management on behalf of

there customers, but they don’t do any production. Alfa was aware that ERP systems

in general are not targeted at thei

r line of business. Therefore a thorough evaluation

and selection process was to be conducted to ensure that the standard system meet

their needs. Alfa spend almost a year specifying requirements, evaluating candidate

systems and finally selecting a system and 9-10 month configuration and customizing

the system before going live in October 2003.

Rejection

Resistance

Equivocation

Acceptance

ep1

ep3

ep2

ep4

ep5

ep6

ep7

ep8

en2

en3

en1

Antecedent conditions:

Encounter (en)

Episode (ep)

Perceived

usefulness

high

Perceived

usefulness

low

Time 1/2001 1/2002 1/2003 1/2004 1/2005

en2

User/business-let process

en9

en8

en6

en5

en7

en4

en3

Fig. 1. Alfa's process model adapted from Newman & Robey (1992).

3.1 A Process Model for Alfa’s ERP Experience

In this section Alfa’s ERP process model is described and a graphical representation

is depicted in figure 1.

Antecedent Conditions: Up until the decision to buy and implement the ERP sys-

tem Alfa had no experience with integrated systems, and very limited experience with

standard systems. Historically software had been developed specifically for functional

areas and allowed the users significant influence on the design of the software.

Encounter 1 – project initiated:

In order to improve the quality of services offered

to the customers, improve resource management, and provide better financial control.

Alfa as many companies before them had however come to the conclusion, that an

integrated ERP Package providing real-time sharing of data were necessary Managers

as well as users were aware that it would require the organization to adapt to the ERP

system, but at the same time they wanted to continue the tradition of user participa-

tion they had good experience with and therefore an approach involving the users

from the very beginning and throughout the project were decided on.

Users’ attitude toward the system: Users, the ERP Project Manager and top

management at ALFA acknowledged the need for a new system and the intended

approach, thus the project stated out with wide acceptance.

Episode 1 - ALFA business processes and requirements specification: First all

business processes that should be part of the new system were described including

Finance, Purchase, Project Administration and Resource Management. A large num-

ber of users throughout the organisation were involved in the process, and a number

of simple business process models on different levels were produced using Power

Point as a tool. For each of the four areas knock-out criteria were defined. After the

Business processes were defined, they served as a common reference for discussing

the requirements focusing on input (data) triggering a process, steps within a process

and output from a process. More detailed requirements for each area were defined in

a dialogue between the Project Manager and the participating users. It was a long and

difficult process especially because it involved a large number of users who had little

or no experience defining requirements. The requirements should at the same time

reflect existing processes and be open towards processes within a standard system.

The users did not know what to expect from a standard system and to inspire them a

couple of standard systems were demonstrated by different vendors.

Alfa defined more than 800 detailed requirements which were simple and priori-

tised on a scale from 1-4. Finally all the requirements were included in a spreadsheet

and mailed to the candidate vendors.

Encounter 2: The requirement specification is finished; users from the four func-

tional areas were in charge of the requirement process and the users influence on the

process has not been challenged. There personal involvement is high and the expec-

tations to the new system high.

Users’ attitude toward the system: Acceptance (no changes from the antecedent

conditions).

Episode 2 - Evaluating candidate ERP systems:

The vendors performed a written

reply and for each requirement they defined too what degree the system could meet

the requirement, they used 4 categories: ‘Fully as standard’, ‘Customisation included

in future upgrades’, ‘Customisation not included in future upgrades’, ‘Not at all’.

Parallel with the requirements definition a set of criteria for evaluating the vendor

were defined, and knowledge about the industry and the vendors desire to understand

Alfas situation were among the more important criteria.

The three pre-qualified vendors were invited to demonstrate there system in an

all-day workshop using scenarios defined by Alfa. 10-15 users participated in the

workshops evaluating the system and vendor performance using an evaluation frame-

work. Finally 1-2 reference customers for each vendor were visited. An evaluation

report comparing the three candidate systems and the tenders from the vendors were

composed. The results from the evaluation process were summarized and presented as

quantitative and qualitative scores in a number of different areas.

Encounter 3 - Evaluation: Alfas board of directors decided to follow the recom-

mendation given by the project group and Oracle were chosen as Alfas new ERP

system.

Users attitude toward the system: The attitudes toward the systems are somewhat

mixed. Some users developed an equivocate attitude but acceptance is still the domi-

nation attitude. The users were in charge of the evaluation and the analysts in charge

of the demo. Some users, especially form project management, realise that the sys-

tems may not fulfil there needs. They have started to realise, that the approach for this

implementation; minimise customization and require the organization to adapt to the

ERP Package, will challenge there historical influence on the systems design, and

therefore there anticipated usefulness of the system.

Episode 3- Re-scoping: Due to financial difficulties the ERP project were asked to

cut the project cost by 5 million DKK before even starting. To re-scope the project

Alfas ERP project manager and user representatives from the four functional areas

together with consultants from Oracle implemented a ‘Conference Room Pilot’ a

quick examination of the original requirements and scope. For each requirement, the

implementation consultants would show the solution in Oracle, and the possibility of

cutting something was discussed. This process very quickly made it visible that it

would be necessary to add as well as cut requirements and scope. In the original re-

quirement specification process the users had relied on assumptions about what a

standard system would provide. Therefore the requirements now appeared to be in-

complete. At the end of the two weeks the 5 millions were found and a contract were

signed defining scope, price etc.

Encounter 4: A fixed price contract is signed with the vendor based on the origi-

nal requirement specification with adjustments decided on during episode 3.

Users’ attitude toward the system: Equivocation and some resistance, most users

have started to feel that the historic situation has changed. The users got to make the

re-scoping decisions, but the final result has to be approved by the steering commit-

tee. The project manager is driving the process very strictly to cut project cost and the

users have to rely on the consultants’ knowledge and judgment about the ERP sys-

tem. Most users have now realized, that the requirement specifications not necessarily

will help them achieving significant influence on the system’s capability, and a feel-

ing that the system will not provide what they asked for is developing. The process is

now challenging the users’ historic position of having significant influence.

Episode 4 – Configuration: In the following nine month three Conference Room

Pilots were conducted. In each pilot the system “to-be” was (re-)scoped at a more

detailed level and the configuration decisions were documented. The work was con-

ducted in small workshops where user representatives and consultants worked to-

gether; the users provided knowledge about the existing work practice (requirements)

and the consultants their knowledge about the standard system. The processes in the

ERP Package were guiding the work and Oracle’s process tool was used. The re-

quirement specification was used as a checklist.

Encounter 5: The first version of the new ERP system is finished.

Users’ attitude toward the system: Resistance and some rejection. Most of the user

representatives are disappointed with the results and know it will be difficult to “sell”

it to the users in there department. The functionality within resource management is

considered so poor, that the users have started rejecting the functionality. The con-

sultants were in charge of the implementation process, the capability of the ERP

Package is constraining the design and the requirement specification is used to evalu-

ate the progress of the work. The users lack experience in the configuration process

and knowledge about the capabilities of ERP Package, they are totally depended on

the consultants. They have all realized, that the new system will not meet the expecta-

tions of there peers and some of them feel much stressed reporting back to the peers.

Conflicting interests among the users is also influencing the process, most of the user

representatives feel, that the financial department is too dominant.

Episode 5 -Training and testing:

The project is under an extreme time pressure. In

the Alfa concern it is not allowed to implement a new financial system the last quarter

of a financial year, therefore the system have to go-live at the beginning of October.

Thus the training of the users takes place alongside the final testing and data conver-

sion.

Encounter 6: 8

of October 2003 Alfa’s Oracle solution went live.

Users’ attitude toward the system: A lot of resistance toward the system is building

up in the organization during episode 6. The users succeed at this late stage having

the resource management module taken out of the implementation because the func-

tionality in there opinion is to poor. The consultants were in charge of the configura-

tion of the system and the modifications to the system. However the user representa-

tives have taken over responsibility regarding training and testing, and the overall

responsibility for the socio-technical design.

Episode 6 – Go-live and stabilizing the system: Because of the time pressure many

reports were still outstanding and a lot of promising and nice functionality were left

to be implemented in a later phase. During the next months the users struggled with

the system. Some parts of the system they learnt to manage but others they refused to

use or used incorrectly thereby causing data quality problems as well as system mal-

function in other areas. After a very turbulent period the system were stabilized and

the most important reports were developed.

Encounter 7: An internal IT-competence centre was formed consisting of the pro-

ject manager and some of the user representatives, and a former Oracle consultant,

and a new project is decided on to improve the usefulness of the system.

Users’ attitude toward the system: Resistance/rejection. As the users became more

experienced using the system, they also became convinced that parts of it had to be

redesigned thus using there political influence to have the design of the system sup-

port there daily work. No significant pattern in some areas the users is in charge of

the process in others the members of the competence centre is in charge.

Episode 7 - The follow up project:

Some of the consultants participating in the

configuration had moved on to new project and some were still helping out correcting

errors. Members of the new internal Oracle competence centre were assigned the

roles of technology experts. The fit of the system were in some areas more problem-

atic then in others. Meetings were set up where people from the competence centre

met all user groups within Alfa. The analysts met the users with an open mind and all

issues reported were noted without considering the relevance or the reason; resulting

in a list of more than 500 issues. Afterwards the reasons for the issues were discussed

and the appropriate action decided. Some issues were met with end user education

and some with reconfiguration or customizations of the system; some were researched

thoroughly, but could not be solved due to the design of standard system.

Encounter 8: At the end of 2004 the follow-up project was completed.

Users’ attitude toward the system: More functionality is accepted. In general the

perceived usefulness of the system increased and some of the rejected functionality

were re-designed or just re-introduced and now accepted. The users in general gained

more self-confidence and they started to fight to get more influence on the socio-

technical design of the new system. Project managers are still fighting what they

perceive as very poor system design refusing to use some functionalities and have

project assistances and secretaries use the system on there behalf.

Episode 8 - Continuous improvement:

Users throughout Alfa and members of the

competence centre are working to increase the quality of use. To do so they are cus-

tomizing the software to change the original capabilities of the ERP Package, recon-

figuring the system and enacting the software. The relationship between the users and

the competence centre is in some areas problematic, but in other areas the relation is

very good and fruitful based on a more joint development approach.

Outcome: The project is being considered a success from a project management point

of view. Cost and time estimates (episode 3-5) were met, the functionality promised

were delivered and after a chaotic go-live the system is now used throughout the

organization and more functionality are implemented as an ongoing process. The

selection and implementation process was relatively participatory, users were in-

volved in the selection process, the scoping of the system, the configuration and im-

plementation, and last but not least the user’s issues that remained after the go-live

phase were collected and seriously addressed. Participation was encouraged and or-

ganised for. However the quality of use can be questioned, many users are still com-

plaining, that they lack knowledge to use the system correct, more powerful users

resist using functionality with what they consider poor user interface. Users partici-

pating in the ongoing implementation of new functionality are complaining about not

being able to understand the capabilities of the software and the consequences of

different design possibilities. Episode 3 and 4 left the organization with a lot of inter-

nal conflicts and frustration, influencing the users’ behaviour in the following epi-

sodes, and causing a lot of re-design and customizations years after the project offi-

cially finished in encounter 7.

3.2 Discussion

The purpose of this paper is to understand what made the users attitude toward the

system change over time. As we can see from the process model, the users were en-

thusiastic and actively involved in the first episodes, during episode 3 and 4 a dra-

matic change happened, that culminated during episode 5 and 6 having users reject

functionality and resist using the system. During episode 7 and 8 a more positive

attitude to the system was developed although the quality of use is still low in many

areas.

In the process model the outcome of an episode implies the preceding events [13]

therefore to understand what led up to the rejection and resistance in episode 5 and 6

the preceding episodes are examined. In episode 3 and 4 the user representatives

found them selves in a situation, where the consultants had taken over the design

process of the new system and the users had realised that the result would constrain

the organizational processes in ways the end users would properly not accept. How-

ever there was not much they could do to change the situation. Most of them had

themselves been involved in defining the requirement specification and choosing the

system, and a fixed prise contract had been signed with the vendor using the require-

ment specification as a basis for setting up the new system. At the same time, the

users had very limited knowledge about the ERP Package and its capabilities and

design options, and therefore there ability to influence the design was rather limited.

Furthermore interest conflicts between users from different functional areas were

causing sub optimization, having the overall perceived usefulness of the new system

deceased. Some of the user participants expressed frustration having to report back to

their peers about the progress of the project because they thought they had nothing

but bad news.

During episode 3 and 4 the user representatives were providing the consultants

with enough knowledge about Alfa’s organization to set up business processes within

the scope of the project. Instinctive many of the user representatives know the useful-

ness of the business processes were doubtful, however the design process did not

included activities evaluating the usefulness of the business processes giving them

arguments to reject the design.

In episode 5 and 6 the new system was presented to the end users. Most of them

had either been involved or had only very limited involvement in the previous epi-

sodes; therefore they had no loyalty conflict rejecting the new system.

Historically users in Alfa had had significant influence on the design and use of

software, and probably for a good reason. Most of the employees have a university

degree, there work are not easily automated, and they are knowledge workers being

expected to take responsibility for the result of there work. They are not easily told

just to do something. In episode 5 and 6 they were introduced to a new system that

did not successfully meet there needs, they had no part in the design and were given

very limited help to assimilate the new system. In response they were sending a very

strong signal; large part of the systems functionality were rejected completely or

enacted in ways that would cause no or very little change to the existing work prac-

tise. The user groups that during episode 3 and 4 had felt dominated by another user

group chiefly resisted and rejected the system.

In episode 7 and 8 the attitude toward the system is changing direction becoming

more positive. As a reaction to the resistance of the new system and the rejection of

functionality in episode 5 and 6 the competence centre in episode 7 goes into a dia-

logue with the end users, where the user organization’s perspective is in focus. The

users are now in a situation where they are being heard and have an opportunity to

influence the re-design of the new system although there understanding of the ERP

software’s capabilities and design options are still causing difficulties. In episode 8

the users influence on the re-design of the new system is continued. As users gain

more experience with the system, they help each others within departments and across

functional areas to understand the capabilities of the ERP software and find ways to

re-design or enact the system to support their needs. Much of the work takes place

without involving the competence centre or in a dialogue with them but on the end-

users initiative and terms.

4 Conclusion

Assimilation of a standard ERP system to an organization is difficult. User participa-

tion and involvement seems to be critical for success. However, as this case study

shows even the best intentions for user involvement may come to nothing. A case

study of a five year ERP implementation process reveals that a main reason may be

that the perception of usefulness in any given phase of the implementation is heavily

dependant on preceding events – the process. User-led development was the antece-

dent condition in the case organization, and the general perceived usefulness of in-

formation systems was high. The case organization intended to continue the tradition

having users participate and influence the design of the system when implementing an

ERP system. However, a process model analysis shows that in reality the consult-

ants/IT-experts take charge during the configuration and customization process chal-

lenging the status qua. Alfa is not aware, that lack of knowledge about the techno-

logical options, a fixed price contract and a strict timetable left them with no choose.

As a response to the change in user-developer dynamic the users’ attitude towards the

ERP system change from accepts/equivocation to resistance/rejection and the users

are fighting to regain control. When succeeding to regain control almost two years

after go live their attitude toward the ERP system changes again. In summary the case

analysis show, that the users attitude toward the system change between acceptance,

equivocation, resistance and rejection over time depending on three things: (1) Dy-

namic between user and consultants, (2) Dynamic between different user groups, and

(3) Understanding of technical, organizational and socio-technical options.

References

1. Markus, M.L. and C. Tanis, The Enterprise System Experience – From Adoption to Suc-

cess, in Framing the domains of IT management: Projecting the future through the past,

R.W. Zmud and M.F. Price, Editors. (2000), Pinnaflex Educational Resources: Cincinatti,

USA.

2. Shang, S. and P.B. Seddon, Assessing and Managing the Benefits of Enterprise Systems:

The Business Manager's Perspective. Information Systems Journal, (2002). 12: p. 271-299.

3. DeLone, W.H. and E.R. McLean, Information systems success: The quest for the depend-

ent variable. Information Systems Research, (1992). 3(1): 60-95.

4. Boudreau, M. and D. Robey, Enacting Integrated Information Technology: Humn Agency

Perspective. Organization Science, (2005). 16(1): p. 3-18.

5. Pries-Heje, L. ERP misfits: What is it and how do they come about? 17th Australasian

Conference on Information Systems. (2006). Adelaide, Australia.

6. Davenport, T.H., Putting the Enterprise into the Enterprise System. Harvard Business

Review, (1998).

7. Kien, S.S. and C. Soh, An Exploratory Analysis of the Sources and Nature of Misfits in

ERP Implementations. 1 ed. Second-wave Enterprise Resource Planning Systems, Imple-

menting for Effectiveness, ed. G. Shanks, P.B. Seddon, and L.P. Willcocks. (2003), Cam-

bridge University Press. 373-387.

8. Robey, D., J. Ross, and M. Boudreau, Learning to Implement Enterprise Systems: An

Exploratory Study of the Dialectics of Change. Journal of Management Information Sys-

tems, (2002). 19(1): p. 17-46.

9. Nah, F.F.-H., K.M. Zuckweiler, and J.L.-S. Lau, ERP Implementation: Chief Information

Officers' Perceptions of Critical Success Factors. International Journal of Human-Computer

Interaction, (2003). 16(1): p. 5-22.

10. Kawalek, P. and T. Wood-Harper, Finding of Thorns: User Participation in Enterprise

System Implementation. Advances in Information Systems, (2002). 33(1): p. 13-22.

11. Esteves-Sousa, J. and J. Pastor-Collado. Towards the unification off critical success factors

for ERP implementations. in 10th Annual Business Information Technology conference.

(2000). Manchester, UK.

12. Barki, H. and J. Hartwick, Rethinking the concept of user involvement, and user attitude.

MIS Quarterly, (1994). 18(1): p. 59-79.

13. Newman, M. and D. Robey, A social process model of user-analyst relationships. MIS

Quarterly, (1992). 16(2): p. 249-266.

14. Klein, H.K. and M.D. Myers, A Set of Principles for Conducting and Evaluating Interpre-

tive Field Studies in Information Systems. MIS Quarterly, Special Issue on Intensive Re-

search, (1999). 23(1): p. 67-93.