An Investigation of Customization in ERP System Implementations

IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 56, NO. 4, NOVEMBER 2009 663

An Investigation of Customization in ERPSystem Implementations

Marcus A. Rothenberger and Mark Srite

Abstract—This research investigates why certain enterpriseresource planning (ERP) system adopters have pursued highlevels of software customization during implementation de-spite the generally accepted best-practice heuristic of limitingcustomization. Qualitative data from ERP adoption projects andconsultants working with ERP implementations have been col-lected. This study empirically identifies customization drivers andexplains their relationship to customization. The results suggestthat high customization may occur because of: unnecessary re-development of functionality that is available in the ERP systemstandard, resistance to change based on cultural issues and lowproject acceptance, insufficient weight given to the implementa-tion team’s recommendations, and the implementation team’s lackof opposition to customization requests. The results of this studyalso explain how these problems occur and why they lead to over-customization.

Index Terms—Case study, enterprise resource planning (ERP),qualitative study, success factors, system customization.

I. INTRODUCTION AND MOTIVATION

ENTERPRISE resource planning (ERP) implementationspose major challenges to organizations [1], as many of

them fail in their early stages or substantially exceed theprojected cost [2], [3]. A number of studies have investi-gated ERP implementation success factors [4]–[15]. Thoughresults from these studies have been diverse, recurring themeshave emerged, such as management support, project teamperformance, the implementation process, education andtraining, as well as change management and minimal ERPcustomization. This study investigates why many organizationsfail to achieve minimal customization.

In all ERP installations, some degree of system customiza-tion is required. Even though, packaged applications are de-signed to work in different organizations, or even in differentindustries, they often do not provide all the functionality neededin a specific business [16]. Nevertheless, customizations thatinvolve extensive additions to the ERP system or modifica-tions of ERP system code may compromise a project’s success,because too much customization increases costs and limits main-tainability. In particular, upgrading highly customized projectsis very labor-intensive because customizations must be re-

Manuscript received February 1, 2007; revised February 15, 2008, September16, 2008, February 6, 2009, and May 20, 2009. Current version publishedOctober 21, 2009. Review of this manuscript was arranged by DepartmentEditor R. Sabherwal.

M. A. Rothenberger is with the Department of Management InformationSystems, College of Business, University of Nevada, Las Vegas, Las Vegas, NV89154-6034 USA (e-mail: [email protected]).

M. Srite is with the Management Information Systems Area, Sheldon B.Lubar School of Business, University of Wisconsin-Milwaukee, Milwaukee,WI 53201 USA (e-mail: [email protected]).

Digital Object Identifier 10.1109/TEM.2009.2028319

aligned to the upgraded system or even rewritten. Several priorstudies [7], [8], [10], [13]–[15] stress the impact that the deci-sion to customize has on ERP adoption success, as a successfuladoption must align software and business processes to matchone another. Considering the existing processes and keepingcustomization to a minimum are both important [14]. A com-parative case study of two ERP implementations [10] showedthat a lack of acceptance of ERP standard processes contributedto the failure of the project. Another study, which analyzed theresponses of 86 organizations [15] confirmed the importance ofminimal customization for ERP implementation success. It iscrucial that the right decisions are made to smoothly integrate thesystem into the organization [17]. These decisions include whichcustomizations of the system are necessary and which changesto the existing business processes can be made. Such decisionsaddress the dilemma that all ERP adopters continuously faceduring the implementation: whether to change the business pro-cess to fit the ERP system or whether to change the ERP systemto fit the business process. To minimize customization, the de-cision to change the ERP system should only be made in rarecircumstances, e.g., when a business process cannot be changedwithout losing a competitive advantage. Furthermore, such de-cisions require cooperation between the information technology(IT) and the operational departments, following formal definedactivities, which are part of a change management process.

Thus, change management is instrumental to ERP imple-mentation. In fact, it was listed as one of the top five fac-tors in a study of chief information officer (CIO) perceptionsof critical success factors for ERP projects [17]. The analy-sis of two implementation cases [7] confirms this notion asit identifies change management as one of the major successfactors. The issue of management and employee readiness toimplementing business process change is a common charac-teristic of successful implementations. In a case study of afailed SAP R/3 implementation [13], the absence of changemanagement inhibited the broad involvement of employees inthe implementation of business changes required for the suc-cessful adoption of the ERP system standard processes. Theimportance of business process reengineering and minimal cus-tomization was further confirmed by a literature-based studyon critical success factors for ERP implementations [8]. Nahet al. [8] identified both as part of 11 key factors for implemen-tation success. They also called for further empirical researchin this area.

Although the difficulties associated with highly customizedenterprise system implementations are widely known and ac-cepted [8], [18], [19], many organizations appear to pay littleattention to this potential threat when it comes to their ownimplementations [20]. It remains unclear why some businesses

0018-9391/$26.00 © 2009 IEEE

664 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 56, NO. 4, NOVEMBER 2009

Fig. 1. ERP Modification options (darker shading indicates a higher likelihood that modification must be redone after upgrade).

choose to extensively customize, while others manage to mini-mize customizations.

Past research suggests that high ERP customization con-tributes to project failure. This study will extend prior researchby clarifying how and why high customization occurs, and de-tailing ways it can be prevented. The study will identify thefactors that drive system modifications and explore how thesefactors affect the decision to customize by analyzing the under-lying mechanisms of the relationships between these factors.This translates into the following research questions.

1) What are the factors that promote ERP system customiza-tion?

2) How do these factors lead to ERP system customization?

A. Overview of Customization

Customization involves the modification of an ERP soft-ware package to match the organization’s existing business pro-cesses [21]. Business process modifications involve changingthe business processes to match the ERP package [22]. Orga-nizations that adopt ERP systems have multiple options whenfitting the system to their business processes. Brehm et al. [23]discuss a typology of such ERP customization approaches:

A business may configure a system to its needs by selectingappropriate system components and by setting parameters thatallow the organization to modify the system within the bound-aries set by the developers of the enterprise application. Whilethis may address many customization needs, it may not accom-modate all existing business processes. Alternatively, organiza-tions can implement third-party packages (or bolt-ons) that aredesigned to work with the ERP package and supplement the ERPfunctionality. To address unique modification needs, businessescan also build custom features on top of their ERP platformsby using the ERP system language or standard programming

languages. This requires additional program code development,but it does not require a modification of existing system code.Consequently, in the case of an upgrade, the functionality canbe retained if the developers of the new module adhere to theERP vendor’s interface standards and naming conventions.

With respect to future systems releases, ERP vendors gen-erally guarantee not to change certain standards that specifyhow one can connect to other applications; however, vendorswill sometimes phase out the guarantee for particular interfacestandards with a multiple-year advance notice. Such bolt-onsintegrate into the ERP system without requiring modificationsof the ERP system source code. Lastly, the ERP system codecan be modified to fit an organization’s needs. This requiressubstantial development effort and specialized expertise. Thisis problematic, since the code modification may need to be re-done when the system is upgraded to a new version (installationof a new version would cause all modifications to be overwrit-ten). Fig. 1 summarizes the different ERP system modificationoptions.

For the purpose of this research, customization is definedas building custom features by using standard programminglanguages or the ERP system’s language, changing the ERPsystem code, and/or including third-party packages that requiresome degree of programming to implement.

B. Structure of the Paper

The next section reviews literature related to ERP system cus-tomization. Following it, the methods employed for data collec-tion and analysis are discussed. Then, the data and a summaryof the ERP adoption projects that have been investigated in thisstudy are presented. Next, customization drivers are identifiedand how they emerged from the analysis is explained. Finally,the paper concludes with a discussion of the contributions andlimitations of this study.

ROTHENBERGER AND SRITE: INVESTIGATION OF CUSTOMIZATION IN ERP SYSTEM IMPLEMENTATIONS 665

II. RELEVANT LITERATURE

A. Drivers of Customization

We reviewed the extant literature on ERP success factorsby focusing on the outcome variable of our study: level of cus-tomization. While low system customization has been discussedas important for ERP implementation success [8], [13], [15],prior research offers little explanation as to how high customiza-tion occurs. In addition to customization as an ERP successfactor, past research has identified several other success factorsthat may be relevant to customization. They relate to projectmotivation, the consultant relationship, the extent of employeeinvolvement, and the organizational culture. Robey et al. [24]have contrasted process change approaches in ERP adoptions.Their study found that expecting strategic value from an ERPimplementation drove the process change approach; as businessprocesses need to change to meet the ERP standards, the processchange approach may affect the extent of customization. Theyprovided an example of an implementation that resulted in highchanges to the ERP system because the implementation lackedstrategic motivation [24].

The importance of the consultant relationship has beenstressed by Al-Mudimigh et al. [25]. Consultants have criticalcapabilities and an in-depth knowledge of the software. Conse-quently, consultant knowledge is a major factor in a successfulERP implementation [26] and its transfer to the organizationis critical [27]. Thus, effectively managing the consultant rela-tionship can lead to greater configuration knowledge [24], andconsequently, better decisions about customization.

Akkermans and van Heldon [4] found cooperation betweenbusiness functions and involvement of operational depart-ments to be a prerequisite for project acceptance and success.Project acceptance helps when asking operational departmentsto change business processes to fit the needs of the software inorder to minimize customization. Davenport [29] emphasizedthat the needs of the business and the needs of the softwarecan only be balanced if the operational side of the business isinvolved; he strongly cautions against having a project solelycontrolled by IT people. Sarker and Lee [28] note that a balancedimplementation team, one that contains members from differentorganizational areas, can lead to successful implementations.

The ability to change is crucial to minimizing customiza-tion, as an ERP adopting organization must be able toimplement the ERP-supported practices as much as possiblein order to minimize customization. Organizational culture canplay an important role in a company’s ability to change. Simon[30] reported in a case study that the inability of an organiza-tion’s units to compromise about business process changes dur-ing an ERP adoption stopped the implementation project. Hongand Kim [6] discussed the role that supporting and opposinggroups play in resisting ERP adoption. Aladwani [31] discussedresistance on an individual level; this resistance is triggered byfear of personal disadvantage. Davison [32] looked specificallyat how culture interacts with ERP implementations. He notedthat in cultures with high-power distances, there is “consider-able reluctance to accept empowering initiatives” [32, p. 110].This occurred even though employee empowerment, including

that related to ERP implementation, should be central to reengi-neering efforts [33]. Davison also implied that employees withlower levels of project acceptance were more resistant to changein their work environments.

To sum up, it can be argued that, based on prior literature, theextent of customization may be related to project motivation,the consultant relationship, employee involvement, and organi-zational culture. As these insights were findings embedded inthe context of ERP success factor studies, they do not provide acomprehensive set of drivers for the level of customization, nordo they provide an explanation as to how or why high customiza-tion occurs. Nevertheless, we are using these tentative drivers asa starting point for our study and have incorporated the conceptstaken from them into our qualitative interview outline.

III. QUALITATIVE RESEARCH APPROACH

Although the research discussed in the previous section hasidentified several drivers for high ERP system customization,the focus of these studies was not the development of a compre-hensive set of the causes of high customization. While the priorliterature provides a theoretical starting point in this investiga-tion, we do not want to limit our results to confirming previouslyidentified customization drivers. Instead, we use an exploratoryapproach [34]–[36] to expand existing notions about what leadsto high customization in ERP implementations by analyzingdata from multiple implementation cases.

A. Data Collection

In order to obtain the maximum possible insight, site selectionshould be guided by diversity and the sites’ potential for mak-ing a contribution to the study (theoretical sampling), rather thanby randomness [37]. To maximize the variety of managementstyles, industry-specific contexts, and organizational cultures,the sites were selected from different industries and differentgeographic regions. The projects investigated in the case studieswere all implementing SAP R/3, which is the most widely usedERP system. While some ERP software packages may be easierto customize than others, we aimed at identifying customizationdrivers other than those based on differences in vendors. Iso-lating the analysis from vendor-specific customization issuespermitted us to focus our investigation on the organizationalcustomization drivers. Limiting the study to adopters of oneparticular ERP software package allowed for valid cross-casecomparisons.

In each ERP adoption project, separate semistructured in-terviews were conducted with the technical lead and the or-ganizational lead. Each interview took 45–75 min, and wasrecorded, transcribed, and analyzed [38], [39]. The semistruc-tured interviews included demographic information, questionsabout ERP adoption (the questions were based on the priorconstructs discussed in the literature review), and open-endedquestions that let new insights emerge. Additionally, interviewswere conducted with three consultants to further corroborateand strengthen the validity of our findings. The interviews wereconducted in three geographic regions. In North America andin southern Europe, the interviews were conducted in English.


In central Europe, the interviews were conducted in the locallanguage. The translation of the interview protocols was verifiedvia back translation by an independent native speaker.

As a pilot test, an interview was conducted with an SAP expertwho was not related to the case organizations. This ensured thatquestions we asked were correct and unambiguous. The SAPexpert who participated in the pilot interview had been involvedin multiple SAP system implementations. The feedback fromthe pilot interview was incorporated into subsequent interviews.

Although case interviews are often supplemented by datafrom other within-case sources of evidence such as quantitativefirm measures or implementation documents [36], case studiescan rely on interviews as a single source of evidence if circum-stances warrant [24], [40], [41]. The cases in this research consistof the implementation projects, rather than entire organizations.Thus, we have followed the data collection approach taken byRobey et al. [24] in a study of multiple ERP implementationprojects where interviews with key team members served as asingle within-case source of evidence. We were able to obtaina detailed picture of the implementation based on interviewswith the two key team members in project teams that averaged16 internal full-time employees. All assessments were based onconsistent information provided by different participants fromeach project, which assured the internal validity of the emer-gent constructs [42]. The data collection approach allowed forfollow-up clarifications, but this was rarely required as we foundthat the interviewees of each firm largely agreed on substantivematters. Any discrepancies between team members were minorin nature and did not pertain to the constructs of the model. Allthe constructs and causal relationships that emerged from ourresearch were based on the insights of multiple implementationcases and additional ERP adoption consultant interviews; there-fore, the results of the study were based on multiple sources ofevidence across organizations.

The interview process aimed at identifying the customizationfactors and at obtaining a detailed understanding of those fac-tors’ effects on the implementation decision [36]. Case studyresearch is an appropriate way to identify such factors [43], butits particular strength is its ability to explore why and how thesefactors occur in organizations [37], [44]; this strength was uti-lized in the study to gain a better understanding of the complexconcepts in ERP adoption.

B. Analysis Process

The comparison and analysis of multiple case studies allowsthe researcher to develop a theory that emerges based on the caseinsights [39]. Eisenhardt [39] discussed an approach that com-bines the earlier technique of grounded theory building [45] withthe more recent method of case study research [36]. Eisenhardt’smethodology deviates from the philosophy of a clean slate thatwas previously closely coupled with the Glaserian groundedtheory research school of thought [45]. Her approach is con-sistent with the later Straussian school of thought to groundedtheory research [46] in that it allows existing theory to guidethe research. In fact, Eisenhardt’s approach is positivistic be-cause it suggests that questions for the case interviews can be

developed by using literature-identified constructs; yet, it allowstheory building from such positivist origins. Eisenhardt arguesthat confirming initially identified constructs through case stud-ies strengthens the constructs of the resulting model throughadditional triangulation [39].

Open-ended questions and a flexible data collection strat-egy (one in which questions can be added or refined in subse-quent semistructured interviews so that emerging themes can beprobed) ensure that constructs beyond these, identified by priorliterature, can emerge [39]. Such alterations to the interviews arelegitimate in theory-building research because the researcher istrying to understand each case individually; thus, additions thatcontribute to a better emerging theory are desirable [39]. Thisprocess led to an improved set of questions after completing theinitial set of interviews. The questions remained unchanged af-ter the collection and analysis of the fourth case, at which pointno further themes requiring additional probing emerged. Thissuggested that the constructs were saturated.

The analysis approach involved multiple iterations betweendata collection and analysis during which the researchers de-veloped the emergent theory based on comparative case analy-sis. Within-case analysis was conducted by developing detailedcase study write-ups for each adoption project [39]. Such analy-sis helps the researchers “become intimately familiar with eachcase as a stand-alone entity” [39, p. 540] and “allows the uniquepatterns of each case to emerge before investigators push togeneralize patterns across cases” [39, p. 540]. The researchersfocused on those patterns that explained why high customiza-tion occurred or did not occur in each case organization. SectionIV discusses the customization drivers in detail in the contextof individual organizations (the columns of Table III summa-rize the customization drivers that emerged in the individualorganizations as a result of the within-case analyses).

Based on the individual case analyses, the set of prelimi-narily customization drivers and their effects in an organizationevolved during the ongoing data collection. Additional case dataconfirmed or refined earlier notions and expanded the concepts;this was achieved through revisiting what was learned after con-ducting each interview, and subsequently, by evaluating how thecurrent case differed from previous ones [39]. As our under-standing of the customization drivers was developed (from theincremental analysis of the case data), each additional case wasadded to this understanding, but at a diminishing rate [37]. Newcase data were collected until additional case studies did not fur-ther change the emerging results. In total, data were collected oneight cases. The number of cases used in the study was consistentwith Eisenhardt [39], who suggests that four to ten case sites aresufficient for comparative case study research. This saturationsupports the notion that the important factors were revealed, andthat the results that emerged were complete. In a second analy-sis phase, cross-case patterns were identified by examining thesimilarities and differences between the cases. Each constructand each relationship between constructs (these represent thecustomization drivers) can be traced back to a specific situationthat occurred in certain cases. For each preliminary customiza-tion driver that was identified in the first phase of the analysis,we identified the cases in which the same driver led to high


Fig. 2. Summary of how high customization occurs.

customization. Identification of a group of cases in which thesame phenomenon occurred, confirmed a customization driver.Section IV presents the case evidence from the groups of casesthat support the customization drivers (the rows of Table IIIsummarize how each customization driver is supported acrosscases, and Fig. 2 presents the resulting model).

For both phases of the analysis, customization drivers had tobe identified, and then coded in the case interview transcripts.Both researchers independently coded the individual cases. Thisresulted in few differences (they occurred in less than 10% of theconstructs), and these differences were fairly minor in nature.In order to consolidate the differences, they were identified, andthen both researchers explained their reasoning to each other.The researcher who did not conduct the interviews assumed therole of a resident devil’s advocate. This brought a fresh view tothe analysis, as this researcher had not met the informants [39].Through this process, consensus was reached. Having two peo-ple independently code the qualitative data reduced the likeli-hood of statements being incorrectly interpreted [43]. In all thecases where differences existed, the resolution emerged as moreof a clarification than a major discrepancy. Since each factordescribes a situation that may or may not occur in an organiza-tion, we did not expect to see all factors in all implementationprojects. In other words, a situation represented by a constructmay be present in a number of projects, yet not in all projects.

Construct validity of qualitative research can be enhanced bybasing important elements of the emerging theory on multiplesources of evidence [37]. To ensure the rigor of the study in thisrespect, additional qualitative data were collected from threeconsulting firms that were operating in the same, respective,three geographic regions as the ERP adopting organizations;however, the consultants were not related to the implementationprojects under investigation. Through additional semistructuredinterviews, the expert opinion of three consultants with extensiveERP adoption experience regarding the drivers of customizationdecisions was sought. These were identical in content and scopeto the ones conducted with the case organizations. The resultsof the study were based on evidence obtained from the adoptingorganizations, as well as expert ERP consultants. To support arelationship between two constructs, a case must provide evi-dence as to how one construct led to the other. Such evidencewas usually obtained when participants explained why or howthe factors occurred. The same applied to the consultant inter-views. Such explanation building in a case analysis ensured theinternal validity of the results [36].

C. Cases and Consultant Interviews

Eight ERP adoption cases and three consultant interviewsprovide the empirical foundation for this study. This subsection


TABLE ICASE SUMMARIES

presents an overview of the implementation projects and theconsultants, and the subsequent section discusses the specificinsights obtained from the data analysis.

1) ERP system implementation cases: Table I summarizeskey information about the ERP adoption projects, whileTable II provides an overview of the modules implementedacross participating organizations. In the Appendix, wesummarize each of the eight implementation projects. Theparticipating organizations differ with regard to key expe-riences, like the extent of customization, the role of con-sultants, organizational culture, internal knowledge aboutERP systems, the involvement of operational departments,the project lead, and the motivation for the adoption. Asnoted previously, a high diversity across the case expe-riences increases the likelihood that all important issueswill be observed during the course of the study.

2) ERP system implementation consultants: As a secondsource of evidence for the customization drivers, threeconsultants’ expert knowledge about ERP customizationwas probed through a series of semistructured interviews.The Appendix provides a summary of each consultant’simplementation experience.

IV. CUSTOMIZATION DRIVERS

Earlier, Section III presented the process employed for con-ducting the interviews, coding, and analyzing the transcripts.

This section develops the results of this study by discussing theinsights that the implementation cases and the consultant dataprovided.

A. Relationships Between Customization Drivers

The findings that follow are based on analyses of the case andconsultant interviews. The relationships that emerged from theanalysis of the qualitative data are summarized in Fig. 2. Ac-cording to these findings, duplicate implementation of existingsystem functionality, the implementation team’s determinationto avoid system customization and resistance to change affectsERP system customization. Several project characteristics, re-lated to specifics of the implementation process, promote thesethree scenarios. These project characteristics are further pre-ceded by a set of preproject characteristics. Fig. 2 groups thesethree types of customization drivers into three columns. Thefollowing subsections discuss the relationships between pairsof issues. Each heading is followed by letters in parenthesesthat correspond to the labels used in Table III and Fig. 2 toidentify the relationships.

1) Experience of Implementation Team—Duplicate Imple-mentation of Existing Functionality (A): An inexperienced im-plementation team may custom develop functionality that isalready available in the standard system, if team members arenot aware that it is available at the time of implementation.Such duplication of functionality happens because of limited


TABLE IISAP MODULES ADOPTED BY CASE ORGANIZATIONS

knowledge about the standard system. It is typical for organiza-tions to rely on consultants for this type of system information.For example, EngCo’s interviewee stressed that “(The consul-tants’) role was to let us know what the system can do.” InEngCo’s case, the consultants fulfilled their role, and duplicationof functionality was not an issue. Other companies were not asfortunate. FoodBevManufCo’s found that “consultants did notfully know the SAP functionality . . . , because of their inexperi-ence.” All three consultants articulated that limited knowledgeabout the standard system led to unnecessary customization.Consultant 1 explains the danger that such a situation bears:

An inexperienced consultant may cause excessive customization,(because he) may not recognize that certain customer requirementscan be implemented using the standard system; instead, he wouldrecommend customization. (Consultant 1)

2) Experience of Implementation Team—ImplementationTeam’s Determination to Avoid System Customization (B): Aninexperienced implementation team may be less successful inlimiting customization of the system to only the necessary func-tions. If such a team faces resistance from the business regardingchanging organizational processes, it may not be able to con-vince the decision makers that keeping system modifications to aminimum is important. As a result, the implementation team willcustomize the ERP software, even in situations where reengi-

neering existing business processes would have been the bet-ter choice. UtilCo1, FoodBevManufCo, and FinInst1 all facedthis problem. FoodBevManufCo’s case illustrated this situation.Initially, the consultants advised against system customization.However, management did not want to modify existing businessprocesses, and in the end, the consultants relented and did whatmanagement asked. A more experienced implementation teamwould have been able to make a stronger case for staying withthe system standard.

Other organizations also encountered some degree of resis-tance to change; however, the implementation teams in thesecompanies were able to control the resistance by makingstrong cases against system modifications. FinInst2, EngCo,and UtilCo2 are in this category. In EngCo, for example, the op-erational departments felt that many existing business processesshould be retained because they were of strategic importance;however, the implementation team was knowledgeable enoughto differentiate between truly strategic processes and those thatcould be modified to the SAP standard. An EngCo employeeemphasized that “IT was savvy enough to push back (if theywere asked to add) something that wasn’t really a strategic pro-cess.”

Consultant 3 stressed that often management must be con-vinced that business processes should be modified to fit the


TABLE IIIEMPIRICAL SUPPORT FOR THE CUSTOMIZATION DRIVERS

standard, especially when respective operational departmentswere pushing for system customization. Consultant 1 explainedthat his firm changed the way it handled customers who did notwant to change business processes as it gained experience.

In the beginning, we did not resist high customization, because oursubsidiary was new. We had few own consultants; they were rotatingfrom (another country). With 30 consultants that change every week,the customer cannot be controlled, thus the customization cannot becontrolled. That’s why we later had dedicated teams, local resources,constant communication with the customer, etc. We had shifted.(Consultant 1)

3) Reliance on Consultants—Implementation Team’s Deter-mination to Avoid System Customization (C): Overreliance onconsultants affects the implementation team’s understanding ofthe business and its ability to assess whether an existing busi-ness process can be modified without disadvantages. UtilCo1’simplementation was mostly controlled by consultants. A com-pany employee pointed out that “many consultants just cameout of school and did not have any actual business experi-ence.” High reliance on the consultants, a limited involvementfrom the operational departments, and the limited experience ofthe implementation team meant that when operational depart-ments wanted to keep their existing processes, they were not

challenged. FinInst1 also relied on consultants’ knowledge fortheir SAP adoption. The team’s business knowledge only camefrom talks with the operational departments whose requirementswere mostly translated into customizations, rather than changesto the existing business processes. The consultants also empha-sized that clients should be in-charge of the project: Consulant 1believed that low customer control is associated with risk, asexternal employees do not understand the customer’s business.Consultant 2 expressed that high reliance on consultants causesdetachment from organizational needs, and that this can ad-versely affect the extent to which customization occurs.

Another danger of relying highly on consultants is “profitmaximization,” a term that was used by one of the consultants.This refers to the practice of some consultants who take advan-tage of the fact that they bill by the hour. As customizations withextensive code development require more billable hours, con-sulting firms have an incentive to agree with customizations,even when they are not in the best interests of the client. Aclient that relies heavily on a team of consultants is particularlyvulnerable to such practices. Although this problem can be aresult of deliberate ill advising, it can also occur after consul-tants’ unsuccessful attempts to counter resistance to change inthe organization (e.g., FoodBevManufCo). At some point, the


consultants may give up and give the client the customizationsfor which the client has asked. The fact that a consulting firmincreases its revenue by supporting customizations is merely anadded benefit. In FinInst1, one department was very reluctantto change existing business processes, and the organization washighly dependent on the consulting firm for the implementation.The consultants did not counter the resistance to change in thedepartment; an employee explained the consultants’ motivation:

They viewed (the customizations requested) as a stable source ofrevenue, and they made themselves irreplaceable. (They acted as a)developer for the operational department and not as a partner of IT.(FinInst1)

Consultant 1 confirmed that his firm engages in customiza-tions if the customer insists. However, he wants to make sure thatthe client is aware of the consequences. He makes the client com-pany acknowledge in writing that customizations may requireadditional work during future upgrades. Consultant 2 pointedout that there are some consulting firms who are engaging indeliberate profit maximization.

4) Involvement of Operational Departments—Implementa-tion Team’s Determination to Avoid System Customization (D):Knowing about the business not only provides necessary ex-pertise to an implementation team, it also gives the team’s cus-tomization decisions credibility within the business departmentswhose acceptance is required. Many organizations place busi-ness unit employees with specific functional knowledge ontothe teams. Such placements promote good decisions about cus-tomization. An UtilCo2 employee emphasized that “involvingthe business from the beginning is important in doing pro-cess (re)design.” A participant at BusPrManufCo explained thatputting people from the business onto the team made for fast de-cisions because no one had to go back and forth to the businessunits. How operational involvement benefits a team’s determi-nation to avoid system customization is summarized by thefollowing statement by Consultant 1:

The most important (thing to address in an implementation) is (. . . )internal knowledge in the form of a good internal team from thecustomer that knows the business processes of the company, and iswilling to reengineer and take things forward. (Consultant 1)

ConsPrManufCo’s implementation team fared well becauseit made the right decisions with regard to these issues. The com-pany did not overly rely on external consultants and it involvedthe business in the project. In fact, in all, but the early stages,the project was led by an internal employee from the businessside. As a result, the company was able to implement SAP withlow customization expressly because its implementation teamhad the knowledge and the capability to change the businessprocesses when necessary.

5) ERP Project Acceptance—Resistance to Change (E): Theimplementation of ERP standard processes normally requiressupport from the operational departments of the organiza-tion, because it involves changing existing business processes.Change is necessary if the legacy processes are different fromthe ERP system standard, but do not provide any advantagesover the best practices that the ERP system prescribes. Con-sequently, an organization that is resistant to change is oftenreluctant about reengineering even ordinary processes if they

differ from the ERP best practice, and they are reluctant evenwhen the existing business processes can be modified without aloss of operational functionality. This can lead to unnecessarysystem customizations. Resistance to change is driven by thethree factors that are discussed in this and the two subsectionsthat follow.

ERP project acceptance impacts resistance to change. Theimplementation of an ERP system provides an opportunity forthe entire firm to improve not only the IT, but also to improvethe business by streamlining, updating, and aligning the way itconducts its operations. If all parts of the organization recognizethis, decision makers and employees will likely accept the or-ganizational changes. In BusPrManufCo and ConsPrManufCo,widespread acceptance of the goals of the ERP implementa-tion promoted low resistance to change. A participant fromConsPrManufCo described the low resistance to change envi-ronment that came from a broad organizational project accep-tance:

One of the standing things was that we do not modify SAP code.And to do so would require an act of God. (To change it, there) has tobe a compelling business reason. (. . . ) That was something that wasbelieved in wholeheartedly all the way throughout (the organization).(ConsPrManufCo)

Consultant 1 also stressed that seeing the business benefit ofan ERP project leads to greater willingness to adopt the standardprocesses of the system. Consultant 2 explained what happenswhen there is no organizational buy-in:

(If there is low acceptance of the system), no department of theorganization will be willing to accept that change is necessary (. . . ),there will be very low flexibility, and then the whole thing becomesvery stagnant and often the software must be modified. (Consultant 2)

Consultant 3 confirmed that a company that “recognizes theimpact (of an ERP implementation) on the longer term strategyfor the organization” will be more willing “to embrace change.”

6) Risk Taking—Resistance to Change (F): Organizationalchange that affects the core processes of a company is normallyassociated with risk to the firm. The willingness to accept suchrisk determines the acceptance rate of such an organizationalchange. Because of diverse organizational cultures, the toleranceto risk differs across firms. One culture may be driven by thehistory of the organization, another by the regulations that affectit. UtilCo1 is government-owned, and accountable to legislatorsand unions. This promoted a culture of low-risk taking. Oneemployee explained how resistance to change developed in thiscontext:

Convincing the decision makers to change business processes is notimpossible, but it is difficult. The company is very sensitive to legis-lation and the budget is controlled by the House of Representatives.(. . . ) When processes change, it had to be negotiated with the unions.(UtilCo1)

FoodBevManufCo also faced difficulties when it tried to con-vince departments to change their existing business processes.The participant described the firm as “not very keen to makechanges” and as “bureaucratic.” ConsPrManufCo was in a sim-ilar situation, and an employee attributed that to the fact that itis a “100-year-old manufacturing company” where “processes


have grown for over 100 years.” Consultants 1 and 3 also sup-ported the notion that certain organizations are more resistant tochange than others based on their willingness to accept the riskthat is associated with such changes.

7) Fear of Personal Disadvantage From Change—Resistance to Change (G): Organizational change can also beassociated with fear that personal disadvantage will result fromthe change. Individual decision makers or employees, moti-vated by such fears, may resist organizational change. EngCo,UtilCo1, UtilCo2, and ConsPrManufCo all faced this issue tovarious extents. The participant from UtilCo2 stressed that “itis education that gets you over the hurdle.” This may be, partic-ularly, true if the fear is not justified. For example, an intervie-wee in UtilCo1 shared that although some employees feared alayoff, no such plans existed. In fact, UtilCo1 provided contin-ued employment, but in different positions, to staff affected bythe implementation. (Granted employment in a different posi-tion might still have been considered a disadvantage if the newposition was perceived as less desirable.) FoodBevManufCo’semployees’ fear was not associated with lay offs. They feared“that change may cause them to lose knowledge and authority.They feel that they may have additional problems, that changeis risk.” Such concerns may make employees not want to sharetheir knowledge. They may feel that their insights translatedinto a documented process will let anyone do their job, and thatthis will cause a loss of leverage and power. An interviewee ofFinInst1 explained:

For some people, it was difficult to leave the established path; thisapplied from the user all the way to the top of the organizationalhierarchy. (. . . ) Some was rooted in the fact that people don’t wantto share their secrets of the trade. Their knowledge is undocumented,and thus, makes them irreplaceable. The project required them to putin writing what they know, so that anyone can do it. The fear wasthat they loose their prior monopoly and that the change may makethem more replaceable. (FinInst1)

All three consultants have faced similar situations during theircareers. Consultant 1 summarized his experience:

Sometimes (employees) are pushing for their own agenda, internalpolitics, etc. Or they just say: ‘No, we want this because this is theway we work.’ It is fear of uncertainty of how the operations will bewhen they run SAP. Some fear the loss of control; they fear that theymay not be needed. (Consultant 1)

8) Involvement of Operational Departments—ERP ProjectAcceptance (H): Involvement of the business side of an or-ganization fosters project acceptance and acceptance of thechanges that may arise because of it. According to an employee,BusPrManufCo integrated the business side into the team aspart of a process improvement initiative and had high projectacceptance because of this strategy. This effect is not limited tothe operational employees who are part of the implementationteam. It also trickles back to their departments. An intervieweein EngCo described this effect:

The business people (. . . ) were involved in the team as they weremaking the configurations. (. . . ) When they came back to the de-partments saying that something doesn’t work (and requires changesof the business process), they had credibility as they were part of theteam. (EngCo)

Consultant 2 summarized the positive effect of operationalinvolvement on project acceptance:

One should always include all involved areas of the organization ininformation and project work. That means that the acceptance ofnew processes develops in the entire organization; the employees inthe departments are involved and the entire organization sees such aproject as a team and as a chance for improvement. (Consultant 2)

9) ERP Knowledge—Experience of Implementation Team(I): The implementation team consists of in-house employeesand consultants. Thus, the experience of the implementationteam depends on both. Lack of ERP knowledge can affect theexperience of the internal members of the implementation teamdirectly; further, suboptimal knowledge about ERP adoption atthe beginning of a project may make evaluating the skills of aconsultant team difficult (e.g., FoodBevManufCo), thus result-ing in a less experienced implementation team. However, a lackof experience on the part of internal team members, which, inturn, results in a delay of the transfer of know-how from externalto internal staff (e.g., FinInst1), can be compensated for by hir-ing the right consultants, but only if those hiring know enoughabout the ERP implementation process to select the appropriateconsultant team. In fact, several companies selected consultantsindividually based on the specific skills or kind of knowledgethat were needed in their organizations. These organizations ob-tained the up-front ERP knowledge typically obtained throughparticipation in user groups or by benchmarking other ERPadopters prior to the project start (e.g., FinInst2, BusPrManufCo,and UtilCo2). In two cases, this up-front knowledge also camefrom prior first-hand ERP experience (FinInst1 and FinInst2).

Consultant 2 stressed that involvement in benchmarking ef-forts is crucial for a successful consultant selection. He pointedout the danger of choosing the wrong external employees:

Often, the consultants did not have much more knowledge (than theclient). (. . . ) As you know, in the land of the blind, the one-eyed manis king. However, when it comes to leading a project to a high-qualityfinish, the (one-eyed) man (is) not sufficient. (Consultant 2)

10) ERP Knowledge—Reliance on Consultants (J): Organi-zations with limited up-front ERP knowledge are more depen-dent on consultants for the system adoption than are companieswith prior ERP experience. The fact that some consultants tookon the role of project lead indicated how much control some or-ganizations turned over to consultants (EngCo). Occasionally,this resulted in the project being run de facto by the consultant(FinInst1, ConsPrManufCo). It was also typical for a consult-ing firm to externally staff large parts of the implementationteams in organizations that had limited up-front ERP knowl-edge (FinInst1 staffed their project with 75% external employ-ees). Consultant 2 explained:

When there are many people with limited knowledge, one has alwaysprovided entire teams (. . . ) the teams were often entirely staffed byexternal consultants. (Consultant 2)

Companies with more up-front ERP experience generally re-tained control of the projects internally and remained engagedthroughout the course of the project (FinInst2, BusPrManufCo,


UtilCo2). Consultant 1 stressed the importance of an organiza-tion’s involvement; however, he emphasized that this was notalways possible:

If a company can (. . . ), it should be involved, however, not allcompanies have the capabilities, internal knowledge, and resources.(Consultant 1)

11) ERP Knowledge—Involvement of Operational Depart-ments (K): Organizations that are knowledgeable about ERPadoption may recognize the need to involve operational depart-ments early in the process. Both UtilCo2 and EngCo stressedthat they learned from their benchmarking efforts that it wasimportant to involve the business side of the organization fromthe beginning of the project. One interviewee explained:

A lot had to do with (. . . ) making sure that the whole organizationwas engaged with the project, and we did a pretty good job ofthat based upon what we learned (from benchmarking with otherorganizations). (EngCo)

Other organizations did not award business a strong role onthe implementation team; UtilCo1 and FinInst1 were examplesof adopters lacking up-front knowledge. Consultant 2 stressedthe importance of operational involvement. He stated that “theadoption of the ERP software (. . . ) has to be accompanied by thebusiness side of the organization.” His company usually works“40% with the business side of the client and 60% with the ITpeople.”

12) ERPKnowledge—ERPProjectAcceptance (L): Whetherthe ERP system adoption is accepted across the organizationdepends on multiple factors. One key is ERP knowledge. If theentire organization believes that adopting an ERP system willbenefit it, acceptance of the project is likely to be higher. Suchan understanding may have come from prior project experience(e.g., FinInst2), or from having successfully communicated thestrategic importance to the employees (e.g., BusPrManufCo).Companies that did not believe that organizational change wasnecessary for an ERP implementation experienced a lower rateof acceptance for the project (UtilCo1 and FoodBevManufCo).Consultant 2 described how tied together ERP knowledge andacceptance of change are when he said:

The more someone (. . . ) learns, the more he sees a benefit (. . . );this has to do a lot with information. When it is transparent thatchange is associated with a benefit (. . . ), change will be embraced.(Consultant 2)

13) Project Motivation—ERP Project Acceptance (M): AnERP system adoption can be motivated in two ways. First, tostay competitive an organization that needs to modify its exist-ing business processes may adopt a new information system,especially if modifying the existing system is not economicallyfeasible. Second, an organization may be technically motivatedto adopt a new information system to address a technical needor to utilize new hardware. Project motivation is the secondfactor that affects project acceptance. The project and the ac-companying changes to existing business processes were usuallyaccepted if the implementation motivation was organizational(BusPrManufCo and EngCo). Even if the organizational mo-tivation was externally driven and not the result of a strategic

implementation decision, such as in FinInst1, it fostered projectacceptance. An interviewee in this company pointed out: “Mostpeople understood that processes must change because of themerger.” Consultant 3 also supported the notion that a com-pany that is driven by organizational needs will more likelysupport organizational changes during the ERP implementa-tion. He stressed that “if the organization is reluctant to take thefull ownership of the project, (it) means that (it is) also reluc-tant to embrace the change (. . . ). Whereas, if the organization(. . . ) recognizes the impact on the longer term strategy for theorganization (this is different).”

14) Top-Down Decision Making—ERP Project Acceptance(N): If the decision to adopt the ERP system is prescribed bymanagement in a top-down fashion, a project may not ob-tain broad support or acceptance; a consultant explained thata top-down management adoption decision without employeeinvolvement can lead to low project acceptance:

If the whole thing is a top management decision according to theprinciple ‘we are now going with SAP’ and the decision is notbeing carried by the organization, then it will be often a very verydifficult adoption, where it is also very difficult to modify the businessprocesses. Because in those cases, no department of the organizationwill be willing to accept that change is necessary and everyone willpush against it. (Consultant 2)

Top-down decision making is common in higher power dis-tance cultures [47], such as in southern Europe. This kind of de-cision making approach was particularly noticeable in the twosouthern European cases that we studied (UtilCo1 and Food-BevManufCo).

15) ERP Knowledge—Project Motivation (O): Limitedknowledge of an ERP system’s business potential may be thecause of a solely technical project motivation. This was notthe case with FinInst2 and BusPrManufCo. Both companieshad acquired extensive ERP knowledge at the beginning ofthe projects, which lead to embedding their ERP adoptionswithin major reengineering initiatives. An interviewee of Bus-PrManufCo explained:

We also knew from studying best practices putting in an ERP thatwe were not going to be successful with that unless we took theopportunity to change our business processes at the same time (. . . ).Our objective was not to implement an information system; ourobjective was to develop and deploy common processes designedacross best practices, and the ways to do that was enabled by acommon information system. (BusPrManufCo)

FoodBevManufCo was somewhat on the other side of thespectrum. The primarily technical motivation for replacing itslegacy system with “an integrated ERP system” resulted in re-luctance “to change processes that are working fine.” (FoodBev-ManufCo employee).

Two of the consultants interviewed linked a limited knowl-edge about what an ERP system could do to a solely technicalmotivation for its adoption. Consultant 1 viewed this as a prob-lem that was more prominent until the late 1990s: Organizationsadopted such systems because everyone else wanted SAP to doexactly what the old system did; thus, these companies werenot prepared to change their existing business processes. Or-ganizations in this group believed that an ERP implementation


would allow the company to downsize by automating existingprocesses. Consultant 2 indicated that some organizations de-scribed this type of ERP adopter as “unprepared and naive,”and said that these companies viewed the ERP system as a re-placement of the legacy system and did so “according to theprinciple “I am doing the same just on a different platform.”“Of the other type of adopters who make ERP projects strategicbusiness initiatives Consultant 1 said:

(Some) customers really understand why they want to have (an ERP)system. They see the business benefit. They want to grow theirbusinesses and have no other way to take control of the organization.(Consultant 1)

B. Summary of the Findings

Section IV-A discussed how the case and consultant data leadto the findings; this is summarized in Table III. The letters inTable III refer to the labels introduced in the subheadings of thatsection.

V. CONCLUSION

The study’s contributions are twofold. First, empirically iden-tified customization drivers, supported by existing determinantsof customization-related ERP success factors, were gleanedfrom prior ERP literature. While this earlier research focused onisolated aspects of ERP implementation issues that were investi-gated mostly in a success context, this research organized thesedispersed findings into a coherent framework and establishedtheir relevance as drivers of customization. Second, the studyidentified new factors that, in turn, expand the set of knowndeterminants of customization. The customization drivers iden-tified in this research explain how organizations fail to achievelow customization. Fig. 2 summarizes the customization driversand illustrates how they relate to high system customization.The findings of this study have implications for both researchand practice.

A. Contributions to Research

While there have been previous studies that examined a com-prehensive set of ERP implementation success factors (whichwere discussed in Section II), most of the previous work focusedon hypothesizing and testing these success factors. Most studiesdid not investigate what causes such factors. This study addsto the body of knowledge by examining what can lead to over-customization of an ERP system and by providing a detailedexplanation of the circumstances under which high customiza-tion can occur. Some of the issues surrounding customizationare closely related to other literature-identified success factors(e.g., team experience, reliance on consultants, and ERP projectacceptance); however, the study adds to prior research by ex-plaining how these issues may be related to extensive systemcustomization. Furthermore, our research relates several of thesefactors to a set of underlying reasons that are novel in the ERPcontext. The Appendix includes a table summarizing the priorknown ERP success factors that this study has integrated into thecustomization framework. In addition to refining known factors

and establishing their relationship to customization, this studyidentified several previously unknown customization drivers.Further, our research introduced 12 novel relationships betweenthese factors; these relationships integrate all the concepts intoa comprehensive framework.

If ERP systems are viewed as a technology in a more generalsense, the findings of this study may also have bearing on somemajor streams of general IT research. Such research containsconsiderable literature, including the large body of research thatexists in the IT area regarding adoption, use, diffusion, and ac-ceptance of technologies. Although this study does not attemptto integrate itself into this body of research, some links areevident and may prompt future research. Several models havebeen used in the Information Systems field to study acceptanceof technology (e.g., the theory of reasoned action (TRA) [48],the theory of planned behavior (TPB) [49], and the technologyacceptance model (TAM) [50], [51]). Our study did not specifi-cally focus on the constructs of TRA and TPB, such as subjectivenorm; however, many of our findings deal with the impact ofindividuals, including consultants, supervisors, and the imple-mentation team, on the process decisions. Furthermore, TAMand TRA both focus on volitional acceptance and use. ERP im-plementations are rarely voluntary in nature, especially not forindividual users. Use is generally a mandated decision made bymanagement.

One additional aspect of our model that distinguishes itfrom the bulk of the technology acceptance literature is thatit is a multilevel model composed of organizational, group,and individual-level constructs. This contrasts with TAM (anindividual-level model) and Klein and Sorra’s model of organi-zational innovation (an organizational-level model) [52].

Future research may take the theoretical lenses of these in-dividual and organizational-level theories, and may be able tofurther explain our multilevel findings by investigating the deci-sion making processes that occur in ERP adopting organizations.This would further consolidate our findings into existing IT the-ories. Further, a quantitative survey-based research approachresulting in a path model would better determine the extent towhich variance in the dependent construct (ERP implementationsuccess) is due to customization.

B. Implications for Practice

As a practical application of the study, managers and engi-neers can gain insights into ERP system adoptions from thispaper. The study addresses one of the major problems that orga-nizations face when implementing ERP systems. Consequently,these findings can help organizations improve their customiza-tion decisions by controlling the level of customization andtargeting process redesign inhibitors. Organizations that under-stand the possible pitfalls of customization early on will be ableto improve project outcomes by addressing these issues at thebeginning of an ERP implementation project. This study ex-plains that high customization happens because of a number offactors that can be summarized as follows. An implementationteam with insufficient knowledge of the system standard mayduplicate the already existing functionality. Low organizational


acceptance of the project and cultural issues (both individualand organizational) may lead to resistance to change of exist-ing business processes. An implementation team with limitedERP experience may have less ability to counter resistance tochange because it may not be able to effectively convince deci-sion makers that system customizations should be avoided. In animplementation setting where reliance on external consultantsis high, consultants may show little opposition to an uninformedclient request for extensive customizations. An implementationteam with limited understanding regarding the organization’sprocesses may retain too many existing business processes be-cause they seem unchangeable (particularly in a setting withhigh reliance on consultants and minimal involvement for oper-ational departments).

These findings show that low customization does not justhappen because the corporate decision makers want it. It requiresan ERP adoption program that carefully avoids the pitfalls thatcan lead to resistance to changing existing business processes.Knowing this may help organizations successfully mange ERPsystem customization.

C. Limitations

The study followed a rigorous qualitative research approach,which is evident when comparing its research design, data col-lection, and data analysis to the recommendations provided byDube and Pare [53] for rigorous case study research. Out ofthe twenty-one recommendations, only one was not followed:To explain the phenomena observed, the study relied on the tri-angulated explanations of the participants, rather than seekingalternative explanations. While this may be a limitation of thestudy, this approach allowed us to capture and convey the ex-perience of the implementers and consultants in this research.In the Appendix, we provide a table that summarizes Dube andPare’s [53] recommendations and compare this study to theirguidelines.

All participating case organizations implemented SAP R/3.While limiting the case data to experiences with one softwarepackage helped internal validity because it allowed for cross-case comparability, such limiting may have impacted the ex-ternal validity of the study. Whether the findings can also beapplied to the implementation of non-SAP software depends onthe extent to which the issues captured by our constructs apply tothese packages. Since the literature showed that many of the is-sues identified in the SAP R/3 context were consistent with priorresearch that was at least partially based on other ERP systems,it is believed that this study can generalize to ERP implementa-tions. Thus, our findings may apply to ERP systems other thanSAP, and possibly even to other customizable off-the-shelf soft-ware; how generally applicable the results of this study are tothese other software products may be investigated in subsequentstudies by using both qualitative and quantitative methods.

Although we chose to investigate the drivers for customiza-tion, other success factors identified by the literature are alsoimportant. We acknowledge that investigating drivers for othersuccess factors was beyond the scope of this study. Conse-quently, this presents opportunities for future research.

APPENDIX

For space consideration, the semistructured interview out-line, implementation case and consultant information, a tablethat illustrates how prior literature on ERP customization wasintegrated into this study’s customization framework, as well asa table that summarizes the assessment of the research designbased on the work of Dube and Pare [53] have been provided inan online appendix. The supplemental information is availableat erpsupp.rothenb.com.

REFERENCES

[1] A. Ragowsky and T. M. Somers, “Special section: Enterprise resourceplanning,” J. Manage. Inf. Syst., vol. 19, pp. 11–15, 2002.

[2] J. Scott and I. Vessey, “Managing risks in enterprise systems implemen-tations,” Commun. ACM, vol. 45, pp. 47–81, 2002.

[3] K. M. Lui and K. C. C. Chan, “Rescuing troubled software projects byteam transformation: A case study with an ERP project,” IEEE Trans.Eng. Manage., vol. 55, no. 1, pp. 171–184, Feb. 2008.

[4] H. Akkermans and K. van Helden, “Vaicious and viruous cycles in ERPimplemenation: A case study of interrelations between critical successfactors,” Eur. J. Inf. Syst., vol. 11, pp. 35–46, Mar. 2002.

[5] K. Amoako-Gyampah and A. Salam, “An extension of the technologyacceptance model in an ERP implementation environment,” Inf. Manage.,vol. 41, pp. 731–745, 2004.

[6] K.-K. Hong and Y.-G. Kim, “The critical success factors for ERP im-plemenation: An organizational fit perspective,” Inf. Manage., vol. 40,pp. 813–829, Oct. 2002.

[7] J. Motwani, D. Mirchandani, M. Madan, and A. Gunasekaran, “Successfulimplementation of ERP projects: Evidence from two case studies,” Int. J.Prod. Econ., vol. 75, pp. 83–96, 2002.

[8] F. F.-H. Nah, J. L.-S. Lau, and J. Kuang, “Critical factors for successfulimplementation of enterprise systems,” Bus. Process Manage. J., vol. 7,pp. 285–296, 2001.

[9] J. Scott and I. Vessey, “Implementing enterprise resource planning sys-tems: The role of learning from failure,” Inf. Syst. Front., vol. 2, pp. 213–232, 2000.

[10] W. Skok and M. Legge, “Evaluating enterprise resource planning (ERP)systems using and interpretive approach,” Knowl. Process Manage., vol. 9,pp. 72–82, 2002.

[11] F. Soliman, S. Clegg, and T. Tantoush, “Critical success factors for inte-gration of CAD/CAM systems with ERP systems,” Int. J. Oper. Prod.Manage., vol. 21, pp. 609–629, 2001.

[12] T. Sommers, K. Nelson, and J. Karimi, “Confirmatory factor analysis ofthe end-user computing satisfaction instrument: Replication within andERP domain,” Decis. Sci., vol. 34, pp. 595–621, 2003.

[13] M. Al-Mashari and A. Al-Mudimigh, “ERP implementation: Lessons froma case study,” Inf. Technol. People, vol. 16, pp. 21–33, 2003.

[14] C. P. Holland and B. Light, “A critical success factors model for ERPimplementation,” IEEE Softw., vol. 6, no. 3, pp. 30–36, May/Jun. 1999.

[15] T. Sommers and K. Nelson, “The impact of critical success factors acrossthe stages of enterprise resource planning implementations,” presented atthe 34th Hawaii Int. Conf. Syst. Sci., Maui, HI, 2001 [CD-ROM].

[16] C. Soh, S. S. Kien, and J. Tay-Yap, “Cultural fits and misfits: Is ERP auniversal solution?,” Commun. ACM, vol. 43, pp. 47–51, 2000.

[17] F. F.-H. Nah, K. M. Zuckweiler, and J. L.-S. Lau, “ERP implementation:Chief information officers’ perceptions of critical success factors,” Int. J.Hum.–Comput. Interact., vol. 16, pp. 5–22, 2003.

[18] K. Kumar and J. van Hillegersberg, “ERP experiences and evolution,”Commun. ACM, vol. 43, pp. 23–26, 2000.

[19] D. Gefen, “What makes an ERP implementation relationship worthwhile:Linking trust mechanisms and ERP usefulness,” J. Manage. Inf. Syst.,vol. 21, pp. 263–288, 2004.

[20] R. C. Beatty and C. D. Williams, “ERP II: Best practices for successfullyimplementing an ERP upgrade,” Commun. ACM, vol. 49, pp. 105–109,2006.

[21] W. Luo and D. M. Strong, “A framework for evaluating ERP implemen-tation choices,” IEEE Trans. Eng. Manage., vol. 51, no. 3, pp. 322–333,Aug. 2004.

[22] A.-W. Scheer and F. Habermann, “Making ERP a success,” Commun.ACM, vol. 43, pp. 57–62, 2000.


[23] L. Brehm, A. Heinzl, and M. L. Markus, “Tailoring ERP systems: Aspectrum of choices and their implications,” presented at the 34th HawaiiInt. Conf. Syst., Maui, HI, 2001.

[24] D. Robey, J. W. Ross, and M.-C. Bourdreau, “Learning to implemententerprise systems: An exploratory study of the dialectics of change,” J.Manage. Inf. Syst., vol. 19, pp. 17–46, 2002.

[25] A. Al-Mudimigh, M. Zairi, and M. Al-Mashari, “ERP software implemen-tation: An integrative framework,” Eur. J. Inf. Syst., vol. 10, pp. 216–226,2001.

[26] G. G. Gable, “Large package software: A neglected technology,” J. Inf.Technol., vol. 6, pp. 3–4, 1998.

[27] D.-G. Ko, L. Kirsch, and W. King, “Antecedents of knowledge transferfrom consultants to clients in enterprise system implementations,” MISQ., vol. 29, pp. 59–86, 2005.

[28] S. Sarker and A. S. Lee, “Using a case study to test the role of three keysocial enablers in ERP implementation,” Inf. Manage., vol. 40, pp. 25–40,Sep. 2003.

[29] T. H. Davenport, “Putting the enterprise into the enterprise system,” Har-vard Bus. Rev., vol. 76, pp. 121–131, Jul./Aug. 1998.

[30] S. J. Simon, “The art of military logistics,” Commun. ACM, vol. 44,pp. 62–66, Jun. 2001.

[31] A. M. Aladwani, “Change management strategies for successful ERPimplementation,” Bus. Process Manage. J., vol. 7, pp. 266–275, 2001.

[32] R. Davison, “Cultural implications of ERP,” Commun. ACM, vol. 45,pp. 109–111, Jul. 2002.

[33] V. Grover, “From business reengineering to business process change man-agement: A longitudinal study of trends and practices,” IEEE Trans. Eng.Manage., vol. 46, no. 1, pp. 36–46, Feb. 1999.

[34] J. Platt, ““Case study” in American methodological thought,” CurrentSociol., vol. 40, pp. 17–48, 1992.

[35] I. Benbasat, D. K. Goldstein, and M. Mead, “The case research strategyin studies of information systems,” MIS Q., vol. 11, pp. 368–386, 1987.

[36] R. K. Yin, Case Study Research: Design and Methods, 2nd ed. ThousandOaks, CA: Sage, 1994.

[37] I. Stuart, D. McCutcheon, R. Handfield, R. McLachlin, and D. Samson,“Effective case research in operations management: A process perspec-tive,” J. Oper. Manage., vol. 20, pp. 419–433, 2002.

[38] O. Holsti, Content Analysis for the Science and Humanities. Don Mills,ON: Addison-Wesley, 1969.

[39] K. M. Eisenhardt, “Building theories from case study research,” Acad.Manage. Rev., vol. 14, pp. 532–550, 1989.

[40] P. Rajagopal, “An innovation-diffusion view of implementation of enter-prise resource planning (ERP) systems and development of a researchmodel,” Inf. Manage., vol. 40, pp. 87–114, 2002.

[41] R. A. Hirschheim, “User experience with and assessment of participativesystem design,” MIS Q., vol. 9, pp. 295–304, Dec. 1985.

[42] J. M. Morse, “Designing funded qualitative research,” in Handbook ofQualitative Research, N. K. Denzin and Y. S. Lincoln, Eds. ThousandOaks, CA: Sage, 1994, pp. 220–235.

[43] M. B. Miles and A. M. Hubermann, Qualitative Data Analysis: A Source-book of New Methods. Newbury Park, CA: Sage, 1994.

[44] W. Chen and R. Hirschheim, “A paradigmatic and methodological exam-ination of information systems research from 1991 to 2001,” Inf. Syst. J.,vol. 14, pp. 197–235, Jul. 2004.

[45] B. G. Glaser and A. Strauss, The Discovery of Grounded Theory: Strategiesfor Qualitative Research. Chicago, IL: Aldined Publishing Co., 1967.

[46] A. Straus and J. Corbin, Basics of Qualitative Research: Grounded TheoryProcedures and Techniques. Newbury Park, CA: Sage, 1990.

[47] G. Hofstede, “The cultural relativity of the quality of life concept,” Acad.Manage. Rev., vol. 9, pp. 389–398, Jul. 1984.

[48] I. Ajzen and M. Fishbein, Understanding Attitudes and Predicting SocialBehavior. Englewood Cliffs, NJ: Prentice-Hall, 1980.

[49] I. Ajzen, “The theory of planned behavior,” Org. Behav. Hum. Decis.Process., vol. 50, pp. 179–211, 1991.

[50] F. Davis, “A technology acceptance model for empirically testing newend-user information systems: Theory and results” Ph.D. dissertation,,Massachusetts Inst. Technol.,, Cambridge, 1986.

[51] F. Davis, “Perceived usefulness, perceived ease of use, and user acceptanceof information technology,” MIS Q., vol. 13, pp. 319–340, 1989.

[52] K. J. Klein and J. S. Sorra, “The challenge of innovation implementation,”Acad. Manage. Rev., vol. 21, pp. 1055–1080, 1996.

[53] L. Dube and G. Pare, “Rigor in information systems positivist case re-search: Current practices, trends, and recommendations,” MIS Q., vol. 27,pp. 597–635, Dec. 2003.

[54] T. H. Davenport, “The future of enterprise system-enabled organizations,”Inf. Syst. Front., vol. 2, pp. 163–180, 2000.

[55] J. K. Stratman and A. V. Roth, “Enterprise resource planning (ERP) com-petence constructs: Two-stage multi-item scale development and valida-tion,” Decis. Sci., vol. 33, pp. 601–628, 2002.

Marcus A. Rothenberger received a Ph.D. degreefrom Arizona State University, Tempe, in 1999.

He is an Associate Professor in the Departmentof Management Information Systems, University ofNevada, Las Vegas. He uses qualitative, quantita-tive, and design science paradigms to research soft-ware process improvement issues, software reusabil-ity, performance measurement, service-oriented ar-chitectures, and the adoption of enterprise resourceplanning systems. He has published papers in majoracademic journals, such as the Journal of Manage-

ment Information Systems, the Decision Sciences Journal, IEEE TRANSACTIONS

ON SOFTWARE ENGINEERING, Communications of the ACM, and Information &Management. He is a Co-Editor-in-Chief of the Journal of Information Tech-nology Theory and Application and an Associate Editor of the AIS Transactionson Enterprise Systems.

Dr. Rothenberger is a member of the Association for Information Systems.

Mark Srite received a Ph.D. degree from FloridaState University, Tallahassee, in 2000.

He is an Associate Professor in the Manage-ment Information Systems Area at the Sheldon B.Lubar School of Business, University of Wisconsin–Milwaukee. His current research interests includeadoption and diffusion of information technologiesacross cultures, enterprise system issues, and tech-nology’s influence on decision making. He has au-thored or coauthored papers published in Manage-ment Information Systems Quarterly, the Journal of

Management Information Systems, Decision Support Systems, Information &Management, etc. He is a Co-Editor-in-Chief of the Journal of InformationTechnology Theory and Application.

Dr. Srite is a member of the Association for Information Systems.

Documents

An Investigation of Customization in ERP System Implementations