organizational knowledge sharing in erp implementation: … · 2014-09-30 · organizational...

Journal of Organizational and End User Computing, 16(1), 21-40, Jan-Mar 2004 21

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea GroupInc. is prohibited.

Organizational Knowledge Sharingin ERP Implementation:Lessons from Industry

Mary C. Jones, University of North Texas, USAR. Leon Price, University of Oklahoma, USA

ABSTRACT

This study examines organizational knowledge sharing in enterprise resource planning (ERP)implementation. Knowledge sharing in ERP implementation is somewhat unique because ERPrequires end users to have more divergent knowledge than is required in the use of traditionalsystems. Because of the length of time and commitment that ERP implementation requires, endusers are also often more involved in ERP implementations than they are in more traditionalERP implementations. They must understand how their tasks fit into the overall process, andthey must understand how their process fits with other organizational processes. Knowledgesharing among organizational members is one critical piece of ERP implementation, yet it ischallenging to achieve. There is often a large gap in knowledge among ERP implementationpersonnel, and people do not easily share what they know. This study presents findings aboutorganizational knowledge sharing during ERP implementation in three firms. Data were col-lected through interviews using a multi-site case study methodology. Findings are analyzed inan effort to provide a basis on which practitioners can more effectively facilitate knowledgesharing during ERP implementation.

Keywords: organizational knowledge sharing; enterprise resource planning; largescale information systems

INTRODUCTION

Enterprise resource planning (ERP)is a strategic tool that helps companies gaina competitive edge by streamlining busi-ness processes, integrating business units,and providing organizational membersgreater access to real-time information.Many firms are using ERP systems to cutcosts, standardize operations, and leveragecommon processes across the organization.ERP allows firms to have a more conver-

gent view of their information by integrat-ing processes across functional and divi-sional lines using a centralized database andintegrated sets of software modules (Scottand Kaindl, 2000; Zheng et al., 2000).

However, the convergence that ERPaffords at the organizational level often re-sults in a divergence of the knowledge re-quired at the individual level (Baskervilleet al., 2000). ERP imposes a new frame-work on the organization (Robey et al.,2002). It requires end users to have

701 E. Chocolate Avenue, Suite 200, Hershey PA 17033-1240, USATel: 717/533-8845; Fax 717/533-8661; URL-http://www.idea-group.com

ITJ2518

IDEA GROUP PUBLISHING

22 Journal of Organizational and End User Computing, 16(1), 21-40, Jan-Mar 2004


broader knowledge than is required in theuse of traditional systems. They must un-derstand how their tasks fit into the overallprocess and how their process fits withother organizational processes (Lee andLee, 2000). Thus, knowledge sharing is onecritical piece of ERP implementation. Anorganization begins to build the foundationduring implementation on which end userscan understand enough about the ERPframework to realize its benefits (Robeyet al., 2002). Because of the time commit-ments and the extensive knowledge shar-ing that must take place during ERP imple-mentation, end users are often more in-volved in the implementation than they arein more traditional implementations. Insome cases, ERP implementations aremanaged and led by end users and end usermanagers, and IT staff serves primarily astechnical advisors (Jones, 2001). Unfortu-nately, there is usually a significant gap inknowledge among these implementationpersonnel, and people do not easily sharewhat they know (Constant et al., 1994;Jarvenpaa and Staples, 2000; Osterloh andFrey, 2000; Soh et al., 2000).

This study was undertaken to exam-ine how firms ensure that organizationalknowledge is shared during ERP implemen-tations. One objective is to identify facilita-tors of organizational knowledge sharing.Another is to synthesize findings into les-sons about knowledge sharing during imple-mentation that other firms can apply in theirown ERP implementations.

THEORETICAL BACKGROUND

Knowledge sharing in ERP imple-mentation is somewhat unique becauseERP redefines jobs and blurs traditionalintra-organizational boundaries (Lee andLee, 2000). Knowledge must be sharedacross functional and divisional boundaries,

and the knowledge required during ERPimplementation entails a wider variety ofexperiences, perspectives, and abilities thantraditional information systems implemen-tations (Baskerville et al., 2000; Robey etal., 2002). Knowledge sharing is challeng-ing because much knowledge is embeddedinto organizational processes (Davenport,1998). The way people actually do theirjobs is often different from the formal pro-cedures specified for even the most rou-tine tasks (Brown and Duguid, 2000). It isalso challenging because there are gapsbetween what people do and what theythink they do (Brown and Duguid, 2000).Some tasks are so routine, and people havedone them for so long, that many of thesteps involved are subconscious (Leonardand Sensiper, 1998). However, there is avariety of factors that can facilitate knowl-edge sharing during ERP implementation.

In order to present a coherent andlogical view of knowledge sharing, we iden-tify factors that influence knowledge shar-ing that are linked by a common concep-tual underpinning, which allows individualsto share observations and experiencesacross traditional boundaries. Most ERPimplementation activities center around theERP implementation team (Baskerville etal., 2000). ERP implementation teams typi-cally consist of organizational membersfrom a variety of functional areas and or-ganizational divisions. Each team membermust understand what the others do in or-der to effectively map processes during theimplementation (Baskerville et al, 2000).Team members must work to achieve thislevel of understanding. The knowledgesharing required does not come automati-cally with team membership; it must befacilitated. Thus, facilitation of knowledgesharing on the team is one factor exam-ined.

The team must also interact with end



users to gather relevant information aboutprocesses and to keep end users and usermanagers informed about changes to ex-pect when the ERP is implemented (Robey,Ross, and Boudreau, 2002). Ideally, thereis an intensive exchange of knowledge be-tween the team and these users that theyrepresent (Baskerville et al., 2000). Inad-equate knowledge sharing between thesetwo groups leads to unsuccessful implemen-tation (Soh et al., 2000). One key to asmooth ERP implementation is effectivechange management (Andriola, 1999;Harari, 1996). Because of the complexityand cost of ERP, it must be visibly plannedand implemented (Hammer, 1990). Oneway to communicate plans, share knowl-edge with end users, and gather knowledgefrom end users is through careful changemanagement (Clement, 1994). Therefore,change management is another knowledgesharing factor examined.

A large part of change managementis training. Those affected by the imple-mentation should receive training to developnew and improved skills to deal with newchallenges brought about by the change(Andriola, 1999). Users must gain knowl-edge about the business rules and processesembedded in the ERP software (Lee andLee, 2000). They also must understandthe integrative nature of ERP in order touse it effectively. ERP requires end usersto understand that they are no longer work-ing in silos, and whatever they do now im-pacts someone else (Welti, 1999). Entiredepartments must be retrained with this inmind (Caldwell and Stein, 1998; Al-Mashariand Zairi, 2000). Training on transactionsand on the integrative nature of ERP isanother factor examined.

Most firms hire external consultants(integration partners) that know the ERPsoftware to help them through the imple-mentation (Soh et al., 2000). This involves

knowledge sharing because the organiza-tional implementation team seeks ways forthe know-how and skills possessed by in-tegration partner staff (IPS) to be sharedwith them so that they are not lost whenthe IPS leaves (Al-Mashari and Zairi,2000). This goes beyond written documen-tation and training manuals. For example,consultants are assigned to work side byside with organizational team members sothat the members can learn what the con-sultants know about the package that cannot easily be written down (Osterloh andFrey, 2000). One source of failure in ERPimplementation is the IPS who works alone,and fails to share knowledge with organi-zational members (Welti, 1999). When theIPS fails to share what they know, the firmoften has trouble supporting the ERP afterthey leave. Thus, it is important that thefirm capture as much of the IPS’s knowl-edge as possible before they transition offthe team. Transition of IPS knowledge isanother knowledge sharing factor exam-ined. In summary, several factors that mayinfluence knowledge sharing are examined.These are facilitation of knowledge shar-ing on the implementation team, changemanagement activities, type of training endusers receive (i.e., transactional or integra-tive), and use of formal knowledge trans-fer from integration partner staff when theyleave the organization.

Finally, the extent to which a firm isbeginning to alter its core knowledge com-petency after SAP implementation is ex-amined. The active sharing of organizationalmembers’ knowledge is linked to a firm’sability to alter its core knowledge compe-tencies (Kogut and Zander, 1992; Grant,1996; Hine and Goul, 1998). Alteringknowledge competency involves sharingknowledge across the organization in a waythat preserves existing knowledge compe-tencies and at the same time absorbs new



knowledge that expands and strengthensthose competencies (Stein andVandenbosch, 1996). An innovation thatimpacts the entire organization and facili-tates major changes in a firm’s processes,as ERP does, provides an opportunity forfirms to do this (Brown and Vessey, 1999).Evidence of this alteration is found in fun-damental changes in the way a firm per-forms its core processes. ERP benefits arethe result of ongoing efforts to continuouslyimprove processes (Ross, 1999). At thetime of data collection, these firms werestill too early in their use of ERP to haverealized extensive change. They were, how-ever, making efforts to integrate processesand thereby alter core knowledge compe-tency. Thus, change in core knowledgecompetency in this study is assessed as theextent to which processes were beingchanged as a result of ERP, rather than theextent to which they had changed.

METHODOLOGY

Data were collected as part of alarger study using a multiple case study offirms in the petroleum industry that hadimplemented SAP R/3. Focusing on a singlepackage helps minimize bias that might beintroduced into findings across packages.However, because the focus is on knowl-edge sharing, rather than on technical as-pects of the package itself, findings shouldbe generalizable to implementation of otherERP software in other industries. The CIOor top IS executive of 10 firms in the in-dustry were contacted to determine if theyhad implemented or were implementingSAP, and if so, whether they would agreeto participate in the study. In some cases, adivision of the firm was included rather thanthe whole firm. Because of size, structure,or geographic dispersion, some firms haveconducted completely separate implemen-

tations in divisions around the world, withlittle or no communication between theimplementation teams. In those cases, thedivision seemed to be a more appropriatecase site than the entire organization. Wecollected data from those that did agree toparticipate, and that met two other criteria.We eliminated firms that had implementedonly one or two modules with no plans toimplement more. We also eliminated firmsthat had not implemented across the orga-nization or the specific division in which wewere interested. Each firm in the studyimplemented the major modules of SAPincluding FI/CO (financial accounting andcontrolling), AM (fixed assets manage-ment), PS (project systems), PM (plantmaintenance), SD (sales and distribution),MM (materials management), and PP (pro-duction planning). These criteria helped toensure that the case sites were comparable,and that differences in findings were notdue to the scale of implementation.

In order to minimize bias that the re-searchers might introduce into the processof analyzing findings, a rigorous and struc-tured approach to analysis was followed(Yin, 1989). For example, the interviewertook notes and taped each interview. Tapesand notes were transcribed by a third party,reviewed by the interviewer, and respon-dents were asked for clarification on pointsthat seemed vague or missing. The tran-scriptions were then summarized, reviewedby another researcher to help ensure thatthe transcriptions flowed well and madesense. Finally, the primary contacts in eachfirm reviewed summaries to help ensurethat what was recorded represented ac-tual events and perceptions. A case studydatabase consisting of interview notes,documentation provided by respondents,tables summarizing findings, and an exactnarrative transcription of all interviews wereused. The questions from the interview



guide are provided in Appendix A. A withincase analysis was performed where datawere extracted using the interview ques-tions as a guide to get a clearer picture ofknowledge sharing in each firm. Then, across-case analysis was performed in whichknowledge sharing across the firms wascompared.

Because of the size of the projectteams, interviewing a sample of key mem-bers was deemed more manageable thanattempting to interview each member. Inaddition, many members had left the firm,or moved out of the areas in which theyhad originally worked. Thus, we asked eachof the top IS executives to identify keymembers of their SAP project team thatwere still involved with SAP in some way,including support and post-implementationprocess redesign. This method of identify-ing respondents has been demonstrated tobe acceptable because professionals in afield have been shown capable of nomi-nating key respondents that have a consis-tent set of attributes appropriate for a studysuch as this (Nelson et al., 2000). A seriesof semi-structured interviews were con-ducted with 8 to 10 members of each firm.The number of interviewees was chosenbased on the concept of theoretical satura-tion, where “incremental learning is mini-mal because the researchers are observ-ing phenomena seen before” (Eisenhardt,1989, p. 545). In these interviews, the re-searchers often heard the same examplesfrom most of the respondents in a site re-gardless of functional background, whenthey came on the team, or their job at thetime of the interview. In addition, the re-spondents often used the same phrases toexpress their perceptions. This was true ofrespondents who were not located at thesame physical locations at a site or whowere not all on the team at the same time.Thus, it was deemed that additional inter-

views would not yield significantly differ-ent insights. For example, all the respon-dents at USWhole used the phrase “psy-chological effort” when referring to howthey approached the project. They indicatedone guiding tenant of their project was thatthe implementation was as much a “psy-chological effort as a technical effort.” Inanother example, the phrase “the accountantsalways cleaned up after everyone” came upin most interviews at each case site.

The interviews lasted between oneand two hours each over a period of sevenmonths between July, 2000 and February,2001. Each person was interviewed oncein person for one to two hours, and thenwas contacted by e-mail or by telephonefor additional information or clarification.In addition to the face-to-face interviews,the researchers also preceded and followedup the interviews with e-mail and telephonecalls for background information, clarifica-tion, and points not covered in the interviews.

Respondents included both informa-tion systems staff and business/functionalstaff. Some had been on the team from thebeginning, while others joined at variouspoints in the project. These people repre-sented a variety of perspectives on SAP,including some who were pleased with it,some who hated it, and others who wereindifferent. They also represented a vari-ety of levels in the firm ranging from CIOand/or project manager to lower level em-ployees, and included people from suchfunctional areas as accounting, purchasing,refineries, sales and distribution, and a va-riety of engineering functions (Table 1).

PROFILE OF COMPANIES

USWhole is the U.S. division of oneof the world’s leading oil companies. It in-cludes upstream (exploration & production),downstream (marketing, refining, and



transportation), and chemical segments.The firm has exploration and productioninterests in many countries, with a largeconcentration in the U.S., and it marketsits products worldwide. USWhole per-formed five SAP implementations for eachof its major business units, including a smallpilot test site, and corporate headquarters.It began its SAP project in early 1995, andcompleted its first implementation in March1996. The final two implementations werecompleted simultaneously in July 1998.There are approximately 15,000 SAP us-ers in USWhole.

E&P is the North American explora-tion and production division of an interna-tional petroleum company that has annualrevenues in excess of US$90 billion. Thisparticular division is engaged in the explo-ration and production of crude oil and natu-ral gas worldwide, and accounts for ap-proximately US$6.8 billion of thecorporation’s revenue. Although SAP hasbeen implemented in various units of theparent company throughout the world, eachproject has been a separate activity fromall the others. The teams, scope, budget,

and timelines have been managed sepa-rately, and SAP has been designed andconfigured differently for each, with verylittle or no collaboration among the units.Therefore, focusing only on E&P’s appli-cation in this firm seems to provide a unitof analysis that is comparable to that in theother sites. E&P began its project in 1996,using a big bang implementation where allmodules were implemented at one time,and finished the implementation in mid-1998, for approximately 3,000 users.

Chemicals is the chemical division ofan international petroleum company withannual revenues of approximately US$16billion. Chemicals accounts for approxi-mately one-fourth of its parent company’srevenue, with annual revenues of approxi-mately US$4 billion. It is a leading chemi-cal manufacturer with interests in basicchemicals, vinyls, petrochemicals, and spe-cialty products. Its products are largelycommodity in nature, in that they are equiva-lent to products manufactured by othersand are generally available in the market-place. They are produced and sold in largevolumes, primarily to industrial customers

Company SAP Team Role for each respondent (1 respondent per line)

USWhole

(Multiple rolesfor manymembers)

Responsible for SAP configuration; reengineering processes; managed quality assurance & testing; changemanagementIT team leader; applications development lead; general leadership with 3 others of Chemical & Downstreamimplementations Managed configuration & upgrades throughout the companyProject managerProject manager

E&P Service delivery manager; Managed transition plan from production to operations and oversight of theconversionTechnical leader for FI/CO; was also on HR design teamFunctional expert in project systems and asset managementTeam member; worked with conversion of legacy systems & investment management data to SAPLeader for transition from development to supportSite implementation manager

Chemicals Logistics team leaderTeam leader of all financial modules of SAPDirector of the order-to-cash process. Dealt with customer service, accounts receivable, credit and some salesaccounting.Team leader for sales and operations planningChange management leader. Responsible for communications and training materialsBusiness implementation leaderManager of the support groupCo-project managerCo-project manager

Table 1: Profile of Respondents



for use as raw materials. Chemicals beganits SAP project in late 1996, with the firstof nine implementations in January 1998.The implementations occurred approxi-mately every two to three months until allimplementations were finished in Decem-ber 1999. There are approximately 5,000SAP users in Chemicals. A summary ofprofiles is provided in Table 2.

DATA ANALYSIS

In the sections that follow is a de-scription of knowledge sharing factors ineach firm, including facilitation of knowl-edge sharing on the team, change manage-ment/training, and transition of IPS knowl-edge. The extent to which firms had

changed or were beginning to change theircore knowledge competencies throughchanges in processes as a result of the SAPimplementation is also discussed. A sum-mary of points covered is provided inTables 3a, 3b, and 3c. Table 3a provides asummary of facilitation of knowledge shar-ing on the team. Table 3b provides a sum-mary of change management and trainingactivities, and IPS knowledge transitionactivities. Table 3c provides a summary ofchanges in core knowledge competency.

USWhole

Facilitation of Knowledge Sharingon the Team. Teams at USWhole had anegative connotation prior to the SAP

Table 2: Corporate Profile

Corporate Identity

Revenue

(U.S. $)

Began SAP Implementation Date

Number of Users

USWhole * 1995 1996-1998 15,000 E&P 6.8 Billion 1996 1998 3,000 Chemicals 4 Billion 1996 1998-1999 5,000

* USWhole requested that this not be revealed

Table 3a: Summary of Facilitation of Knowledge Sharing on the Team

Company Facilitation of knowledge sharing on the team

USWhole deemphasized titles, rank, and seniority on the team; emphasis on codifying how things worked and comparing written descriptions

E&P lots of socialization after work; team members got to know each other and were supportive of each other; viewed each other as experts in their respective areas focused on a common purpose; some tension between IT and integration partner yet subsided as the project required heavy time and energy commitments; proactively sought ways to minimize the impact of the tension

Chemicals team organized by process; deemphasized seniority and rank by providing the same bonus to all on the team actively; involved a variety of key users early in the process to ensure that they gathered knowledge from the right people



project. They were often used as dumpinggrounds for weak employees. This was amajor obstacle to overcome in facilitatingknowledge sharing on the SAP implemen-tation team. Top management strongly sup-ported SAP, so the project managers wereable to ask for and get the “best people inmost cases” for the implementation team.They sent people back to their units if theydid not work out. Thus, they put togetherteam members that had reasonably good

knowledge about their own processes.USWhole facilitated knowledge sharing onthe team by eliminating seniority and func-tional distinctions. For example, seniorpeople worked alongside hourly workerson the team, and if the lower level employ-ees had an idea or wanted to try some-thing, the senior people listened to them,and in some cases took direction fromthem. As one person said, before thisproject “a lower level person wouldn’t say

Table 3b: Summary of Change Management/Training for End Users and Transition of IPSKnowledge

Company Change Management Training

Transition of IPS Knowledge

USWhole Team communicated with end users about how SAP would change their jobs; Identified end users to be change agents within the units, Relied on change agents to communicate as well

Identified power users among end users to train; Power users helped train other users; Focused largely on transactions Limited focus on integration

Worked with IPS throughout the project; Documented lessons learned at the end of each go-live; Used no formal transfer process at the end

E&P Team went to change management training; Followed a change management strategy; Focused on communicating project status to the company; Made sure end users who were not directly part of the team had input into the project

Identified power users among end users to train; Power users helped train other users; Focused largely on transactions Limited focus on integration

Used formal transfer process with checklists on how to configure and on which things triggered what; Transferred knowledge from IPS to 3rd party consultant, then from that consultant to E&P support team

Chemicals Focused on helping end users understand how their jobs would change after SAP

Focused on how end users would use SAP

Identified power users among end users to train; Power users helped train other users; Focused on integration in addition to transactions

Built knowledge transfer into the contract with the IPS; Focused on how they solved problems & where they looked for answers; Team members gradually took on more responsibility so they could learn what the integration partner knew



what they thought in front of a more seniorperson. But with the shared goal of gettingthe project done quickly, they did.” Lowerlevel people also challenged senior peopleif they didn’t agree or thought there was abetter way of doing something. USWholeprovided a structure to the team that al-lowed people to share knowledge openlyand freely. This helped to resolve conflictsand to map processes to SAP effectively.

As one person said, “the bad thingwas to have an idea and not express it.”USWhole also relied heavily on codifyingknowledge, and writing down how pro-cesses worked. For example, “If someonesaid we can’t do it this way, we said, ‘Whycan’t you? Is it really unique?’ We’d getthem to list what they do and to look atwhat others have listed, and identify thecommonalities.” USWhole used severalapproaches to facilitating knowledge shar-ing on the team, including codifying knowl-edge, structuring the team to remove bar-riers to knowledge sharing, and proactivelyseeking to overcome the stigma associatedwith teams.

Change Management/Training.USWhole had a strong change manage-ment team from the beginning of the projectto communicate with the rest of the orga-nization about project status, issues, ideas,managing expectations, and training. As onesaid, “It’s all about change management.That’s the name of the game.” Anotherperson indicated that “we had to breakdown cultural barriers (to common pro-cesses) through communication.” Theteam shared their knowledge about SAPwith the users in order to do so. They usedseveral verbal and written communicationmeans to reach users at all levels of theorganization. The change managementteam helped users and managers under-stand how SAP would impact them, gath-ered feedback on user perceptions, con-cerns, and issues, and helped overcomeresistance to change.

USWhole used a power user conceptfor training users. They identified users ineach of the business units that were influ-ential in their units and that were interestedin SAP, and trained them extensively in how

Table 3c: Summary of Changes in Core Knowledge Competency

Company Changes

USWhole Gradually eliminating silo behavior; Some units adapted better than others, thus have seen more changes than others; Adaptation across the firm seems to be occurring; "it's not like I do a job anymore, but I perform a step in a process"

E&P Slowly moving away from silo behavior; People are beginning to understand the integration points better, particularly in the financials area; Adaptation limited by corporate budget cuts unrelated to SAP; Are still in the learning cycle, but changes are ongoing

Chemicals Majority of Chemicals units have embraced the concept of common processes, particularly in financials and purchasing; Have completed development of a common master file for parts, and units are designing purchasing around families of parts; Processes in general are now more well defined and better understood across functions within and across divisions



to do transaction processing as well as inhow processes were changing and beingintegrated. However, there was more em-phasis on the ‘how-to’ than on processchanges. Users largely learned the latteron the job as they began to use the system.As power users shared their knowledgewith other users, knowledge about how touse SAP began to permeate the organiza-tion. However, this was more difficult insome streams than in others. For example,one unit had old technology, and went from“1960’s technology to 1990’s technology inone fell swoop. Some had never used amouse before, and one guy was movinghis mouse over the screen to choose anicon.” Thus, it was harder for them to learnhow to use the new system even at themost basic level.

Transition of IPS Knowledge. Be-cause of the sheer size of the project,USWhole had several integration partners.They did not use a formal knowledge trans-fer process when IPS left, but they diddocument how to configure and performall major activities, and they documentedlessons learned with each implementation.USWhole people worked with each inte-gration partner throughout the project sothat the knowledge transfer took place overtime. In addition, although integration part-ners may have been different for each busi-ness unit, the core team from USWholewas the same throughout. Thus, knowledgegained in one implementation was not lost,but rather, was enhanced as the projectprogressed.

Changes in Core Knowledge Com-petency. Team members gained knowledgeabout the organization as a result of SAPas they learned about the “linkages and in-efficiencies between processes.” How-ever, the organization has had mixed re-sults in altering core knowledge competen-cies to change the way they perform pro-

cesses. “Different streams have adapteddifferently.” The downstream operationsare the most complex to do in SAP, andthis stream had experienced the leastchange in the past. In the beginning, it hadthe greatest difficulty in adapting to inte-grated, common processes. “Downstreamadapted very poorly early on.” The chemi-cals division was used to change becauseit operates in an “acquisition and trade en-vironment.” It also was running SAP R/2,so it was more familiar with the integratedprocess approach. Thus, it has had aneasier time adapting. Similarly, “upstreamis primarily accounting based, so with thechanging economy they grew used tochange,” and this stream has adapted tothe changes more readily. Thus, USWholehas experienced mixed results in its effortsto alter core knowledge competencies, butis continually working toward change.

One explanation for this is thatUSWhole did not recognize early enoughdifferences in the streams’ abilities to adaptto change. Their change management ap-proach was not tailored to each stream, andeven though they received feedback fromeach, if a stream was resistant, it may nothave shared enough of what it knew sothat the team could make the transition moreeffective. Although USWhole workedhard, to ensure effective knowledge shar-ing took place on the team, its efforts toensure knowledge sharing between theteam and the rest of the organization maynot have been strong enough to impactchange in core processes.

E&P

Facilitation of Knowledge Sharingon the Team. E&P used informal teambuilding activities to help solidify team mem-ber relationships in an effort to foster knowl-edge sharing. Team members frequently



socialized together after work, and at theend of major milestones, the companytreated the entire team at various dinners,parties, and other outings. The team wasalso solidified because team members“knew the legacy systems on the businessand technical side, and they were highlycapable and credible in their areas.” Theyviewed each other as experts in their ar-eas, and thus, were willing to listen to andlearn from each other.

However, E&P had a somewhatunique obstacle to knowledge sharing toovercome in its implementation. The infor-mation technology (IT) division of the par-ent company is managed as a separatecompany, and must contract with E&P andin competition with other outsourcing ven-dors for jobs. The IT company bid to bethe integration partner on the SAP project,yet the E&P project leader chose anotherfirm to be the primary integration partnerbecause it had more experience with SAP.However, the IT staff had extensive knowl-edge about and experience with the E&Plegacy systems that SAP replaced. In somecases, the IT staff had as much or moreknowledge about how processes workedthan the E&P business unit employees.Thus, they were selected to be part of theSAP team in order not to lose their knowl-edge. At first, there was some tensionbetween IT staff and the IPS because theIT staff felt that they should have beenchosen as the primary integration partner.However, there was a strong corporateculture of working in teams, thus this ten-sion was minimized, and team membersfocused primarily on the common purposeof completing the project rather than onthemselves. In addition, as new peoplecame on the team throughout the project,they were not aware of the earlier tension,which also helped to dissipate it. As onesaid “we didn’t have time to draw lines in

the sand. We were concerned with meet-ing deadlines, and we all had the same goal—making SAP work.”

Change Management/Training.E&P had a change management team inplace whose responsibility was to make surethat current project status was communi-cated to all company employees, and tomake sure that people not directly tied tothe project felt like they also had some own-ership. There was particular emphasis onthis communication because “our experi-ence on these large implementations has avery checkered past.” E&P had imple-mented “fairly well conceived” large sys-tems in the past where the change man-agement people did not handle the changewell. As a result, organizational membersdid not like the systems, and sometimes thesystems were perceived as becoming the“butt of a lot of jokes.” Thus, senior man-agement placed a high priority on manag-ing change in the SAP project, and a largepiece of the budget was devoted to it. Thechange management team went throughchange management training classes, andthe integration partner “brought in a verystrong change management plan.” The“change management piece was very ma-ture, very well thought out, very strong.”The change management team handled allcommunication, using a variety of writtenand verbal communication techniques rang-ing from e-mail to town hall meetings. “Wegot some good input (through this commu-nication) that helped us restore some thingsthat may have caused trouble later on.”

Training was done using the poweruser concept . The emphasis in training wasmore on how to perform transaction pro-cessing than on the way processes werechanging or the integrative nature of pro-cesses. The project budget provided for thelatter aspect of training after implementa-



tion to give the users a chance to first un-derstand how to use the system for basictransactions. However, the budget for alltraining at E&P, not just SAP, was cut, andthey did not get to do as much of that asthey wanted. This hurt the change man-agement team’s ability to share knowledgewith the organization. One site was ableto do more training because they had someadditional resources that they could use.Even though “it wasn’t much more train-ing, you can really see the difference inhow much better they are able to take ad-vantage of SAP than other locations are.”

Transition of IPS Knowledge. Whenit came time to transition the IPS off theteam, the original tension regarding choiceof partner began to resurface. Althoughmost of the team members had either got-ten past it or were unaware of it through-out the project, the project manager still hadreservations about the firm’s internal IT ca-pabilities to support SAP after implemen-tation. He wanted to hire the integrationpartner to continue working with the firmindefinitely as the SAP support team, eventhough this was a more expensive long runoption. Because of the expense and thetension the decision created, senior man-agement overrode the project manager’sdecision and hired the IT division to do long-term support. To ensure that the transitionwas smooth, they removed the projectmanager from the project and transferredhim laterally to another part of the organi-zation that had nothing to do with SAP. Theyappointed an experienced, senior IT man-ager to oversee the transition of knowledgefrom the integration partner to the team,and to manage the establishment of thesupport team. This was a strong, proactiveattempt to overcome an obstacle that couldhave negatively impacted the rest of theproject.

Another choice that helped minimize

effects of this situation is that E&P hiredanother consulting firm with experience inSAP to help transition the IPS off the teamand ensure that their knowledge was notlost to E&P. Because the support teammembers had worked throughout the SAPproject, they already understood the pro-cesses quite well, but were missing techni-cal information such as how to configureparticular processes, or where to look forcertain technical or operational information.The integration partner transferred theirknowledge to the third-party consultant, andthen the third-party consultant transferredthat knowledge to the E&P support team.In their knowledge transfer model, “it wastransferring SAP knowledge from one SAPexperienced group to another SAP experi-enced group, then that group transitionedthe knowledge to us in a way we couldunderstand.” While some knowledge wassurely lost because of the varying percep-tions, experiences, and communication bar-riers involved in getting second-hand orthird-hand knowledge, this may have beenthe best way E&P could gain integrationpartner knowledge, given the situation inwhich they were working. Thus, E&P tookstrong steps to minimize knowledge losswhen it recognized a potential problem withknowledge sharing.

Changes in Core Knowledge Com-petency. The extent to which E&P has in-tegrated the results of its knowledge shar-ing to alter core knowledge and processesis somewhat lacking in consistency. Oneperson indicated that for a long time“people didn’t really try to exploit SAP; theyjust tried to get their jobs done.” However,several months after implementation thatbegan to change. The support team is “get-ting more requests from people looking athow to use SAP to change the business.”Part of that is because budget cuts and lay-offs that occurred about the time SAP was



implemented (not SAP related), created astrain on employee’s time and motivationto learn something new. The pressure onthe budget has eased, yet the emphasis oncost cutting remains. Thus, end users haverenewed their efforts to find opportunitiesto run the business more cost effectively.They are asking the SAP support teamquestions about how to identify and makeuse of these opportunities in SAP. Theyhave also begun to understand that whatthey do in their process now affects some-one else in another process, and are look-ing for ways to take advantage of that. TheSAP support team continues to encouragepeople to exploit SAP opportunities. E&Phas continued sharing knowledge and seek-ing ways to exploit old certainties and ex-ploring new possibilities long after imple-mentation. Thus, changes to the coreknowledge competency are ongoing. Us-ers are now trying to use SAP to changethe way they perform processes and arethus beginning to alter core knowledge com-petencies. One explanation for this may bethe efforts E&P made throughout the imple-mentation to facilitate knowledge sharingon the team and with the rest of the orga-nization. These knowledge sharing effortshelped make the organization ready to fa-cilitate change in processes, and that readi-ness lasted through corporate budget cuts.

Chemicals

Facilitation of Knowledge Sharingon the Team. Chemicals’ project managersaid that “one of the things I always tell myfolks is that SAP is a team sport. If youdon’t play as a team, you can’t win.” Oneof the things in place to discourage indi-vidual hoarding of knowledge was that eachmember of the team received the samebonus at the end of an implementation re-gardless of rank in the organization, and

the bonus was based on the quality of thework, and how well the implementationdeadlines were met. Thus, there was in-centive for each member to work with oth-ers to accomplish a common goal. “We hada foxhole mentality” whereby team mem-bers were united around a common cause.

The team was also organized by pro-cess, rather than by function or SAP mod-ule, to facilitate knowledge sharing. Chemi-cals built overlap between modules andfunctions into the project, and often two ormore groups worked together on a particu-lar piece. For example, logistics is in theSD (sales and distribution) module, butChemicals broke it out and had a subteammanage the logistics process separatelyfrom the sales and distribution people. Muchof that data was also in the order-to-cashprocess performed by the customer ser-vice area. Thus, the logistics group had towork closely with the order-to-cash groupto make sure that the logistics pieces fit.They also did cross-team training to helpensure that people working on one pieceunderstood how their piece impacted oth-ers. Although this approach required moreeffort in many cases than a module-orientedapproach they believed that “if you get toomodule oriented, you get too focused onthe modules you’re working on,” and losesight of the big picture, which is the pro-cesses. Thus, the SAP team was organizedto focus on the transfer of knowledgeacross functions, processes, and units, andto eliminate silo behavior within the teamand between the team and the organiza-tion. Although they did not use formal team-building activities, “everyone on the teamhad to rely on everyone else,” because noone person or group knew all the things ittook to do the project.

The SAP team also decided to bringthe key end users across plants into imple-mentation planning meetings where each



team gave a basic overview of how eachprocess would work in SAP, which includedSAP terminology and basic concepts. Theywent through an exhaustive set of detailedquestions about how processes worked andhow they did their jobs. They built thesequestions over time, based on the integra-tion partner’s experience, and on what theylearned with each implementation. Thus,by the last few implementations, they haddeveloped a set of questions that allowedthem to cover almost every conceivable partof the business processes. “We’d talk aboutthe pros and cons of each decision theseplant people made. And we’d try to makepeople understand what it actually meant,and document the decision. We’d distrib-ute minutes of the meeting and have peopleeither agree or not with what we’d decidedon.” This allowed the business people inmultiple plants to share knowledge and makedecisions about common processes acrossthe plants. As a result, there was moreuniformity of processes across plants, andthere was a better understanding of howto handle exceptions or things that had tra-ditionally been ‘workarounds’ in the legacysystem. “We had some consultants whosaid our method was non-standard andshouldn’t be used, but it worked well forus.”

Change Management/Training.Chemicals had a very strong change man-agement process in place, and although theyhad a formal team in place for this, muchof the change management was an overallSAP team responsibility rather than that ofjust one subgroup. “We had never workedso hard on cultural readiness,” one personsaid. “We worked really hard on commu-nications,” through email, memos, ‘lunchand learns,’ and television monitors withan animated video presentation that rancontinually in the cafeterias in plants. Theon-site planning meetings were also viewed

as an important part of change manage-ment. “We had decision makers from ev-ery functional group in the plants in eachdesign and implementation,” which went along way toward the cultural readiness onwhich change management was focused.

Although there was some use of thepower user concept for training, the teammembers who implemented also trained theusers on site during the implementation us-ing materials the change management grouphad developed. Training involved the trans-actional based skills and a “heavy focus onthe integration points” to help people un-derstand “where they fit in the chain ofevents and why their piece was importantand how it had downstream processes.”They originally thought that the trainingwould be more focused on the how-to,transactional skills, yet when they realizedthat “if we were going to get the wins wehoped were there, it was predicated oneverybody doing their job.” Thus, the train-ing role changed considerably. “We spentmore time and money around training thanwe originally planned, and we had plannedto train much heavier than we had in anyprevious system.”

Transition of IPS Knowledge.Chemicals built knowledge sharing into theircontract with the integration partner. Teammembers focused both on how the partnersolved problems and on where they lookedfor answers. This provided them with notonly “how-to” knowledge, but also withmore experiential knowledge about how tosolve problems. Another way that Chemi-cals ensured knowledge sharing with itsintegration partner is that team memberstook on more responsibility as the imple-mentation progressed so they could learnwhat the integration partner knew, and sothey could develop shared SAP experienceswith the partner.

Changes in Core Knowledge Com-



petency. Chemicals has made substantialprogress toward integrating what it hadlearned through the knowledge sharing inthe SAP project into its core knowledge,and its processes have begun to change.“A lot more people are aware of the inte-gration and dependencies amongprocesses....Our business processes havebecome much more well-defined and un-derstood.” They are beginning to see sub-stantial financial savings from leveragingcommon processes across units. For ex-ample, the purchasing process is now uni-form throughout all the plants, and Chemi-cals has negotiated better prices on partsby buying the same part for all plantsthrough fewer suppliers. To do this, theplants had to work together to change theirnomenclature for parts to create a com-mon master file of parts across plants, whichwas a major hurdle to cross because of thevast number of parts involved. Chemicalshired a consulting firm that had experiencewith this type of task to help them. Thefirm now has a uniform on-line catalog ofparts and vendors. Buyers are now calledalliance owners who “negotiate contracts,approve changes from vendors, and moni-tor the business flow with the vendors”across Chemicals for a particular family ofparts rather than buying all the parts for agiven plant. “We’re still not over the humpon all of these (standards). The processworks, but there’s room for improvement.”

One explanation for this is the strongknowledge sharing facilitators that Chemi-cals built throughout the implementation. Itbegan from a process focus in which func-tional boundaries were removed, and teammembers from a variety of processes hadto work together and share their knowl-edge. This process focus also engaged endusers from across the organization to en-sure that their knowledge about processeswas incorporated into the implementation.

In addition, users that were not directly in-volved in the implementation were trainednot only on transactions, but also on theintegrative nature of performing processesin ERP. Based on this evidence, Chemi-cals had the strongest knowledge sharingduring implementation and seems to havebeen able to move more quickly than theother two firms in altering core knowledgecompetencies through changing the waythey perform processes.

LESSONS LEARNED

The firms that have had success withknowledge sharing during the implementa-tion process are making great strides to-ward taking advantage of ERP to changethe way they perform key processes. Al-though it is too early for these companiesto have realized substantial benefits, theyhave mechanisms in place that put themwell on the road to doing so. They haveformed cross-functional, cross-unit net-works of employees to alter core knowl-edge competencies by standardizing no-menclature, leveraging common processes,and eliminating silo behavior between units.These networks have arisen out of theknowledge sharing that took place duringthe implementation project among teammembers, other organizational members,and integration partners. Thus, there areseveral valuable lessons from these find-ings (see Table 4 for a summary).

One lesson learned is that when firmsstart to implement an ERP, they should iden-tify organizational facilitators of and ob-stacles to knowledge sharing, andproactively seek to overcome the obstacles.For example, team members at E&P rec-ognized a potential problem in the tensionbetween two organizational units, and madea conscious decision to minimize it, thussuccessfully ensuring it was not passed on



to new team members. One of Chemicals’goals was to engage a large number of theappropriate end users in the implementa-tion to ensure that they captured the rightknowledge. Chemicals and USWhole bothworked to overcome traditional barriers toknowledge sharing such as rank, seniority,titles, and physical workspace. Barriers orobstacles that a firm has had in the past onlarge scale projects will not disappear bythemselves, and ignoring them in an ERPproject may magnify them. These firmstook actions that were different from, if notcounter to, organizational norms and pat-terns in order to ensure that the ERP imple-mentation could successfully integrate pro-cesses and eliminate silos.

Lesson two is that firms should focuson integration from the beginning of theERP project. Because ERP requires inte-gration of processes in the end, the transi-tion from silos is easier if the entire imple-mentation effort is built around this inte-gration. Implementing by module may feelmore natural because it’s how organiza-tional members are used to working. How-ever, it only prolongs the inevitable changeto integrated processes necessary to real-ize significant ERP benefits. For example,Chemicals sought to overcome the divisions

among functional areas and business unitsfrom the very beginning of its project.Chemicals’ employees were educatedabout integration of processes from thebeginning of the project because they wereinvolved in integrated groups as theyworked with the SAP team to map out pro-cesses and as they were trained to use SAP.Furthermore, the firms that primarily fo-cused on “how-to” training said that theyregret not having realized the importanceof focusing on integration points with usersearlier.

Lesson three is that firms should learnfrom the past and not be afraid to acknowl-edge prior project weaknesses or failures.For example, E&P recognized that it hadnot been good at change management inthe past, and took steps to correct this weak-ness. USWhole recognized that its man-agement of teams in the past was not good,and took deliberate steps to build a strongSAP team.

Lesson four is that firms should fo-cus on knowledge sharing both on the teamand with the rest of the organization. Forexample, USWhole may not have recog-nized the differences in the ability of itsstreams to adapt to changes brought aboutby SAP early enough because it did not

Table 4: Summary of Lessons Learned

Identify and eliminate obstacles to success e.g., cultural barriers such as stigma associated with teamwork or tensions between units; structural barriers that promote silo behavior or inhibit knowledge sharing between levelsFocus on integration from the beginning of the project e.g., implement by process rather than by module; focus training on integration points in addition to how to process transactionsFocus on finding the best solutions to problems e.g., don't 'sweep problems under the rug' and hope to fix them later; resist pressures to meet deadlines simply to mark milestonesBuild organizational knowledge sharing throughout the project e.g., foster knowledge sharing among team members with formal & informal activities; encourage knowledge sharing between team and other organizational members; minimize knowledge lost when consultants or other team members leave through formal roll- off proceduresLearn from the past e.g., acknowledge prior project weaknesses and look for ways to do better; recognize prior strengths and build on those



tailor its change management activities tothe different streams. As a result, differ-ent streams adapted differently, and theteam had to work harder with some thanothers to begin to affect change in pro-cesses. On the other hand, E&P andChemicals worked hard to facilitate knowl-edge sharing among all relevant stakehold-ers in their implementations. Both organi-zations have begun to change core pro-cesses and alter core knowledge compe-tencies.

Thus, the findings from this study pro-vide several lessons firms may apply in theirown ERP implementations. Even firms thatalready have implementations in progressor that are struggling to make ERP workafter the initial implementation can applythese lessons to their own situations. ERPis a long term solution, and once imple-mented, it is difficult, if not impossible, togo back to the way things were prior toERP. Thus, it is never too late to look atother firms’ success stories to find whatwe can learn from them.

LIMITATIONS OF THE STUDYAND DIRECTIONS FOR FUTURERESEARCH

One limitation of the study is that onlyone industry and one package was exam-ined. Although this helps to minimize biasthat could be introduced across industriesand packages, there is a trade-off betweengeneralizability of findings and minimizingbias. Minimizing bias helps eliminate manyfactors that might confound the results andprovides a clearer view of the phenomenonof interest. Selection of appropriate casesites controls extraneous variation and helpsdefine the limits for generalizing findings(Eisenhardt, 1989). If consistent results arefound across similar case sites, then wecan be surer that the theory that led to the

case study originally will also help identifyother cases to which results are analyti-cally generalizable (Eisenhardt, 1989; Yin,1989). However, using one industry ig-nores difficulties or challenges in implemen-tation that may be unique to a given indus-try. One avenue for future research is toexamine these constructs in this studyacross industries and using different ERPpackages to determine whether industry orpackage mediate the findings in this study.

Another limitation is the number ofrespondents interviewed. Although manyof the same phrases were heard from re-spondents, indicating that theoretical satu-ration had been reached, one direction forfuture research is to examine the phenom-ena of interest in this study using a largersample size in order to be more sure thatthe responses obtained in this study do rep-resent the broader views and perceptionsof the project team. In addition, the unit ofanalysis in this study is restricted to theimplementation team. Although mostknowledge sharing during the implementa-tion revolved around this team, future re-search that explores the perceptions ofother organizational members or of the in-tegration partner staff could be useful. Oneavenue for this future research is to com-pare responses to determine whetherknowledge sharing is perceived differentlybetween the team, other organizationalmembers, and the integration partner staff.

CONTRIBUTIONS OF THESTUDY

This study contributes to what isknown about knowledge sharing in ERPimplementations in several ways. First, itidentifies, categorizes, and discusses sev-eral factors that facilitate knowledge shar-ing during ERP implementation. Second, itlinks knowledge sharing to attempts to



change core knowledge competencies.Third, it provides several lessons for prac-titioners that they can use in their own ERPimplementations. Practitioners engaged inERP implementation can use these find-ings both to determine what may work bestfor them and to identify their own facilita-tors of knowledge sharing. Fourth, thisstudy provides directions for future re-search by identifying limitations of the cur-rent study and suggesting ways that futureresearch could examine those limitationsto further extend what we know aboutknowledge sharing in ERP implementation.

APPENDIX A: SEMI-STRUCTURED INTERVIEWGUIDE

Team vs. individual efforts1. Do you usually work on a project team

or do you primarily work alone onprojects?

2. Do you think you are more rewardedfor individual activities or for work onteams? How important is project team-work to your company?

3. Are teams primarily made up of peoplefrom the same functional areas or fromacross functions?

4. How would you describe the culture ofthe firm?

Process vs. product (deadline) orien-tation1. How much focus was there on meeting

deadlines and finishing the project underbudget?

2. How well were deadlines met?3. When deadlines weren’t met, what was

the reason?4. How did your team determine whether

the goals were valid and being met?5. How did your team learn about opportu-

nities SAP could provide your firm?

6. Do you think this learning process oc-curred throughout the implementation?

Organizational knowledge sharing dur-ing the project1. How were the SAP project team mem-

bers selected?2. How were differences in perspectives

melded together?3. Was this easy or difficult?4. Was there ever a time when differences

couldn’t be resolved? (if so, how wasthat handled?)

5. How did your team seek input from oth-ers in the company on areas where youwere uncertain?

6. How did your team seek to keep othersin the company informed about companygoals and progress on SAP?

7. Do you think this was ever seen as sim-ply another IT project?

8. How much did your group rely on out-side consultant expertise?

9. How did you make sure that you hadlearned enough from them so that youcould carry on after they left?

10. Was there much transition off your SAPteam? How was it managed?

11. How were new people coming on theteam brought up to speed?

12. During SAP team meetings, werepeople encouraged to express their ideas,even if they weren’t fully formed yet?And did they express these ideas? Canyou give some examples?

13. Was there ever anything in the imple-mentation process you felt just wasn’tright, but couldn’t exactly explain why?If so, did you express this? Why or whynot?

14. Was there anything you assumed to betrue about SAP that you later changedyour mind about?



Incorporation of new knowledge intoCore Knowledge Competencies1. Do you believe that the organization is

different now than before SAP imple-mentation? If not, why; if so, how?

2. Have the processes changed or are theybeing changed because of SAP?

3. How has SAP changed the way youthink about your job or the company?

4. What are some things that you learnedabout the business processes at the com-pany that you didn’t know before theSAP implementation?

AUTHOR NOTEThis paper supported by NSF Grant SES 000-1998

REFERENCES

Al-Mashari, M. and Zairi, M.(2000).“The Effective Application of SAP R/3: AProposed Model of Best Practice,” Logis-tics Information Management, 13(3),156-166.

Andriola, T. (1999). “InformationTechnology—The Driver of Change,” Hos-pital Material Management, 21(2), 52-58.

Baskerville, R., Pawlowski, S., andMcLean, E.(2000). “Enterprise ResourcePlanning and Organizational Knowledge:Patterns of Convergence and Divergence,”Proceedings of the 21st ICIS Conference,Brisbane, Australia, 396-406.

Brown, J.S. and Duguid, P. (2000).“Balancing Act: How to Capture Knowl-edge without Killing It,” Harvard Busi-ness Review, May-June, 73-80.

Brown, C. and Vessey, I. (1999).“ERP implementation approaches: Towarda contingency framework,” Proceedingsof the 20th Annual International Con-ference on Information Systems, Char-lotte, NC, December 12-14, 411-416.

Caldwell, B. and Stein, T. (1998). “Be-yond ERP - New IT agenda - A secondwave of ERP activity promises to increaseefficiency and transform ways of doingbusiness,” InformationWeek, (November),30, 34-35.

Clement, R.W. (1994). “Culture,Leadership, and Power: The Keys to Or-ganizational Change,” Business Horizons,37(1), 33-39.

Constant, D., Kiesler, S., Sproull, L,(1994). “What’s Mine is Ours, or Is It? AStudy of Attitudes about Information Shar-ing,” Information Systems Research, 5(4),400-421.

Davenport, T.H. (1998). “Putting theenterprise in the enterprise system,”Harvard Business Review, July-August,121-131.

Eisenhardt, K.M. (1989). “BuildingTheories form Case Research,” Academyof Management Review, 14(4), 532-550.

Grant, R.M. (1996). “Prospering indynamically competitive environments: Or-ganizational capability as knowledge inte-gration,” Organization Science, 7(4), 375-387.

Hammer, M. (1990). “ReengineeringWork: Don’t Automate, Obliterate,”Harvard Business Review, 68(4), 104-112.

Harari, O. (1996). “Why DidReengineering Die,” Management Review,85(6), 49-52.

Hine, M.J. and Goul, M. (1998). “Thedesign, development, and validation of aknowledge-based organizational learningsupport system,” Journal of ManagementInformation Systems, 15(2), 119-152.

Jarvenpaa, S.L. and Staples, D.S.,(2000). “The use of collaborative electronicmedia for information sharing: An explor-atory study of determinants,” Journal ofStrategic Information Systems, 9, 129-154.

Jones, M.C. (2001). The Role of Or-



ganizational Knowledge Sharing in ERPImplementation, Final Report to the Na-tional Science Foundation Grant SES0001998.

Kogut, B. and Zander, U.(1992).“Knowledge of the firm, combinative ca-pabilities, and the replication of technology,”Organization Science, 3(3), pp. 383-397.

Leonard, D. and Sensiper, S. (1998).“The role of tacit knowledge in group inno-vation,” California Management Review,40(3), 112-132.

Nelson, K.M., Nadkarni, S.,Narayanan, V.K., and Ghods, M.(2000).“Understanding Software Operations Sup-port Expertise: A Revealed Causal map-ping Approach,” MIS Quarterly, 24(3),475-507.

Osterloh, M. and Frey, B.S. (2000).“Motivation, Knowledge Transfer, and Or-ganizational Forms,” Organization Sci-ence, 11(5), 538-550.

Robey, D., Ross, J.W., and Boudreau,M-C. (2002). “Learning to Implement En-terprises Systems: An Exploratory Studyof the Dialectics of Change,” Journal ofManagement Information Systems, 19(1),17-46.

Ross, J. (1999). “Surprising Facts

about Implementing ERP,” IT Pro, July/August, 65-68.

Scott, J.E. and Kaindl, L. (2000). “En-hancing Functionality in an Enterprise Soft-ware Package,” Information and Man-agement, 37, 111-122.

Soh, C., Kien, S.S., and Tay-Yap, J.(2000). “Cultural Fits and Misfits: Is ERPa Universal Solution?” Communicationsof the ACM, 43(4), pp. 47-51.

Stein, E.W. and Vandenbosch, B.(1996). “Organizational learning during ad-vanced systems development: Opportuni-ties and obstacles,” Journal of Manage-ment Information Systems, 13(2), 115-136.

Welti, N. (1999). Successful SAPR/3 implementation: Practical manage-ment of ERP projects, Addison-Wesley:Reading, MA.

Yin, R. K.(1989). Case Study Re-search: Design and Methods, Sage Pub-lications: Newbury Park, CA.

Zheng, S., Yen, D.C., and Tarn, J.M.,(2000). “The New Spectrum of the Cross-Enterprise Solution: The Integration of Sup-ply Chain Management and EnterpriseResources Planning Systems,” Journal ofComputer Information Systems, Fall, 84-93.

Mary C. Jones is an associate professor of information systems at the University ofNorth Texas. She received her doctorate from the University of Oklahoma in 1990.Dr. Jones has published articles in such journals as Information and Management,Information Resources Management Journal, European Journal of InformationSystems, Journal of Computer Information Systems, and Behavioral Science. Herresearch interests are in the management and integration of emerging electroniccommerce technologies and in organizational factors associated with enterprise-wide systems.

R. Leon Price is a Conoco Teaching Fellow at the University of Oklahoma. Dr.Price has published many articles and papers, one of which the Academy of Man-agement Review named as one of their seven outstanding articles of the year. Otherpublication outlets include Behavioral Science, Information Resources Manage-ment Journal, Journal of Computer Information Systems, and Information Execu-tive. His research interests are in the management of information technologies.

organizational knowledge sharing in erp implementation: … · 2014-09-30 · organizational...

Documents