KNOWLEDGE TRANSFER TO AND AMONG END-USERS IN

PRE-PACKAGED ENTERPRISE APPLICATION SOFTWARE

IMPLEMENTATION:

An Exploratory Study of the Roles of Communities of Practice

Jimmy Tanamal

Department of Information Systems, The University of Melbourne, Australia

Keywords: Enterprise application [ERP, ES] implementation, knowledge transfer, end-users perspective, Communities

of Practice (CoPs), financial information system

Abstract: This paper is concerned with the roles of Communities of Practice (CoPs) in knowledge transfer during the

implementation of a particular IT artefact, i.e. the Pre-packaged Enterprise Application Software (PEAS

) or

also known as Enterprise Resource Planning (ERP) software. Using an in-depth longitudinal case-study

across different stages of a Financial PEAS implementation in a large Australian university, we assess the

effectiveness and applicability of the practices of CoPs for transferring the PEAS knowledge to and among

end-users. The key finding of this paper is that CoPs can be utilized to enhance knowledge transfer for a

better PEAS implementation result. Our findings also indicate that CoPs can be assigned to steward

this

dynamic PEAS knowledge in its most updated version among the very people who are its owners.

1 INTRODUCTION

Previous studies have indicated that it has become

popular for both large and medium-sized

organizations to license a Pre-packaged Enterprise

Application Software (PEAS) for their enterprise

system (Howcroft and Light 2002; Robey et al. 2002;

Shang and Seddon 2003). However, the PEAS comes

with its own ‘established way of doing business’ (Lee

and Lee 2000 p.282) and ‘imposes its own logic’

(Davenport 1998 p.122) on the adopting

organization’s business practice. In most of the

adoption cases, if not all, the configured PEAS

capabilities or functionalities embed a “best” business

practice which is not exactly the same as the adopting

organization’s legacy business practice. This

necessitates knowledge transfer or even changes to

the organization’s values, structure, and culture.

Regarding the knowledge transfer issue, Robey et al.

(2002 p.32) suggest adopting organizations to

exercise formal training along with a phased

implementation approach to help PEAS end-users

assimilate the new PEAS business practice.

As the PEAS “best” business practice contains

more than the canonical and codified element (Lee

and Lee 2000), formal training alone will be

insufficient and incapable of transferring the whole

aspects of this PEAS’ knowledge to its end-users.

Boudreau (2003) also indicates that PEAS end-users

learn to use a PEAS through formal and informal

ways. Communities of Practice (CoPs) with their

situated learning approach, which exist in the daily

life of the PEAS-adopting organization’s end-users

(Boudreau and Robey 2001 as quoted from Robey et

al. 2002 p.41; Wenger et al. 2002), can be exploited

to integrate and share the PEAS knowledge (Jones

and Price 2001; Pan et al. 2001) for this knowledge

transferring purpose.

For the preceding reason the research question in

this study is: What are the roles of Communities of

Practice in the knowledge transfer during a PEAS

implementation?

While the bulk of academic research has put the

top management involvement and satisfaction as,

consecutively, a critical success factor and benefit

measurement of a PEAS adoption, little consideration

has been given to end-user justified requirements,

participation and gratification. Inevitably, in

exploring the end-users knowledge transfer issue, this

paper is also exposing the end-users’ perspective

about the PEAS implementation.

647

Proceedings of ICEIS 2004

Sixth International Conference on Enterprise Information Systems

2 WHAT IS ALREADY KNOWN

ABOUT THE TOPIC

This section is organized into two subsections. The

first subsection provides background on PEAS and

their implementation issues in relation to knowledge

transfer. It ends with an explanation about how

practice and informal training as part of situated

learning play a significant role in PEAS knowledge

transfer. The next subsection depicts CoPs as a social

structure in relation to situated learning and

knowledge sharing.

2.1 PEAS & Knowledge Transfer

Enterprise Systems can be defined as integrated

systems of people and organizational business units,

software [e.g. PEAS] and hardware, and

telecommunications networks for handling all core

corporate functions such as sales and marketing,

distribution, production and planning, finance and

human resources (Robey et al. 2002; Shang and

Seddon 2003).

Implementing a PEAS for an organization’s

enterprise system can span over a significant time

frame. According to Markus and Tanis (2000), the

whole implementation process can be ideally staged

into four following phases:

1. chartering phase [comprises decision making

leading up to the funding of an enterprise

system adoption; cut-over: finalized PEAS

selection based on fit-gap analysis],

2. project phase [comprises activities purposed

to get the selected PEAS up and running; cut-

over: system goes live],

3. shake-down phase [is the organization’s

coming to grips with the PEAS; cut-over:

normal operation has been achieved], and

4. onwards & upwards phase [continues from

normal operation until the system is replaced

with an upgrade or a different system].

The people component of enterprise systems is

crucial in each of the aforementioned implementation

phases. For example it is people [either top

management, project team members, vendors,

consultants, local IT staff or end-users] who

determine whether the execution of each

implementation phase is successful and whether the

benefits of the ongoing PEAS adoption have been

achieved. Howcroft and Light (2002) found that end-

users were marginalized during the procurement

process of packaged software in their case study. This

is intriguing as it ‘contradicts the rational approach

commonly reported in IS literature’ (p.76). They

implicitly suggest two consequences of a distinct lack

of end-user involvement: end-user resistance and

system implementation failure. It is interesting to see

the effect of end-user participation [or lack of

participation] in packaged software selection on

knowledge transfer.

PEAS, same as in-house application software,

were also developed based on a kind of business

practice

– normally, a hybrid of all the best practices

which might well mean that no such practice exists in

any of the real organizations. Hence, for most

organizations, the PEAS-embedded practice is

normally out-of-tune with their legacy business

practice.

This can be preliminarily identified by the gaps

and/or misfits between the PEAS capabilities and the

organization system requirements. Soh et al. (2000)

suggest a spectrum of resolution strategies ranging

from a greater PEAS customization to a greater

organizational change to resolve the implementation

barriers {Figure A below}. Adopting organizations

interested in embracing the “best” business practice

embedded in the PEAS will likely prefer

organizational changes to customization.

Robey et al. (2002) identify PEAS knowledge as

the knowledge of software technical navigation and

business practice. Lee and Lee (2000) further classify

A business practice is incorporated in an organization

structure and relationship as well as with an information

technology infrastructure (Holland and Light 1999 p.31).

misfit

System Requirements &

Legacy Business

Practice of the

Adopting Organizations

Product Capabilities &

“Best” Business Practice

embedded in the

Adopted PEAS

PEAS Customization,

Workaround,

Organizational Change,

or an

combination?

Knowledge Transfer

for End-Users

1: Software Technical Navigation

2: Explicit Business Practice

3: Implicit Business Practice

gap

Workaround

1: Neutral

2: Neutral

3: Neutral

Org. Change

1: Neutral

2: Necessary

3: Necessary

Full Customization

1: Neutral

2: Unnecessary

3: Unnecessary

Figure A: PEAS Implementation & Knowledge Transfer

ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

648

the knowledge of this business practice as implicit

and explicit. The explicit or codified part can be

represented by sets of defined procedural steps to

accomplish a certain task or operation. The implicit

part governs how that task or operation is actually

being carried out effectively; for example work

culture, networks, values and norms. The cross-

functional nature of PEAS intensifies the impact of

the new implicit business practice on system adoption

- as compared to most of other packaged software.

As PEAS are enterprise-wide, complex, tightly

integrated, cross-functional, and “not easily

modifiable to fit an individual organization’s

requirements” (Jones and Price 2001 p.551), any

customization will risk some failures towards system

implementation (Sumner 2000). It is very costly as

well (Lee and Lee 2000; Davenport 1998; Davis

1998) with no guarantee that the customization will

work perfectly and in time. A small change to an

existing module in one of the functions might entail

serious ramifications across all other functions.

Besides, present customization diminishes the future

privilege for upgrading the PEAS without incurring

much cost. Adding some new modules is considered

of little risk though it will generate additional burden

on the financial resources for software development

plus some delay for “go-live”.

According to Forrester Research, ninety five

percent of Fortune 1000 organizations do not intend

to customize their PEAS (Davis 1998). This means

that the incorporated “best” business practice from

the PEAS is mapped and transferred directly with

little or no modification into the adopting

organization (Lee and Lee 2000). If there is no

customization but the business practices between the

adopted PEAS and the adopting organization are

different, then the organization should exercise a

significant change management program like job

redesign or redistribution. This situation also implies

that a more intensive knowledge transfer, especially

in relation to the knowledge of business practice, is

needed. Robey et al. (2002) suggest a knowledge

transfer through formal training that included both

technical and business practice along with an

incremental PEAS implementation approach.

However, Boudreau (2003) indicates that

individual end-users learn to use the PEAS through

different knowledge transfer channels. She argues

that informal training, as one of the possible

knowledge transfer channels, has a positive impact

on end-users’ learning. This informal training, often

called peer-to-peer learning or legitimate peripheral

learning, together with practice are an integral part of

situated learning and knowledge sharing, which are

the central ideas of Communities of Practice (Lave

and Wenger 1991; Wenger 1998).

2.2 Communities of Practice (CoPs)

According to Wenger et al. (2002), CoPs are groups

of people who share a concern, a set of problems, or

a passion about a topic, and who deepen their

knowledge and expertise in this area by sharing and

interacting on an ongoing basis. These groups can be

formally institutionalized or, on the other hand,

completely unrecognized by their parent organization

(p.27).

Brown and Gray (1995) share a similar definition

with Wenger et al. (2002) as they try to define what

kinds of people are grouped or grouping themselves.

Brown and Gray (1995) claim that these people are

peers in the execution of ‘real work’. They all know

the practice and not merely the explicit knowledge.

Brown and Gray (1995) also find that there are many

communities of practice within a single company,

and most employees belong to more than one of

them. Furthermore, most of these communities are

not named though each boundary is clearly set. It is

also not uncommon that one community can be a

subset of a larger community or in the other case it

can overlap with another community. A community

can also exist within one business unit – mostly for a

“communal memory” purpose (Wenger et al. 2002,

p.26). The size of a community (p.24) can be small [a

few people] or very large [hundreds of people]. CoPs

can be colocated [same location] or distributed, they

can also be homogeneous [same function] or

heterogeneous (p.25). These simple concepts can

help to understand and analyze the phenomena of

CoPs in an organization.

But still, people might not really realize that they

belong to CoPs as CoPs have become so integrated

with their daily lives. This obscurity can be tackled

using the reificative and participative identification

methods (Wenger 1998). The reificative

identification method is to identify members as

people that fall into a certain category or description.

While the participative method helps them identify

themselves with people whose experience is

constitutive of whom they are.

PEAS knowledge is dynamic and complex. It

evolves along the implementation phases and as

software upgrade is pretty much inevitable, this

knowledge will certainly need to be managed for

future purpose. Apparently, a CoP can also contribute

as a knowledge management tool partly based on its

situated practice approach.

CoPs as a knowledge-management tool

The social structure of an organization can play a

significant role in managing knowledge. Wenger et

al. (2002) reveal that conventional structures can not

address knowledge-related problems effectively.

KNOWLEDGE TRANSFER TO AND AMONG END-USERS IN PRE-PACKAGED ENTERPRISE APPLICATION

SOFTWARE IMPLEMENTATION: An Exploratory Study of the Roles of Communities of Practice

649

Though learning does occur in conventional

structures [such as teams], the lessons learnt are

easily lost. They propose CoPs as the ideal social

structure to address knowledge stewardship. By

assigning practitioners the task to create and

communicate the necessary knowledge, CoPs provide

a social forum that supports the living nature of

knowledge.

3 RESEARCH APPROACH

3.1 Research Case

The case organization is a large Australian university

with around 1200 faculty/departmental [local] end-

users and 60 Central Finance [central] end-users.

Central Finance is a department by itself – a central

administrative department indeed. It is seen as the

main owner of the University’s Finance

Administrative IT System [F-AITS]. Beside the F-

AITS, the University is also supported by two other

major administrative IT systems, i.e. Human

Resources Administrative IT System [HR-AITS] and

Student Administrative IT System [S-AITS] – mainly

owned by the Human Resources department and the

Student Admin department respectively

A review of the University's AITSs was

established in 1999 as a means of assessing the

capacity of the University's current AITSs to support

the requirements articulated in the University Agenda

towards the Future.

The review concluded that many of the

University's current business practices were unlikely

to meet the University's longer term needs, as defined

by the University Agenda. The review also stated that

the University's AITSs were found to have served the

University very well to date, but had some limitations

which would prevent them from supporting the

University's activities well in the future.

This review triggered a university-wide project

to revamp and integrate all three existing

administrative IT systems plus a new Research

Administrative IT System [R-AITS]. The main focus

of this project is the S-AITS but for some particular

reasons

the F-AITS was implemented first.

These two departments are also categorized as central

administrative departments in the case university, just like

the Central Finance.

Two main reasons: first, financial systems are more or

less world-wide standardized (also evidenced in Soh et al.

2000) hence do not need much streamlining; second, the

University felt that it was good to provide more time for

Student PEAS to mature before acquiring one.

The case organization exercised an incremental

implementation approach in adopting the new F-

AITS. The incremental implementation approach

can be detailed as spreading the implemented

modules over the time and focusing heavily on the

Central Finance as the live testing and maturing

entity before it is implemented to other business

units, including the Human Resources and Student

Admin departments. Implementation Stage 1 went

live in early 2003 and was considered successful.

The switch to accrual accounting for internal use

was initially delayed for another year and later, is

postponed for another additional year due to end-

users’ learning pace and resistance.

3.2 Research Design & Data

Collection

The case study research methodology was employed

to assess the roles of CoPs in knowledge transfer

during PEAS implementation. This methodology was

chosen for a number of reasons. CoP is an informal

issue and cannot be manipulated as investigators have

no control over actual behavioral events (Yin 1998).

Also, CoP is still a novel issue (Eisenhardt 1989)

especially in relation to PEAS implementation. As

the implementation is currently being executed in the

case organization, investigators can gain a real-time

and inside view (Yin 1998). Furthermore, an in-depth

longitudinal perspective was chosen here to capture

the ‘reality’ of different aspects of the

unpredetermined phenomenon in details across time

and at different phases of PEAS implementation.

Data were collected from multiple sources and

analyzed in different ways before being synthesized

for the discussion. Data collection was started with

the case-organization documentations [such as Fit-

Gap Analysis Review, Project Status Reports and

Newsletter, Training Needs Analysis Forms]. This

was followed by participant observation to the end-

users training, in-person and telephone interviews,

passive observation to the user-group meetings, and

through emails. The investigator also subscribed to

the end-users mailing list.

Several groups of people who work for different

sections of the University, including department-

level, faculty-level, the Central Finance central

administrative department, and the Project Team

[especially the Training/Change Management team]

were interviewed. Each group [except the

Training/Change Management team] was comprised

of at least one other person who use the system

intensively and another person who only use the

system indirectly. Each person was interviewed more

than one time over a period of approximately nine

months. Except for Central Finance (central) end-

ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

650

users, all other (local) end-users were interviewed for

the first time before the new financial information

system went live. All first interviews were in-person,

semi-structured with more general and open-ended

questions. The list of interview questions was

developed from themes based in the literature review

(Neuman 1997) as well as the practical work issues in

relation to the usage of information system and the

organization documentation review. The second and

later rounds of interviews were guided with more

specific questions based on their answers in the first

round. Some of these later interviews were conducted

in-person and some over the phone.

4 RESULTS & DISCUSSION

The Financial and Accounting [F&A] CoP was

present in the case university even before the new F-

AITS was implemented. The most concrete evidence

was the old Financial User Group Meeting [oFUGM]

and the old Financial User Mailing List [oFUML].

The focus of these periodic informal meetings and

mailing list was at the F-AITS and its usage. That is

why both were named after the system – and were

renamed after the new F-AITS went live as FUGM

and FUML respectively. Both of these community

entities are university-wide, and included both local

and central end-users.

CENTRAL COP LOCAL COPS

LIAISON

GROUPS

Selected Representative

TESTERS Selected Representative

TRAINERS

EARLY

SUPPORTS

Selected

Representative

Selected

Representative

SITUATED

LEARNING

Collective Collective

MAILING

LIST

PERIODIC

MEETING

Collective

University-wide CoP

The F&A CoP also exists at the business unit

level

, although, the existence of such community is

felt more strongly among the Central Finance

[central] end-users compared to among other business

units [local] end-users. This is mainly because the

local end-users are not only administering the local

Financial and Accounting works. They, except the

CoPs within business units (Wenger et al. 2002, p.26)

HR and Student Admin central administrative

department

end-users, also administer the local HR and

Student administrative works [including using the

HR-AITS and S-AITS]

as well as other

administrative office works. Even when using

the F-AITS, the local end-users in general use more

than one module while the central end-users tend to

focus on one specific module. In fact, the different

specializations among the central end-users have

caused a varied sense of ‘shared meaning’ to the

F&A CoP among diverse divisions within the Central

Finance. Local end-users identify themselves as

members of F&A CoP through the reificative

identification method while central end-users identify

themselves as members of F&A CoP either through

reificative or participative identification method.

4.1 CoPs & Knowledge Transfer

In general, F&A CoPs were represented by a few key

central end-users and key local management people

in the PEAS presentation sessions during the

chartering phase of the PEAS implementation. One

representative from the central community, who also

worked before as a local end-user, commented:

“The selection rules were pretty much set by the 1999

reviews, anyway. During the three-week selection

process, we were presented with three international

packaged software. Each [PEAS] was tested using

the same scenarios set by the Uni. … Their interface

was different compared to [the old F-AITS] but it

shouldn’t be a major problem. All three [PEAS] did

not exactly match the system requirements but each

vendor is willing to patch the gaps. I guess at the end,

it was the cost-benefit consideration … ehm, maybe

also the after-sales support, upgrading issue and the

alliance agreement that closed the deal. Anyway, the

final say came from the higher people up there, if you

get what I mean …”

There is a resistance from a small number of

local end-users in the case organization. But it is

more rooted on the argument “why replace the old F-

AITS”, not “why choose this PEAS” as suggested by

Howcroft and Light (2002)

. This resistance has

increased the need and the importance of end-user

based knowledge transfer as follows:

This means that they are also part of other university-

wide functional CoPs.

To date, the project is still considered successful though

there are some adjustment made to the initial

implementation plan due to a slower learning tempo and

the resistance.

Table 1: CoPs Involvement & Participation

KNOWLEDGE TRANSFER TO AND AMONG END-USERS IN PRE-PACKAGED ENTERPRISE APPLICATION

SOFTWARE IMPLEMENTATION: An Exploratory Study of the Roles of Communities of Practice

651

4.1.1 Liaison Group & User Acceptance

Tests

The first significant participation of key local end-

users was in the project phase, i.e. through the F-

AITS Liaison Groups. Eight

groups altogether were

formed to contribute in the configuration process of

this pre-packaged software. Each Liaison Group

brought together various stakeholders [local end-

users, Project Team members, external consultants,

and Module Experts representing central end-users]

to discuss any issues related to the implementation

including more directed activities like mapping

existing processes, identifying opportunity for

improvements, and redesigning required processes.

The participation of the first three stakeholders came

naturally while it was more nominated voluntary for

the local end-users. The local participants’ views

about partaking in the Liaison Group were mixed

between being useful and useless. It was mostly

valuable especially when the discussion was still

fresh. Getting in touch with other stakeholders’

perspective and being able to contribute into the

discussion helped to better understand the overall

picture of the PEAS implementation. For the local

participants, it was their first encounter with the new

system though only on the surface. Expectations on

the new system were high as the Project Team was

selling the integrated and superior capabilities of the

PEAS compared to the existing system. Some gaps

and/or misfits were uncovered but they were told that

customization was to be avoided as much as possible

as it was costly. They were also involved in the later

user-acceptance tests using some given scenarios.

One of only a few local end-users who tested the

system pointed out:

“I am glad that I decided to get involved in the user

testing. It was not a waste of time … It helped me to

understand the new system better. I told that to other

[user] trainers during our ‘Train the Trainer’ session

and they regretted that they were not involved.”

Based on their experience of joining the Liaison

Group, these local participants felt that should there

be any end-users involvement during the selection

process of PEAS, it would not have a significant

effect on the content of required knowledge transfer.

The only important knowledge that they could think

of getting through such involvement was the pre-

packaged nature of the new software which they

learnt also through the discussion in Liaison Group.

E.g.: Accounts Payable Group, General Ledger Liaison

Group, Reporting Liaison Group, etc.

Not all the user-trainers were involved in the user

acceptance tests. The test for each module only required

one local end-user and one central end-user as the testers.

Lesson: During the Liaison Group discussion, central

and various local CoPs’ members shared their legacy

business practices (Jones and Price 2001) to form an

integrated view (Pan et al. 2001), followed by the

streamlining process through some brainstorming.

This all was important for a correct PEAS

configuration. Here, CoPs in relation to knowledge

transfer played a role in sharing the knowledge of

various business units’ legacy business practice

among the members who participated in the group

meetings. The knowledge was also shared to the non-

members, i.e. the Project Team personnel and

consultants. In addition to that knowledge, those few

CoPs members learnt the knowledge of PEAS

business practice, though not much of the implicit

part, from the non-members. Furthermore, a limited

knowledge of the PEAS technical navigation was

transferred through a scenario-based practice in a

testing environment.

4.1.2 Formal Training by Module Experts &

User Trainers

After the PEAS was configured as the case

organization’s new enterprise system, formal training

was on the way to be delivered. The Module Experts,

who were trained earlier at the vendor’s headquarters,

trained their colleagues, other central end-users.

These Module Experts also trained the Training team

[a sub-team of the Project Team] who later executed

the “Train the Trainer” [TtT] program. The TtT

program turned sixteen

key local end-users from

various faculties

into user-trainers

which

sequentially conducted formal training for their

fellow local end-users. The final goal of this program

is to create local new-system-expert end-users so that

when these user-trainers return to their 'home base',

they can provide a support for their faculty-wide

community through a coaching/mentoring role. The

core difference between these [central] Module

Experts and these local expert end-users is the first

group specialized in one module for the usage of both

central and/or local end-users while the later group

focused across modules for the local usage only.

Were the trainees ready to start using the new

system after they completed their training cycle? A

local end-user directly answered:

Some of these sixteen people also partook in the earlier

Liaison Groups.

Though the grouping of these user-trainers was based on

their faculty-origin, it did not mean that they all were from

the local faculty-level CoPs.

They were not expected to become professional trainers

in such a short time though they were equipped with

trainer skills.

ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

652

“Absolutely not. The new knowledge is huge and sort

of confusing. It takes time to really munch the whole

idea about this big system. Even when the trainer

tried to focus down on a very specific function, you

still somehow have to know about other [related]

functions. But I guess it is a good idea not to confuse

yourself by trying to understand every single field

and its usage. And … practice makes perfect will

surely apply here.”

All other interviewed local end-users resonated

with a big no to that question. They gave varied

reasons but there was one commonality, i.e. they

need to internalize and put the taught explicit

knowledge into practice using the real system before

they could be really sure. But even without testing

this notion, they felt their lack of deep understanding

of the implicit business practice that worked in the

background had hindered them to see the whole

process flow.

Another departmental end-user commented that:

“I think we need to be trained in a live system. The

trainer told us more than once that ‘This step is not

necessary in Training as we have created for you

some generic accounts. But when you return to your

office, you need to do it’. And in another training

session: ‘You will not need to do this step in the live

system because the data will have been there. This is

just because we do not have the purchase order

number yet, so we have to create one before we can

do the matching’. … I even experienced one session

where the system was down, so we just went through

the training manuals.”

In one case, a trainee showed that he could

answer a question from a fellow trainee where the

user-trainer could not. A further investigation

revealed that this trainee had learnt about the new

system informally from his colleague prior to the

training. He learnt just by observing his colleague

performing a task using the live-system in a real

working environment and reading his colleague’s

training manuals. He sat in for the training partly

because it was a prerequisite to get authorization in

using the new F-AITS.

Overall, all end-users and even the Project Team

agreed that “Train the Trainer”, as just a variant of

the formal training, was insufficient in transferring

the whole aspect of PEAS knowledge. That is why

some support channels like Help-Desk have been

established to deal with the things left uncovered or

that could not be covered by formal training - even

conducted in a lab-based setting.

Lesson: The knowledge transferred through formal

training is not considered very task specific.

Voluminous materials presented in such a short time

and the teaching assumption of a perfect and normal

use of the new F-AITS [Wiedenbeck et al. 1995:

absence of error recovery information] devalue the

quality of formal training. At the end of the training,

end-users still can not comprehend the overall data

flow and the implicit business practice. Here, the

roles of CoPs in relation to knowledge transfer are

institutionalized. Some central and local CoP

members were involved formally in transferring the

knowledge of PEAS technical navigation and explicit

business practice to their fellow members. The

implicit business practice was intentionally not

covered for various reasons. At the end, the main

purpose of involving end-users in delivering the

training can be seen as an approach of capturing the

PEAS knowledge [especially the technical navigation

and explicit business practice parts which are more

easily transferred through formal ways with little

preliminary practice] among the university’s staff and

being more independent from external help as soon as

possible (Robey et al. 2002).

4.1.3 Support Channels & Situated Learning

Based on the prediction of a disruptive performance,

the Project Team activated several formal

community-based support channels, on top of the

online help, to back local end-users in using the new

system, especially in the earlier days of “go-live”.

Central end-users were covered by their Module

Experts as well as by the external consultants.

The central end-users [of the Accounting

Division, especially] learnt a lot through practicing

and informal training. They repeated the same tasks

again and again – very focused. They are the heavy-

usage end-users of the system. The volume has

helped them to master how to use the system and to

forget the previous practice that was not relevant

anymore. The other advantage of being so focused

was that they had more time to explore the system as

well to share among each other. They learnt more and

more through simply using the system frequently [i.e.

practicing]. The new business practice became

clearer and sensible when they shared any new

understanding to be tested by others (also evidenced

in Wenger et al. 2002).

The local F&A CoP within each faculty or

department is normally very small, on average it

consists of only four people

. In any composition, at

least one does the data-entry tasks and each data-

entry needs to be approved by a different person. In

summary, local end-users’ tasks can be categorized as

data-entry, budgeting and summary reporting. While

data-entry task is more monotonous and frequent as

This excludes the “Approver Only” end-users who will

only do approvals online – they were not the old F-AITS

end-users because that time approval was done on paper-

base.

KNOWLEDGE TRANSFER TO AND AMONG END-USERS IN PRE-PACKAGED ENTERPRISE APPLICATION

SOFTWARE IMPLEMENTATION: An Exploratory Study of the Roles of Communities of Practice

653

daily

, budgeting is once a year and summary

reporting is still more or less fed up from the Central

Finance. Hence, the budgeting and summary

reporting end-users are generally perceived as light-

usage end-users and the data-entry end-users as the

heavy-usage end-users of the system.

In the old F-AITS, local data-entry end-users

normally could try to get some help from their senior

colleagues first (not the other way around) before

they tried the Help-Desk. The logic was: data-entry

staff were newer than other staff; earlier, these other

staff had worked as data-entry officers so they had

the experience and knowledge to share. In the new F-

AITS, it is no longer the case if their senior

colleagues do not share the data-entry responsibility.

Even if their seniors do, they will normally do the

task more frequently than their seniors. It means they

will tend to know better than their seniors. Hence,

they go directly to the Help-Desk. Later, they find

that the Help-Desk is very useful and quick to answer

the system navigation and the solved operational

questions but not with the new operational problems.

In fact, they sometimes are referred to other more

advanced data-entry end-users [which are also local

end-users].

More than five hundred priority-one local end-

users were trained about a month before they started

to use the new F-AITS. They took the training when

they were still intensively using the old system [with

the old business practice mindset] to complete the

end of financial year tasks. On “go-live”, when they

were about to perform the same task using the new F-

AITS [with a different business practice], it was not

surprising that they had to recall what they have

learnt one month ago. But it was not the whole thing

as even the priority-two and -three local end-users,

who were trained after “go-live”, found that most of

the training knowledge could not be applied directly.

There was something else missing or it was simply

because the real practice was not as straight forward

as the training example. So they had to dig deeper

either from playing around and practicing, and/or

getting the helps from other end-users or the support

channels. One of the local end-users said:

“The system is pretty much new to all other [local]

staff. So I would prefer to go to the Help-Desk

directly.”

The rest indicated [when they were interviewed

before the system went live] that they would ask their

buddies – people to whom they used to relate when

using the old system which are normally their

superior or colleagues.

If the assistant is a casual (not a permanent) staff, then

data-entry works are likely to happen in batches every

second day or twice a week.

Central end-users were no better off than their

local counterparts. When they started to use the

system, a couple of days earlier than the local end-

users, they also needed a lot of help. As they were

only about 60 people, compared to around 1200 local

end-users, the support from the Module Experts and

consultants could be focused on them.

Both central and local end-users said that the

training was not sufficient. They needed more than

training knowledge to perform their work. Training

was able to introduce the software technical

knowledge and the explicit business practice. The

knowledge gained from such training was still more

in an explicit form (Nonaka 1994).

Though the daily usage of the accrual accounting

has been deferred, the new chart of accounts itself is

quite confusing. The old fifteen-character chart of

accounts now was changed to a twenty-seven-

character one. The initial problem was related in

setting up the correct [not too specific as well not too

broad] categories which was encountered before “go-

live”. After “go-live”, the problem was how to use it

consistently over the time and across all data-entry

officers within each business unit. In regards to this

consistent use issue, central end-users help to check

the data keyed-in by the local end-users but it was not

easy as each business unit has a different set of

categories.

At the earlier stage after “go-live”, everything

was slow. The same data-entry task took a longer

time as the end-users were still not familiar with the

system. But after more practice, entry time improved

though it has not reached expectations yet. The Mac

users still find the system a bit slow because of the

processing time – and are waiting for the vendor to

find a better solution. More things were learnt and

shared. Useful tips were gathered by the

FUGM/FUML principal and passed to the local end-

users during the FUGM and FUML.

Lesson: The nature of PEAS business practice and

IT-navigation knowledge put CoPs’ situated learning

[either informal training or practice] as a significant

and necessary complement to formal learning [i.e.

formal training] in the context of knowledge transfer.

Though both local and central end-users regard a

guided informal training as superior to a formal

training, this is impractical given the large number of

(especially local) end-users and as the usage of the

new system is rapid. Formal training can at least

introduce a general knowledge of the new system.

But it is not enough. The presence of support

channels like the Help-Desk is undeniable evidence

of formal training incapability. As the support is

normally a one-to-one help, empowering capable

end-users to take part in supporting novice end-users

is simply effective. This can have a significant impact

ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

654

on the project resources as well as on CoP cultivation

effort. Furthermore, this empowering process needs

to be regenerated by upgrading more end-users as

capable end-users to partake in this precious

knowledge transfer. Another interesting thing is the

evolution of local CoPs from colocated semi-

heterogeneous [e.g. department X CoP] to distributed

homogeneous [e.g. local data-entry CoP] because of

the new financial information system adoption.

4.2 CoPs to Steward the Dynamic

Nature of PEAS Knowledge

The knowledge about the PEAS is enormous and will

continue to evolve as the implementation process is

still ongoing. When end-users use the PEAS, they

learn more. This helps them to extend their usage of

the PEAS. By using it more, they learn more and vice

versa.

To date, the case organization’s end-users find

that there is new knowledge added to their system

knowledge bank every now and then through using

the system as well as interacting with other end-users.

The system is new so it will certainly take some time

to become proficient in using the system. Also, as

some deferred policy changes are being revealed,

there are more new things to learn.

Further training sessions are not an effective and

efficient way to convey these incremental updates

unless it is about a new module. A better way could

be through the periodic FUGM and/or the FUML –

both are part of the University’s F&A CoP and later,

the internalization of this updates can be socialized

through informal interaction among CoPs members.

The central modules experts and the local super-

users can play more significant roles in chairing and

addressing any ongoing issues in the FUGM and

FUML as the stewards of the PEAS knowledge. As

for the rest, FUGM and FUML can be a melting point

for newly-hired vs existing and heavy- vs light-usage

end-users. The existing end-users tend to revisit and

compare the logic between the new and old system

while the newly-hired ones do not. These two groups

apparently are heading in different directions. The

FUGM and FUML can be exploited to guide the

direction of these two groups. As for end-users with

different usages of the system, their learning speeds

are unequal. The meeting and the mailing list can

promote knowledge sharing among them to help the

slower ones to catch up with the rest. The light-usage

end-users can learn the mistakes from the heavy-

usage ones in using the system instead of reinventing

the wheel again. Also, in a practical way, these two

communication channels can be used to detect any

unwanted workarounds which can lead to identifying

unseen misfits [not mentioned in Fit Gap Analysis].

They can also function to promote the use of the

organization’s social capital in either a formal and

informal way as implied by one informant:

“I feel that there was a shift of knowledge sources

around the [university-wide F&A CoP]. People can

feel it through the meetings and the mailing list. …

But anyway, my point is even if one is shy to ask or to

contribute in the open forum, at least, he or she

knows to whom they should relate in regard to a

certain issue. So, he or she can do it later in a more

private way.”

5 CONCLUSIONS

Although the implementation program of the case

organization is still ongoing as well as its formal and

informal knowledge transfer processes, some

important lessons can be learnt.

Implementing any PEAS entails the adoption of

its “best” business practice. This business practice

contains more than just the canonical and codified

element (Lee and Lee 2000). Hence, formal training

alone, even with an incremental implementation

(Robey et al. 2002) – like this case study, is

insufficient and incapable of transferring all required

aspects of this knowledge. Furthermore, as each

individual learning approach is different (Boudreau

2003), it is best to exercise a wide-range of

knowledge transfer strategies – from formal to

informal ways. This is also inline with the nature of

the knowledge to be transferred. The knowledge of

software technical navigation and explicit business

practice needs to be internalized (Nonaka 1994) by

each end-user as part of individual learning process

before the canonical operation can be performed.

This internalization process takes time and needs

practice. It forms end-users’ quality of use (Boudreau

2003) of the new system in conducting their daily

works.

In the case organization, the PEAS adoption is

rapid although its implementation is gradual. All end-

users, either central or local, had to switch from the

old system to the new one in the course of a few of

days. Everybody is learning, and sometimes

unlearning as well as relearning. No one knows

everything, but there is massive knowledge to be

incorporated and more to come as the implementation

advances. Having decided to be knowledge-

independent as soon as possible, some key members

of the organization-wide CoP were assigned to

understand the new knowledge and to synthesize it

with the existing knowledge. Later they disseminated

the synthesized knowledge through formal and

informal ways.

KNOWLEDGE TRANSFER TO AND AMONG END-USERS IN PRE-PACKAGED ENTERPRISE APPLICATION

SOFTWARE IMPLEMENTATION: An Exploratory Study of the Roles of Communities of Practice

655

The main role of CoP in the knowledge transfer

to and among the end-users is as an enabler. CoPs

enable the PEAS end-users to share their knowledge

that they have learnt either formally and informally.

As end-users use the PEAS differently in terms of

usage-load and background, their learning process

differs in speed and direction. Here, CoPs enable the

PEAS end-users to avoid reinventing the wheel by

learning from others’ mistakes. At the same time,

CoPs also enable the PEAS end-users to assess,

revise, and shape the desired business practice for

competitive advantage purposes (Lee and Lee 2000)

through policy amendments, roles and

responsibilities redistribution. CoPs’ periodic

informal meetings and mailing list can be cultivated

to accommodate the above goals as well as to

promote the social capital usage.

Future research should investigate whether CoPs

can address end-user resistance towards a PEAS

adoption. That issue was not thoroughly investigated

in this study because it was categorized “sensitive”

by the case organization.

REFERENCES

AMR Research, 2000. Application spending & penetration

by vertical market: 2001-2002, The Market Analysis

and Review Series. AMR Research, p.72.

Boudreau, M.-C., 2003. Learning to use ERP technology:

A causal model. 36

Annual HICSS, Hawaii.

Brown, J. S. and Gray, E. S., 1995. The people are the

company: How to build your company around your

people. Retrieved August 5, 2003, from

http://www.fastcompany.com/online/01/people.html.

Davenport, T., 1998. Putting the enterprise into the

enterprise system. Harvard Business Review (76:4),

pp.121-133.

Davis, J., 1998. Scooping up vanilla ERP: Off-the-shelf vs

customized software. InfoWorld (20:47), pp.1-4.

Eisenhardt, K.M., 1989. Building theories from case study

research. Academy of Management Review (14:4),

pp.532-550.

Holland, C.P. and Light, B., 1999. A critical success

factors model for ERP implementation. IEEE Software

(17:3), pp.30-36.

Howcroft, D. and Light, B., 2002. A study of user

involvement in packaged software selection. 23

ICIS,

pp.69-77.

Jones, M.C. and Price, R.L., 2001. Organizational

knowledge sharing in ERP implementation: A

multiple case study analysis. 22

ICIS, pp.551-554.

Klein, H.K. and Myers, M.D., 1999. A set of principles for

conducting and evaluating interpretive field studies in

information systems. MISQ (23:1), pp.67-94.

Lave, J. and Wenger, E., 1991. Situated Learning:

Legitimate Peripheral Participation, Cambridge:

Cambridge University Press.

Lee, Z. and Lee, J., 2000. An ERP implementation case

study from a knowledge transfer perspective. Journal

of Information Technology (15), pp.281-288.

Markus, L. and Tanis, C., 2000. The enterprise systems

experience - from adoption to success. Framing the

Domains of IT Research: Glimpsing the Future

through the Past, Zmud, R.W. (ed.) Cincinnatti, OH:

Pinnaflex Educational Resources, pp.173-207.

Neuman, W.L., 1997. Social Research Methods:

Qualitative and Quantitative Approaches, 3

ed.,

Allyn and Bacon, USA.

Nonaka, I., 1994. A dynamic theory of organizational

knowledge creation. Organization Science (5:1),

pp.14-37.

Pan, S. L., Newell, S., Huang, J. C. and Cheung, A.W.K.,

2001. Knowledge integration as a key problem in an

ERP implementation. 22

ICIS, pp.321-328.

Robey, D., Ross, J.W. and Boudreau, M.-C., 2002.

Learning to implement enterprise systems: An

exploratory study of the dialectics of change. Journal

of Management Information Systems (19:1), pp.17-46.

Shang, S. and Seddon, P., 2003. Maximizing benefits from

enterprise systems. Paper presented to the UniMelb

OASIS Research Group, Melbourne.

Soh, C., Sia, S. K. and Tay-Yap, J., 2000. Cultural fits and

misfits: Is ERP a universal solution? Communications

of the ACM (43:4), pp.47-51.

Sumner, M., 2000. Risk factors in enterprise-wide/ERP

projects. Journal of Information Technology (15),

pp.317-327.

Wenger, E., 1998. Communities of Practice: Learning,

Meaning and Identity, Cambridge: Cambridge

University Press.

Wenger, E., McDermott, R. and Snyder, W.M., 2002.

Cultivating Communities of Practice, Boston: Harvard

Business School Press.

Wiedenbeck, S., Zila, P.L. and McConnell, D.S., 1995.

End-user training: An empirical study comparing on-

line practice methods. CHI’95 Proceedings.

Yin, R., 1989. Case Study Research: Design and

Methods, Sage, London, UK.

This term is developed from a very similar term coined in

a paper by Shang and Seddon (2003). Every letter in this

acronym “PEAS” is essential to distinguish PEAS from

other IT products. For example, the word ‘pre-packaged’

is to distinguish PEAS from custom-built EAS, or other

packaged EAS that do not need a significant configuration

[and, likely, customization] process before they can be

used appropriately.

The word ‘steward’ is coined as a verb by Wenger et al.

(2002) [e.g. in p.7 and p.26 of their book].

ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

656