Available online at ScienceDirect. Procedia Technology 16 (2014 )

(1)

Procedia Technology 16 ( 2014 ) 430 – 439

ScienceDirect

Peer-review under responsibility of the Organizing Committee of CENTERIS 2014. doi: 10.1016/j.protcy.2014.10.109

CENTERIS 2014 - Conference on ENTERprise Information Systems / ProjMAN 2014 -

International Conference on Project MANagement / HCIST 2014 - International Conference on

Health and Social Care Information Systems and Technologies

Knowledge transfer mechanisms in an ERP post-implementation

stage

Sylvain Goyette

a

_{*, Luc Cassivi}

a

_{, Mathieu Courchesne}

a

_{, Elie Elia}

a

a_{Université du Québec à Montréal (UQAM), P.O. Box 8888, Downtown Station, Montreal (Quebec) Canada, H3C 3P8}

Abstract

This paper examines the knowledge transfer process in ERP post-implementation projects, and more specifically between the ERP project team and the IT support team. Case studies were conducted in three large organisations and data was collected via semi-structured interviews. Descriptive and graphical representations were used to analyze knowledge transfer processes for each case and a cross-case analysis was performed. Results from this exploratory study shed light on the relation between the IT support team’s organizational structure and the use of knowledge transfer mechanisms according to different types of knowledge (functional and technical). This paper also shows the importance of deploying both formal and informal knowledge transfer mechanisms during post-implementation projects.

Peer-review under responsibility of the Organizing Committees of CENTERIS/ProjMAN/HCIST 2014

Keywords: ERP, project management, knowledge transfer, post-implementation

1.Introduction

Enterprise resource planning (ERP) systems are now somewhat of a commodity with its presence in more than

* Corresponding author. Tel.: +1-514-987-3000 (1787)

E-mail address: Goyette.sylvain@uqam.ca

(2)

75% of North American manufacturing firms and 60 % of service firms [1]. The implementation projects of these integrated systems has seen its share of challenges as they require major investments and are far from being assured success. Recent statistics show that over 50% of projects experience cost overruns and over 60 percent experience schedule overruns [2], nearly the same numbers as fifteen years ago where 70% of ERP implementations were considered a failure or a negative experience [3].

These bad experiences may be explained by several factors, but one factor that stands out is the time and effort required to fine-tune the ERP system. A majority of organizations consider the initial implementation of the ERP as the final activity rather than a life cycle stage of the system. In order to reap the benefits of such an ERP implementation, several preoccupations linked to the evolution of the systems must be taken into account [4]. This evolution, which consists of multiple iterations such as revisions, reimplementation or upgrades [5], ultimately focuses on making sure the ERP is aligned with the actual and future business needs of the organization [4]. Wenrich and Ahmad [6] state that several maintenance activities included in the evolution must be manage as development projects in order to be successful, but they also iterate that a permanent structure of support needs to be

maintained to cover the ERP user’s operational needs. With this duality of structure (ERP project and ERP support)

in the ERP evolution context, mechanisms are required to transfer knowledge between these two different structures in order to maximise the evolution of the ERP system [7].

The objective of this paper is to understand how organizations transfer knowledge between the ERP project structure and the ERP support structure to conduct the evolution of an ERP in an organization. The next section presents a brief literature review of the main themes of this study. It is followed in section 3 by the methodology used to conduct the research and by the main results in section 4. The paper concludes with the main contributions. 2.Literature review

2.1.Enterprise Resource Planning (ERP) systems

Several definitions of an ERP are available in the literature [1,5]. In a nutshell, an ERP is a software system designed to support organizations in the management of the processes or components of their businesses. The ERP automates business processes and collects transactional business information, giving real-time information visibility to the multiple users dispersed all over the organization. The literature on ERP includes several themes [8], but this study focuses on one of the under investigated themes - ERP system optimisation - and more precisely the system evolution. ERP system optimisation is associated to the post-implementation stage, which begins when the ERP becomes available to the final users, and ends when the system is no longer used [9].

The researchers interested in the post-implementation stage all agree that the literature on the subject is scarce [5,6,10,11]. Amongst the themes studied by these researchers are found ERP maintenance activities [4,12,13], which are defined by the influencing maintenance strategies [5], the knowledge transfer between the development team and the final users [14], and the knowledge management planning and continuous improvement in ERP implementations [7,11,15,16].

2.2.Project management

Research in project management is in constant evolution where this field, mainly controlled by professional in

the 70’s and 80’s, has produced rigorous and quality research over the last 20 years [17]. Smyth and Morris [18] mention the absence of theory in the field of project management, which is explained by its multidisciplinary nature.

A project is defined as “a temporary group activity designed to produce a unique product, service or result” [19]. Managing a project is hence “the application of knowledge, skills and techniques to execute projects effectively and efficiently” [19]. The focus is however slowly changing where the execution of a project (notably with Atkinson’s

[20] “iron triangle” of time, cost and quality), is giving way to the perspective of knowledge transfer (learning) recently being put forth in project management [21]. This perspective stipulates that “during the project, knowledge

must be transferred, integrated, created, and exploited to create new organizational value” [21].

A project consists of different stages, which is often presented by different steps of a project life cycle including a closing phase. Lundin and Söderholm [22] propose an interesting terminology to the different stages of a project

(3)

life cycle: Action-based entrepreneurialism, Fragmentation for commitment-building, Planned isolation, Institutionalized termination. This study focuses on the Institutionalized termination stage for which the temporary organization is recoupled with the permanent organization.

This coupling involves a transfer (or bridge) between the members of the project team and the organization in order to develop a link between the different projects and the organization’s operations [22]. In this particular study of the evolution of an ERP, the bridge to be analysed is that of the transfer from development of ERP project to ERP operation support.

2.3.Knowledge transfer and knowledge management

Knowledge is a “dynamic human process of justifying personal belief toward the truth” [23]. Knowledge is dynamic as it develops interactions between individuals [23] and is context specific (time and place). Several authors categorise knowledge into two types: explicit and tacit [23,24]. Explicit knowledge may be articulated in a formal language easy to codify, transfer or store, while tacit knowledge is personal and difficult to codify as it is sculpted in the actions, procedures, routines, values and emotions of the individuals.

Knowledge management (KM) is defined as the “process of capturing the collective expertise of the organization

from different sources (i.e. databases, paper, people) and utilizing that knowledge base to leverage the organization”

[25]. Several authors present their perspective of knowledge management and its processes notably through life cycle stages [25,26]. In this study, we chose to adopt Sedera and Gable’s four phases [25]. The first phase -knowledge creation- embodies all that is linked to the -knowledge creation process, either developed through internal resources or obtained externally via specialists. The second phase - knowledge retention - consists in maintaining knowledge in a referential in order to allow this knowledge to last the test of time. The third phase - knowledge transfer - implies the use of informal and formal transfer channels that enables the distribution of knowledge within an organization. Finally, the last phase - knowledge application – is the use of the knowledge by an individual (or many) that received the knowledge in the transfer.

Knowledge transfer is hence a sub-component of knowledge management [25] and it will be detailed for this study. Knowledge transfer is only possible with formal and informal mechanisms that integrate, interpret and share knowledge anchored in individuals or groups of individuals [27]. A summary of the literature review allowed us to identify three categories of transfer mechanisms: i) personnel movement, ii) use of tools and iii) role assignment.

Personnel movement simply consists in transferring an employee to another department or to another division [28]. It improves communication abilities of the identified resource and enables the development of a stronger network within the organization [28]. The use of tools, the second category of mechanisms, involves information technologies, rules, procedures, reports and manuals used by employees in the organization [29]. Finally, in the third category, certain mechanisms ask for individuals to take on a particular role, as is the case for the knowledge broker

or the power user [14].

Some authors have been interested by the factors that affect the selection of knowledge transfer mechanisms. For instance, Chai et al. indicate that the choice of the mechanism depends on the nature (tacit or explicit) of the knowledge being transferred, and of the dependence of the knowledge to its context [29]. Jasimuddin asserts that the selection of the transfer mechanism depends on three elements, the status of actors implicated in the transfer, the relational aspects, and the social ties and proximity of the actors [30]. Many studies on the transfer of knowledge are found in the literature, but very few on the mechanisms used to transfer the knowledge [30,31].

3.Methodological approach

A case study approach was chosen to conduct this study as it enables the researchers to retain the holistic and meaningful characteristics of real-life events [32]. The sampling was conducted both at the organizational level and the respondent level. Selection criteria were used to ensure the quality of the information provided and to validate the subsequent research results [33]. Data collection was then conducted via semi-structured interviews [34], which were then recorded and transcribed. Finally, a mixed interpretation strategy (descriptive and graphical analyses) was

(4)

used to compare processes and to develop a process model that will help understand the knowledge transfer process exploited by the organizations [35].

As previously mentioned, the literature on knowledge transfer mechanisms between project teams and more operational/support team in IT is relatively scarce, which justifies the methodological approach chosen [36]. Furthermore, the distinction between the phenomena and the context is not clearly delimited [37], which also calls for a case study approach. The unit of analysis being the organization, the case study approach was chosen to collect

the data for this level of analysis. A four step methodology was followed. First, organizations and respondents were selected. The sampling was conducted at the organizational level and also at the respondent level. Selection criteria were used to ensure the quality of the information provided and to validate the subsequent research results [33]. Second, interviews were conducted where the data collection was conducted via semi-structured interviews [34] and documents analysis to ensure a triangulation of the data [30]. The narrative and graphical representations of the process followed, for which a mix interpretation strategy was used to analyze each case individually [35]. Finally, a cross-case data analysis was conducted to identify similarities and differences in the process. The analysis framework (Figure 1) presents both the maintenance group and the project evolution group that are involved in developing the ERP. The study notably looks into the transfer mechanisms between these two groups.

3.1 Profile of the organizations and respondents

Three organizations from the public/para-public sector were chosen to participate to this study. With over 30,000 employees, the ERP of Organization A, a large municipal actor, was implemented in 2006. Since 2010, three initiatives have been developed to add advanced procurement functionalities, a human resource module and a payroll component (all from the same editor). Organization B, which employs 9,000 people, conducts its activities in the field of transportation and has gradually implemented several ERP modules (all from the same editor) over the last 13 years. Finally, Organization C, with 22,000 employees, conducts its activities in the utilities. Its implementation of an ERP began in 1999 and has since continued gradually to include new modules in several of its

(5)

operational divisions. Its evolution strategy involved in a set of software from different editors as some specialized functionalities were not available by the initial editor.

For each of these organizations, interviews were conducted with three different profiles IT support managers, IT project managers, ERP internal customers. The interviews lasted approximately 75 minutes. A total of twelve interviews were conducted in the three organizations.

4.Findings

Two main elements where specifically analyzed for this study, the organizational structure and the transfer mechanisms required to conduct the ERP evolution. Both will be presented in this section.

4.1 Organizational structure

For the first element of comparison (organizational structure), two specific dimensions, centralization and the localization of resources, are identified and discussed.

The strategies of organizations A and B have been to pool resources into a single team to cover both ERP projects and ERP support. Both organizations have identified the same advantages as this structure has improved their activities, notably in terms of knowledge transfer. As the IT manager of Organization A mentions “ of one, it’s

a proven concept in our organization, and two, splitting resources into two groups would raise costs with additional resources required, and less efficiency, I am convinced”. The IT manager in Organization B mentions the importance of continuity: “ this hybrid zone where two teams ensure the knowledge is an advantage, as if one leaves for retirement or for another reason, a team is capable to compensate, and it has happened in both ways in the past.”

In Organization C, a different strategy has been applied where the ERP project team is separated from the ERP support team (see figure 2). They consider that this structure improves the specialization of the resources and increases the employee retention level. The impact of such a structure involves information duplication and the creation of more knowledge transfer processes to compensate the resources’ lack off proximity. The analysis of the structural integration of the project and the support resources in these three organizations make this element an important factor in the ERP knowledge transfer as it facilitates the exchange of information among the members of the group.

Although organizations A and B have both implemented centralized support groups, the localization of their employees is quite different (see figure 2). For Organization A, the technical and functional resources are localized in the (same) IT department. For Organization B, the technical resources are grouped in the IT department with functional experts in each of the operational units. The data gathered during the interviews showed that Organization B has chosen this set up to get better interactions and collaboration between the IT support and the internal customers, while Organization A aims for better integration between the different ERP modules.

Our findings, summarized in figure 3, are coherent with the centralization and the structural integration dimensions of Chen and Huang [38]. Gallagher et al. [16] have also described this dilemma of having to choose between a centralized, a decentralized or a hybrid structure for the functional resources after an ERP implementation. Another implication of localizing the functional resources in the operational units is related to the distribution of the ERP knowledge among the functional experts.

For Organization A, the pooling of all resources in one place allows knowledge sharing among multiple functional experts, which is not completely the case for Organization B. In fact, certain functional areas of Organization B are covered by only one functional resource, the sole keeper of both project and support knowledge. In such a case, the knowledge transfer mechanisms are just not possible, and the organization faces risky knowledge management issues.

The results also show the criticality of distinguishing technical resources from functional resources, and therefore the technical knowledge from the functional knowledge. The integration of these two types of knowledge in the success of an ERP implementation is critical as identified by Baskerville et al. [39].

(6)

(7)

4.2 Knowledge transfer mechanisms

For the second element of comparison, knowledge transfer mechanisms, there is a similar pattern as organizations A and B opt for the same scheme, that is, of both exploiting the movement of employees as their primary mechanism of functional knowledge transfer (see Table 1). The richness and complexity of the contextual information is the main reason for the use of this scheme, which may be declined in three different approaches:

x complete assignment, where the support resources are full time in the project,

x shared assignment, where resources are part time in both the support groups and the project group, and

x hand-offs, where the knowledge transfer is fully conducted at the project go live.

The IT manager of Organization A gives an example of this complexity: “it’s easy for a programmer or a

configurator to read the programming lines to understand what the program does. But what is more difficult is to know the background information on why the program is what it is. When change requests arrive, they are very rarely related to a change in the program. It is a user need that is requested. Therefore, you have to understand what is in place, the link with the business need, and how you can make it happen... And it is all of that knowledge, and understanding of the business needs and business solutions that must be disclosed to the maintenance resources,”

Organization C’s actual organizational structure seems to be an obstacle for this personnel movement mechanism. Some of the stakeholders involved in the projects interviewed complained about this specific gap in their knowledge transfer process.

The use of tools (documents, etc.) is the prime mechanism for all three organizations used to capture and transfer technical knowledge, while the employee movement mechanism is executed by all three organizations for functional knowledge, but to a lesser extent for Organization C. Also, the three organizations are completing their functional transfer mechanisms with one-on-one interactions and integrator training. For all three organizations, the role assignment mechanisms are not used at all to transfer technical knowledge and but are scarcely used for functional knowledge. Our results show that this mechanism is mainly use for knowledge transfer between the IT organization and the internal customer.

(8)

8 Author name / Procedia Technology 00 (2014) 000–000

4.3 Informal knowledge transfer mechanisms

The analysis of organizations A and B basically shows that they are in line with the transfer mechanisms presented in the literature. They only use informal mechanisms (such as personal contacts and networks, ad hoc meeting, etc.) to exchange information. Organizational C, however, is not using the usual formal mechanisms. During the interviews, stakeholders in Organization C confirmed the inefficiency of the formal knowledge transfer process, but as identified in the following quote, mentioned that they have established informal mechanisms of information exchanges to complete the gaps:”it is really ad hoc, really… if you have a problem, come and see me, it’s always like that, so you learn by trial and error…by trial and error”.

Organizations A and B are coherent with Boh’s conclusions that individual informal mechanisms are to be used

to transfer knowledge [27]. In Boh’s view, individual informal mechanisms should be only used for unique

situations, while institutional formal mechanisms should be used for recurring information [27]. On the other hand, the institutional mechanisms are not used properly by Organization C, as there is absence of personnel movement and no other formal mechanism to compensate. However, the system is still able to run the system and conduct change requests on the ERP.

4.4 The role of ERP integrator in the knowledge transfer process

In the majority of ERP projects, an integrator (external consultant) may participate to the project in different ways. The specific specialized knowledge of an ERP system may be developed by the internal team, but often emanates from external consultant at first. The knowledge transfer is therefore critical to the long term viability of the system. In Organization A, the integrator’s role is moderate, mostly during the ERP support activities where they act as trainers to transfer their knowledge. In Organization B, the inclusion of integrator is low where their services are mainly provided during the project with a mix team of internal and external resources. Knowledge transfer to the support team is conducted at the end of the project. Finally, in Organization C, the integrator is highly included in the ERP activities and is even responsible for projects in the organization. The impact of the different strategies of integrator inclusion is important on the knowledge being shared by the stakeholders of the project. In Organization C, significant efforts must be deployed to retain the knowledge on the project, but the transfer mechanisms are not always used adequately to capture all of the critical information. In Organization B, efforts are minimal to retain the information from the integrators, but are important to transfer the knowledge from the project team to the support staff.

(9)

5.Contribution and future research

The main contribution of this paper is to provide a preliminary understanding of the knowledge transfer process between ERP projects and IT support. The importance of the organizational structure and the use of knowledge transfer mechanisms based on different type of knowledge (functional and technical) bring new insight. Our research focuses only on public sector organizations, leaving space for endorsement in the private sector. An interesting potential future research initiative would be to use a quantitative approach with a larger number of respondents in order to generalize the results obtained in this study.

For business managers, our paper confirms the importance to establish a proper organizational structure to facilitate knowledge transfer within the organization. It also shows the necessity to rely on both formal and informal knowledge transfer mechanisms to cover recurring and ad hoc exchanges between the different stakeholders responsible for the evolution of the ERP.

References

[1] Gattiker, T.F., and D.L. Goodhue. What Happens after ERP Implementation: Understanding the Impact of Interdependence and Differentiation on Plant-Level Outcomes. MIS Quarterly, 2005; 29:3, 559-585.

[2] Krigsman, M. "2013 ERP research: Compelling advice for the CFO" http://www.zdnet.com/2013-erp-research-compelling-advice-for-the-cfo-7000011619/ accessed January 10th_2014.

[3] Davenport, T.H. The Future of Enterprise System-Enabled Organizations. Information Systems Frontiers, 2000: 2:2, 163-180.

[4] Hirt, S.G, and E.B. Swanson. Emergent maintenance of ERP: new roles and relationships. Journal of Software Maintenance and Evolution: Research and Practice, 2001; 13:6,373-387.

[5] Gable, G.G., T. Chan and W.G. Tan. Large packaged application software maintenance: a research framework. Journal of Software Maintenance and Evolution: Research and Practice, 2001; 13:6, 351-371.

[6] Wenrich, K. and N. Ahmad. Lessons Learned During a Decade of ERP Experience: A Case Study. International Journal of Enterprise Information Systems, 2009; 5:1, 55-73.

[7] McGinnis, T.C., and Z. Huang. Rethinking ERP success: A new perspective from knowledge management and continuous improvement.

Information & Management, 2007; 44:7, 626-634.

[8] Schlichter, B.R. and P. Kraemmergaard. A comprehensive literature review of the ERP research field over a decade. Journal of Enterprise Information Management, 2010; 23:4, 486-520.

[9] Yu, C-S. Causes influencing the effectiveness of the post-implementation ERP system. Industrial Management & Data Systems, 2005; 105:1, 115-132

[10] Ifinedo, P., B. Rapp, A. Ifinedo and K. Sundberg. Relationships among ERP post-implementation success constructs: An analysis at the organizational level. Computers in Human Behavior, 2010; 26:5, 1136-1148.

[11] Law, C.C.H., C.C. Chen and B.J.P. Wu. Managing the full ERP life-cycle: Considerations of maintenance and support requirements and IT governance practice as integral elements of the formula for successful ERP adoption. Computers in Industry, 2010; 61:3, 297-308. [12] Nah, F.F-H., S. Faja and T. Cata. Characteristics of ERP software maintenance: a multiple case study. Journal of Software Maintenance and

Evolution: Research and Practice, 2001; 13:6, 399-414.

[13] Ng, C.S.P. A decision framework for enterprise resource planning maintenance and upgrade: A client perspective”. Journal of Software Maintenance and Evolution: Research and Practice, 2001; 13:6, 431-468.

[14] Volkoff, O., M.B. Elmes and D.M. Strong. Enterprise systems, knowledge transfer and power users. The Journal of Strategic Information Systems, 2004; 134, 279-304.

[15] Salmeron, J.L., and C. Lopez. A multicriteria approach for risks assessment in ERP maintenance. Journal of Systems and Software, 2010; 83:10, 1941-1953.

[16] Gallagher, K.P., J.L. Worell and R.M. Mason. The negotiation and selection of horizontal mechanisms to support post-implementation ERP organizations. Information Technology & People, 2012; 25:1, 27.

[17] Turner, J. R. Evolution of project management research as evidenced by papers published in the International Journal of Project Management. International Journal of Project Management, 2010; 28:1, 1-6.

[18] Smyth, H.J., and P.W.G. Morris. An epistemological evaluation of research into projects and their management: Methodological issues.

International Journal of Project Management, 2007; 25:4, 423-436.

[19] PMI. The Standard for Portfolio Management 4. Pennsylvania: Project Management Institute. 2013

[20] Atkinson, R. Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria.

International Journal of Project Management, 1999; 17:6, 337-342.

[21] Reich, B.H., A. Gemino and C. Sauer. Modeling the knowledge perspective of IT projects. Project Management Journal, 2008:39, p.S4-S14. [22]Lundin, R.A., and A. Söderholm. A theory of the temporary organization. Scandinavian Journal of Management, 1995; 11:4, 437-455. [23]Nonaka, I, R. Toyama and N. Konno. SECI, Ba and Leadership: a Unified Model of Dynamic Knowledge Creation. Long Range Planning,

2000; 33:1, 5-34.

(10)

2008; 21:8, 920-926.

[25]Sedera, D. and G.G. Gable. Knowledge Management Competence for Enterprise System Success. The Journal of Strategic Information Systems, 2010; 19:4, 296-306.

[26]Davenport, T.H., and L. Prusak. Working knowledge: How organizations manage what they know. Boston: Harvard Business School Press. 1998

[27]Boh, W.F. Mechanisms for sharing knowledge in project-based organizations. Information and Organization, 2007; 17:1, 27-58.

[28]Galbraith, J. Competing with flexible lateral organizations, second edition. Coll. «OD series». USA: Addison-Wesley Publishing Company, 152 p. 1994.

[29]Chai, K.H., M. Gregory and Y. Shi. Bridging islands of knowledge: a framework of knowledge sharing mechanisms. International Journal of Technology Management, 2003; 25:8, 703-727.

[30] Jasimuddin, S.M. Exploring knowledge transfer mechanisms: The case of a UK-based group within a high-tech global corporation.

International Journal of Information Management, 2007; 27:4, 294-300.

[31]Persson, M.. The impact of operational structure, lateral integrative mechanisms and control mechanisms on intra-MNE knowledge transfer.

International Business Review, 2006; 15: 5, p.547-569.

[32]Yin, R.K. Case Study Research: Design and methods, California, 171 p. 1994..

[33]Patton, M. Q. Qualitative research & evaluation methods (3rd edition). Thousand Oaks, California: Sage Publications. 2002

[34]Romelaer, P. L'entretien en recherche. In Management des ressources humaines: Méthodes de recherche en science humaines et sociales,

Belgique: De Boeck Supérieur, 448 p. 2001

[35]Langley, A. Strategies for Theorizing from Process Data. The Academy of Management Review, 1999; 24:4, 691-710. [36]Gagnon, Y.C. L'étude de cas comme méthode de recherche, 2e édition: Presses de l'Université du Québec, 123 p. 2012. [37]Yin, R.K. The Case Study Crisis: Some Answers. Administrative Science Quarterly, 1981; 26:1, 58-65.

[38]Chen, C.J. and J.W. Huang. How organizational climate and structure affect knowledge management—The social interaction perspective".

International Journal of Information Management, 2007; 27 :2, 104-118.

[39]Baskerville, R., S. Pawlowski and E. McLean.. Enterprise Resource Planning and Organizational Knowledge: Patterns of Convergence and Divergence. Systèmes d'Information et Management, 2006; 11:4, p.7-28.