Larsen Case1

8/12/2019 Larsen Case1

1/23

When success turns into failure: a package-drivenbusiness process re-engineering project in the

financial services industry

M.A. Larsena, M.D. Myersb,*

aKPMG, 8 Salisbury Square, London, EC4Y 8BB, UKbDepartment of Management Science and Information Systems, University of Auckland, Private Bag 92019,

Auckland, New Zealand

Accepted 6 March 2000

Abstract

This article discusses a Business Process Re-engineering project that involved the implementation

of an enterprise resource planning software package. Although the project was deemed to be a

success when the system was first delivered, this initial success soon turned to failure. While the

short-term financial results were spectacular, the long-term implications of the changes were more

worrying. This paper raises many questions about the meaning of success. In particular, it shows

how a successful implementation can, within a relatively short space of time, turn into failure.

1999 Elsevier Science B.V. All rights reserved.

Keywords: Business process re-engineering; Enterprise resource planning; Case study; Interpretivist perspective;

Information systems success; Implementation of information systems; Financial sector

1. Introduction

A substantial body of research in information systems has been concerned with IS

implementation and IS success. Some researchers have focused on success within

specific domains, such as Decision Support Systems (Alavi and Joachimsthaler, 1992),

Executive Information Systems (Bussen and Myers, 1997), or Business Process Re-engi-

neering (BPR) (Carr and Johansson, 1995; Teng et al., 1998), while others have focused on

the success of information systems projects more generally (Lucas, 1975; Ginzberg, 1981;

Journal of Strategic Information Systems 8 (1999) 395417

0963-8687/99/$ - see front matter 1999 Elsevier Science B.V. All rights reserved.

PII: S0963-8687(00)00025-1

www.elsevier.com/locate/jsis

* Corresponding author. Tel.: 64-9-3737-599, ext. 7468; fax: 64-9-3737-430.

E-mail addresses:[email protected] (M.D. Myers), [email protected] (M.A. Larsen).


2/23

Lucas, 1981; Ives and Olson, 1984; Swanson, 1988; DeLone and McLean, 1992; Robey et

al., 1993; Seddon, 1997).

This paper concerns the implementation of a package-driven BPR project. In package-

driven re-engineering, the idea is to redesign the business processesbeforeimplementingan enterprise resource planning (ERP) system, but to limit the process changes to those are

supported by the best practices built into current ERP packages. The BPR project in

question involved the implementation of an ERP software package, namely, SAP. While

the specific focus of this paper is on the success of BPR projects, the findings will also be

of interest to those concerned with the implementation of ERP systems and the imple-

mentation of information systems more generally.

The primary contribution of this paper is to suggest that success is a moving target.

The attribution of success can vary considerably depending upon the time at which the

evaluation is done. While the BPR project discussed here was regarded as a success at the

time of implementation, it was not regarded as such a few months later. The short-termfinancial results may have been spectacular, but the long-term implications of the changes

were more worrying. We also question the ease with which commentators attribute

success or failure to particular projects. We believe that the extent to which a project

is successful or not is not easy to determine, particularly if the viewpoints of various

stakeholders are taken into account.

A secondary contribution of this paper is to provide an in-depth case study of package-

driven BPR. A number of researchers have drawn attention to the lack of in-depth case

studies of BPR projects (Glasson, 1994; Grover et al., 1995; Hamilton and Atchison, 1996;

Willmott and Wray-Bliss, 1996). This paper can be seen as one response to the call for

more empirical in-depth case studies concerning the implementation of BPR in practice.The BPR project discussed here was one which involved the introduction of new work

processes, a new organisational structure, and the implementation of a new financial

information system within one organisation in the New Zealand financial services indus-

try. One of the purposes of the research was to understand the development and imple-

mentation of a BPR project over time.

The paper proceeds as follows: the following section discusses BPR, focusing specifi-

cally on BPR success. Section 3 describes the interpretive case study research method

that was used. In Section 4, the empirical evidence from the BPR case study is discussed.

Section 5 presents an analysis of the case, while Section 6 is a discussion of the findings.

Section 7 presents the conclusions.

2. BPR success

One of the difficulties in conducting research on BPR is that various terms are used,

such as Business Process Re-engineering, Business Process Redesign, or Business Process

Improvement. Not only are there disagreements about the scale of change or scope of

the processes being redesigned (Jones, 1994), but different definitions of the same term

are used in different studies. This makes it difficult to compare studies (Childe et al.,1994).

Rather than quibble about the definition of BPR, we prefer to take the pragmatic step of

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417396


3/23

simply using Hammer and Champys definition, which has been one of the most cited in

the literature. Their definition is as follows:

The fundamental rethinking and radical design of business processes to achieve

dramatic improvement in critical, contemporary measures of performance such ascost, quality, service and speed (Hammer and Champy, 1993, p. 2).

The underlying principles of the definition above are that re-engineering involves a

focus on business processes, should question the fundamentals, the change should be

radical, and the benefits proposed substantial. Other authors add that BPR is a deliberate

and planned phenomenon (Grover et al., 1995), and that it is usually enabled through

information technology (Benjamin and Levinson, 1993; Fielder et al., 1995). Various

approaches to doing BPR are presented in the literature (e.g. Davenport and Short,

1990; Carr and Johansson, 1995; Grover et al., 1995; Kettinger et al., 1997) and many

lessons have now been learnt (e.g. see Hall et al., 1993; Caron et al., 1994; Davenportand Beers, 1995; Stoddard and Jarvenpaa, 1995; Teng et al., 1998).

BPR is not without its critics. BPR has been criticised for increasing unemployment, for

disempowering staff (Willmott, 1994; Grey and Mitev, 1995; Willmott and Wray-Bliss,

1996), and for attacking structures that provide organisational identity (Bailie, 1995; Grint

et al., 1996). Furthermore, many BPR projects have failed (Willcocks and Smith, 1995).

Our aim in this paper is not to critique BPR per se, however; rather, our research has the

more limited goal of simply evaluating BPR success and the success factor approach

which has been associated with it.

As was mentioned earlier, a substantial body of research in information systems has

been concerned with IS implementation and IS success. One of the major streams ofresearch in this area has been the factor research approach. The success factor approach in

information systems implementation research attempts to identify those factors (variables)

which have the greater influence on IS success. Quantitative data is collected from a

sample of implementation sites in order to determine the relative importance of these

variables on the outcomes of implementation (Kwon and Zmud, 1987). Most of the

research into IS success or failure has resulted in descriptive lists of factors that lead to

one or the other. The assumption seems to be that if the practitioner is aware of these

factors and addresses them during implementation, then the IS project is more likely to be

successful.

In a similar fashion, a number of researchers have attempted to identify those factors,

which are associated with BPR success. In the BPR literature, the following factors have

been suggested as increasing the likelihood of BPR success: senior management support

and vision (Hammer, 1990; Robb, 1995); a strong project leader who is well respected and

committed (Robb, 1995); staying focused (Hammer and Stanton, 1995); well estab-

lished objectives, with aggressive targets (Robb, 1995); a project team consisting of a

mix of staff and consultants; the very best staff in the organisation for various functional

areas; a well planned change management and communication strategy (Hammer and

Champy, 1993); an effective methodology (Hammer and Champy, 1993; Robb, 1995);

the breadth and depth of the project (Hall et al., 1993); and two way communicationregarding the re-engineering process (Evans, 1994).

Grover et al. (1995) identified a large number of problem or failure factors associated

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417 397


4/23

with BPR, which they classified into nine categories. These were, in order of severity

(from first to last): change management; technological competence; strategic planning;

time frame; management support; human resource; process delineation; project manage-

ment; and tactical planning.Although much BPR implementation research has used the factor research approach,

this approach has been criticised in the IS implementation literature. Firstly, the factor

approach tends to view implementation as a static process instead of a dynamic phenom-

enon, and ignores the potential for a factor to have varying levels of importance at different

stages of the implementation process. It also fails to explain the relationship among the

factors (Ginzberg, 1981; Lucas, 1981). Secondly, there has been a lack of consistency in

the IS research and very few factors have been shown to be important across multiple

studies (Kwon and Zmud, 1987). Thirdly, the factor research approach is based on an

underlying mechanistic view of information systems implementation (Myers, 1994). The

attempt to identify variables associated with some measure of implementation successassumes that each factor is an independent variable and overlooks the interaction between

them and other elements in the social and organisational context (Nandhakumar, 1996).

The factor approach can be contrasted with many other approaches to understanding IS

success and failure. The process research stream, for example, has focused on the devel-

opment of a project; these studies have focused on issues such as the relationship between

designers and users and the impact of a system on the organisation (e.g. see Kwon and

Zmud, 1987; Newman and Robey, 1992). We believe that an awareness of this and other

research approaches to IS implementation could be helpful to BPR implementation

researchers, who until now seem to have focused almost exclusively on the factor research

approach.The factor approach can also be contrasted with interpretive approaches, which assume

that people are active makers of their physical and social reality (Orlikowski and Baroudi,

1991), that people are actors not factors. Mouritsen and Bjorn-Andersen (1991) argue that

agents actively construct everyday interaction in accordance with their wants. Humans

are not, as seems to be suggested by the idea of human factor, merely an inactive

although problematic part of a system, something that can be optimised through selection,

education, and training (Mouritsen and Bjorn-Andersen, 1991; p. 312). Bussen and

Myers (1997) found that the broader contextual issues surrounding a particular IS imple-

mentation had a greater influence than previously identified narrowly focused factors.

The two concepts of success and failure warrant further discussion. In the BPR litera-

ture, success and failure are often taken for granted; since the BPR literature emphasises

short term financial criteria, it tends to be assumed that it is relatively easy to determine

whether a particular BPR project is successful or not. For example, Hammer cites a 75%

reduction in head count (Hammer, 1990), while other researchers cite order delivery time

reduced from 33 to 6 days (Davenport and Short, 1990), US$1 million per plan cost

reduction (McCloud, 1993) or reducing costs of errors in fulfilling orders by US$2 million

dollars (Bambarger, 1994).

We question the apparent ease with which BPR projects are labelled a success or failure

by outside observers. In the IS implementation literature, there continues to be consider-able disagreement concerning how these concepts should be defined (Lucas, 1975;

DeLone and McLean, 1992; Sauer, 1993; Myers, 1995; Seddon, 1997). Following



5/23

Sauer (1993) and Myers (1995), we suggest that success or failure of a project can only be

determined by considering the opinions of the various stakeholders. It is also possible that

the opinion of stakeholders may change over time. A focus of this research, therefore, was

participants evaluations of the success or failure of the project and the way in which theirassessment of the project changed over the life of the project.

3. Research method

As was stated earlier, one of the main purposes of this research was to attempt to

understand the development and implementation of one BPR project over time. We

wanted to study one BPR project in depth, focusing on the process of BPR, the internal

and external factors or issues which influenced the process, the outcomes of the process,

and participants evaluations of the project. It was determined that the most appropriateresearch method for doing this was the interpretive case study.

Interpretive research focuses on the complexity of human sense making as the situation

emerges (Kaplan and Maxwell, 1994); it attempts to understand phenomena through the

meanings that people assign to them (Boland, 1985; Orlikowski and Baroudi, 1991).

Interpretive methods of research in IS are aimed at producing an understanding of the

contextof the information system, and theprocesswhereby the information system influ-

ences and is influenced by the context (Walsham, 1993).

The main value of the interpretive case study lies in itsdepth: as others have pointed out,

it allows the researcher to generalise from the case to theory, and to obtain deep insights

about IS phenomena (Walsham, 1995b). Conversely, one of its weaknesses is that it doesnot have much breadth (only one or a few organisations are studied). More extensive

discussions of the contributions which interpretive research can make to information

systems research can be found elsewhere (Walsham, 1995a; Walsham, 1995b; Myers,

1997a; Klein and Myers, 1999).

Data were obtained from formal interviews, numerous documentary sources, and many

informal discussions with some of the participants. Ten semi-structured interviews were

conducted with all the key players in the BPR project, including the project sponsor (who

reported directly to the CEO), process owner, members of the core BPR team, consultants

who supported the various phases of the process, and key users. The interviews lasted from

one to three hours. All interviews were tape recorded except one (the latter at the request of

the informant). The documents obtained included project deliverables, proposals, minutes

of meetings, internal newsletters and memoranda, annual reports, and articles from news-

papers and business magazines. The research was conducted by one of the authors over a

six-month period, from September 1996 to February 1997.

The focus of our analysis was one specific case of BPR, where we wanted to understand

the context and process of the project, and participants views concerning its success. The

data were used to construct an historical narrative of a BPR project in a financial services

company in New Zealand, from inception to final implementation. We paid attention to the

broader social and organisational context within which the project took place, andexplored the multiple interpretations of various participants over time. The primary criter-

ion we used for assessing the validity of our interpretations was the hermeneutic one of



6/23

seeing if they made sense (Myers, 1997b) and were believable both to ourselves and to

all the key people involved with the BPR project. Walsham suggests that the validity of

interpretive case study research depends on the plausibility and cogency of the logical

reasoning used in describing the results from the cases, and in drawing conclusions fromthem (Walsham, 1993, p. 15). We believe that this paper, while narrow in scope, offers

broad insights into the context and process of BPR.

4. The BPR case study

Alpha NZ Limited (a pseudonym) is a member of the New Zealand financial services

industry. Alpha was incorporated as a private company in 1986, comprised of nine sepa-

rate regional subsidiary financial service companies, all offering the same core financial

services. Each of the nine regional companies had their own regional head office whichserved as a regional processing centre for various functions for the company, and a number

of branches in various locations in that particular region. Each regional company had its

own accounting department, which performed tasks such as asset management, accounts

payable processing, management accounting, financial accounting, and reporting.

Management determined that the objectives of the BPR project in question were to

improve customer service, reduce costs, and improve the quality of the work performed.

The need for this was driven by deregulation of the financial services industry in New

Zealand in the late 1980s; increased competition, and the inefficiencies inherent in the

company due to the earlier merger of the nine separate regional companies. The project

used the standard BPR methodology of Gamma Consulting (a pseudonym for a large,multinational consulting firm).

4.1. The PQI movement

In order to understand how and why the BPR project was launched, we believe it would

be helpful to briefly review some of the key events and initiatives which led up to it. In

1993 (one year before the BPR project began) one of the regions of Alpha NZ Ltd

developed a quality program called PQIshort for Process Quality Improvement..

The objectives of this program were to improve the service to the customer, both internally

and externally. This program with its focus on the customer was welcomed by seniormanagement since this focus was not prevalent in the organisation at the time.

In view of the perceived success of PQI (at least in the eyes of senior management) and

the profitability of this one region, the leader of the PQI programme was invited to Alpha

NZ Ltd. Head Office in Wellington to help adopt this program for Alpha as a whole. As

part of this PQI initiative the management team appointed a consultant from a small

consulting firm, who took responsibility for this project. The consultant reported to the

Managing Director. Subsequently a new Alpha NZ Ltd vision and strategy was developed

called Service 2000. A travelling road show was created in which the Service 2000

initiative was presented to the regions and branches.

In the 1993 Half Yearly Report, the Managing Director commented on the PQI launch:

During the period, the Group took a significant step towards achieving the goals of



7/23

its Service 2000 quality process with the launch of a PQI programme. PQI is

designed to bring together the Groups family of companies in an integrated way.

Using international benchmarks, the Group is reviewing all aspects of its operations

to establish the most efficient way of delivering services. The aim is to free staff so

they can more effectively meet the changing needs of customers.

With regard to this PQI initiative, one Alpha staff member commented:

It was really trying to bring about a focus on customer service and quality of every-

thing that was done in the organisationIt was really saying that in the competitiveenvironment(that we found ourselves in) we couldnt continue as we were. And it

was time to review the way that we were structured and our general direction and our

key strategic objectives.

Along with the PQI initiative, three main projects were launched at this time, concerned

with Distribution and Strategy, Organisation Review, and Effective Customer Service.

The Organisation Review was given the responsibility for investigating the various func-

tions of the Head Office and the nine regional head offices, and indicating areas for

improvement. These developments are summarised in Fig. 1 above. As can be seen, the

internal PQI initiative which began in July 1993 led to an organisation review which inturn resulted in four key areas of the organisation being selected for further review and

redesign.

4.2. Re-engineering the accounting processes

Following on from the overall organisation review, four key areas of the organisation

were selected for further review and redesign. These were accounting, marketing, lending

and credit, and other head office functions. In order to focus our research efforts, we

decided to concentrate on the accounting redesign project only.

A project team was formed in February 1994 to redesign and implement new accountingprocesses. Five people from Alpha were appointed to the project team, including senior

accounting people from both the head and regional offices.


Fig. 1. The PQI initiative.


8/23

The first task was to select a consulting partner to aid in the redesign project. Of the

three consultancies contacted, Gamma Consulting was selected. Since Gamma was part of

a large international consultancy firm, it was felt that they had the expertise and knowledge

required. Two Gamma consultants were assigned to the project team, one of whom was

considered by the team as a BPR guru. His previous experience involved redesigning a

global financial institution based in the UK, and he was also involved full-time in two

other enterprise-wide re-engineering projects in New Zealand.

The senior consultant from Gamma Consulting explains what happened next.

We went for a chat with some of the accountants. We took them for a coffee and a

drink and talked to them about the way that we would go about doing the job. This

was a piddly little (project) in their mind, a 30 K deal. Pay peanuts and you get

monkeys dont you? They wanted a 30 K deal to redesign the accounting

processBy the time wed finished, we had explained to them we were going to

try to find out what accountants did, and do it properly. You cant do better than that.

As can be seen, the senior consultant from Gamma believed that the project would be

much larger than the Alpha accountants envisaged. According to him, Alpha NZ Ltd. had

about six different approaches to re-engineering. He was concerned about their piecemealapproach, but he felt that he was able to convince the members of the project team that the

scope of the new BPR project should be established as including all the processes within


Fig. 2. The Gamma consulting re-engineering methodology.


9/23

the accounting function. He also managed to convince the project team to use the standard

BPR methodology used by Gamma Consulting. It was from this point on, therefore, that

the project started to be labelled as BPR (the former term PQI now fell into disuse). The

BPR methodology as used by Gamma Consulting is illustrated in Fig. 2 above.In this methodology, the Data Gathering and Interview steps come first. These steps are

followed by various steps concerned with the analysis of activities, options and costs. For

example, the Responsibility Authority Expertise Work (RAEW) matrix helps to identify

key processes for improvement. The final report incorporates recommendations for the

redesign of management structures and processes.

In the first phase at Alpha, 60 people were interviewed from the nine regions over the

next four weeks. The interviewees included senior management, internal audit, and users

of the accounting information. Before the interviews were completed, the two Gamma

consultants approached two leading members of the project team and voiced their concern

that the project team as a whole would not support the recommendations that they believedwere needed. The consultants feared that the project team might be reluctant to support

any major redesign initiatives, particularly if this involved re-structuring the organisation

and a substantial number of people being made redundant. However, the two Alpha project

team leaders expressed confidence in the team members as whole. They raised a different

concern viz. that the senior Gamma consultant, the BPR guru, had left most of the work

to his more inexperienced colleague (the junior consultant did in fact possess considerable

business experience, especially with finance/banking audit clients, but lacked experience

in the BPR methodology). It was obvious to the Alpha NZ team members that the junior

consultant had not been through this process before, and due to his inexperience they felt

that they were lacking clear direction. Despite these reservations on both sides, GammaConsulting agreed to continue with the project.

A benchmarking study against Alphas seven major competitors indicated that Alpha

NZ Ltd. had the second highest staff levels compared to its main competitors, and the

second highest salary cost. However, the salary per employee was the lowest of the seven

competitors who responded to the questionnaire. This was interpreted as resulting from the

fact that Alpha had a large number of clerical accounting staff. Only 27% of the accounting

employees were accredited members of the Institute of Chartered Accountants of New

Zealandthis contrasted with one competitor where 80% of its employees were accre-

dited.

The benchmarking also revealed that six of the seven competitors were producing

monthly reports up to four days faster than Alpha after the month end close. Also, only

one of its competitors was using a custom written general ledger and subsidiary systems

such as accounts payable. The other six competitors were using commercially available

packages, with little or no customisation by in-house IT people. Additionally, the bench-

marking illustrated that none of the seven competitors managed a decentralised accounting

function, and only two of the seven had distributed some accounting functions into the

business units.

Subsequently a workshop was held on Gamma Consulting premises, in order to take the

project team away from the Alpha NZ Ltd. environment. The workshop was facilitated bythe BPR guru from Gamma Consulting. The project team agreed on the following

recommendations: (1) re-engineer the recording and reporting processput responsibility



10/23

back to the manager for their business; (2) automate routine accounting functions

develop a new integrated ledgers system; and (3) provide fingertip access to financial

informationdevelop a new integrated financial reporting and information system. It was

proposed that the new information systems would be selected and implemented within 18

months.

As part of the re-engineered accounting processes, a new corporate accounting team

would be established. This team would be a highly skilled and motivated group of people,

service driven and customer focused. The team members would be highly paid and

supported by the Group Manager of Finance and Treasury. The central accounting team

was to be responsive to service requirements, and be comprised of members with specia-lised expertise. The team would have responsibility for accounts payable, accounts recei-

vable and fixed assets; statutory and prudential reporting; procedure and policy formation;

systems accountants; and treasury accounting.

In addition to the establishment of a new corporate accounting team, a new position was

to be created in each of the nine regional companies, called a Regional Financial Adviser

(RFA). The RFAs would be responsive to service requirements and would proactively

provide financial insights and direction to the management team of each regional

company. The idea was that the RFAs would think strategically and proactively rather

than transactionally and reactively, and would be seen as valued, equal members of the

local management team. A Financial Adviser would also be appointed at head office. The

proposed organisational structure is shown in Fig. 3 above.

A major change to the recording and reporting process was facilitated by the idea that

people who order goods and authorise payments should input the data into the system

directly. This affected the accounts payable sub-process, which originates with a business

manager or person purchasing an item, through to receipt of the item for service and

payment.

These recommendations, along with some others, were presented to the management

board in May 1994. With an 88% reduction in headcount proposed in some areas, and clear

cost savings identified, the recommendations were accepted.In July 1994 a communication pack was sent to the managers of all the regional

branches. In this pack it was indicated that all accounting positions within Alpha NZ Ltd.


Fig. 3. The proposed organisational structure.


11/23

would be disestablished, and existing staff would need to apply for a new position with

the company. The process of re-deployment was also outlined in the communication pack.

4.3. Implementation

The beginning of the implementation phase was preceded by selecting an implementa-

tion-consulting partner. Of four consulting firms invited to propose, Omega Consulting

was selected primarily because one of the leading consultants within Omega seemed to

have the necessary people skills that the Alpha project team were looking for. Omega

also agreed to risk 15% of their consultancy fees against the success of the project.

The consultant from Omega Consulting recommended using his firms methodology for

selecting a new financial information system. This methodology for the selection and

implementation of integrated packages can be broken into two clear sub-phases: (1)

Design, Requirements Definition and Selection; and (2) Implementation.The first sub-phase involved creating the design of the accounting procedures and

processes (to a more detailed level than the first design phase), building the detailed

requirements for the new systems, and selecting a new integrated financial information

systems. At the beginning of this phase (early September 1994), the success criteria for this

phase of the project were defined by the project team and approved by senior management.

These criteria were as follows:

selection of a financial systems solution by 31 March 1995;

implemented processes and systems in a test environment by 1 October 1995; and

live operations systems and fully implemented organisation infrastructure by 31 Janu-ary 1996.

In terms of implementation, some specific measurable elements were considered, such

as appropriateness of systems design, adequacy of user training and so on. Some key

assumptions were factored into the success criteria, such as availability of Alpha resources

with the necessary skills; deliverables from resources external to the core project team

being on time; sufficient authorisation to push through new procedures and practices; the

ability to obtain additional resources if required, subject to budgetary constraint; the scope

of the project being not significantly affected by other initiatives; and the required tech-

nology infrastructure being implemented by required time scales. The summary and

detailed management plans were completed by mid-September 1994.

One of the most urgent tasks was now seen as preparing new job descriptions and

recruiting for these positions, as the plan to disestablish all accounting positions was

known to all staff. Alpha NZ Ltd. needed to retain their best people for these positions and

so wanted to recruit them for the new positions as soon as possible. Therefore manage-

ment started to appoint people to these new positions even while they were still performing

their existing jobs. This overlapping was necessary in view of the 18 month implementa-

tion time of the new information system and accompanying organisational structure.

In October 1994 a Request for Information (RFI) was issued to a large number of

vendors. After analysing the responses, a vendor shortlist was created. A detailed Requestfor Proposal (RFP) was prepared in November and the short-listed vendors given three

weeks to respond. After various demonstrations, reference site checks, and an evaluation



12/23

workshop attended by members of the project team, SAP emerged as the preferred vendor.

By February 1995 a contract was signed with SAP. The project team agreed that the

functionality of SAP best met the needs of Alpha NZ Ltd. The process of selecting a

vendor and specific software (the first sub-phase of Omegas implementation methodol-

ogy) is summarised in Fig. 4 above.

The second sub-phase of Omegas methodology for the selection and implementation of

integrated packages now began (i.e. implementation). In March the project team attendeda three-week in-depth training course in Sydney, Australia, while the hardware and soft-

ware was being installed at Alpha NZ Ltd. Over the next six months detailed software

development work was conducted until September 1995, at which point the acceptance

testing was completed. User training began in October and continued to the beginning of

December. Also in October, a parallel run was commenced, with the Wellington branch

chosen as the test site. After almost two months the parallel run confirmed that the


Fig. 4. The design, requirements definition and selection process.

Fig. 5. The SAP implementation process.


13/23

interfaces were working correctly and the system was ready for use. The new information

system went live in all branches on 1 December 1995.

During December 1995 and January 1996 all the changes to the organisation structure,

business functions and staff which had been recommended earlier were put in place. On 31January 1996, those staffs who were not able to be re-deployed were made redundant. The

accounting staff full time equivalent (FTE) fell from 75 to 24, a headcount reduction of

68%.

Therefore, by the beginning of February 1996, the new systems were implemented, the

new processes in place, and the new head office accounting team were established. On 8th

March 1996 the project was signed off by Omega Consulting and passed to the project

sponsor, and a Project Sign Off Report was delivered to Alpha NZ Ltd. from the project

manager. Omega Consulting was paid its commission in full. The process of implementing

the SAP software (the second sub-phase of Omegas implementation methodology) is

summarised in Fig. 5.

4.4. Post implementation

The following months did not proceed so smoothly as the ones just gone. With some

members of the project team being made redundant, one member joining Omega Consult-

ing as an IT consultant, and others being moved sideways, none of the original project

team members were left in group accounting. All in-house expertise had disappeared from

the central accounting group.

Some report development was identified in the Project Sign Off Report as an uncom-

pleted task of the project, and some new report development was also suggested (theidentification of these reporting needs arose towards the end of the project implementation

phase). However, due to the low level of skill present at the accounting head office with

regard to the use of the new system, this task was not completed. Other new management

reports were identified likewise, but these too were not forthcoming.

In April 1996 the Regional Financial Advisers met to discuss their difficulties in the

post-implementation period. The main area of difficulty identified was the lack of report-

ing from the new system. The majority of the statutory reports had been developed and

they were considered to be superior to the statutory reporting previously available under

the old system, however the lack of management reporting was starting to cause difficul-

ties. One Regional Financial Adviser (RFA) commented There was a lack of leadership

and buy-in from Group Accountingit was evident to all the RFAs (at our meeting). In

response to these difficulties and to satisfy increased user expectations, Group Accounting

agreed to hire a consultant from Omega Consulting to write the new reports.

In April 1996, however, it was announced that Beta Limited (a pseudonym) had the

intention to purchase 100% ownership of Alpha NZ Ltd. shares, and a merger would be

taking place. As soon as the merger was announced, a moratorium was placed on hiring

new staff, and the development of management reports was placed on hold until the future

of the system and the requirements of the new company could be determined. New

reporting requirements for Beta Ltd. were given top priority and existing resourceswere diverted to develop these reports for the new owners.

A post implementation review was conducted in early April. This involved interviewing



14/23

key staff and preparing a report for the executive committee overseeing the merger. One of

the findings of this report was that staff morale was low in the head office accounting team.

This was believed to be partly caused by poor management and poor leadership skills. The

staffs had undergone a major structural and process change, and were not being adequatelysupported by their manager. Further, the lack of skill and expertise in the system they were

now using was low, and affected their confidence in it. The recent announcement of the

merger had also de-stabilised their future with the company, and many were feeling

insecure about their positions. Staff morale had plummeted.

By September 1996 there were no longer any accounting staff in any of the regional

companies. The Regional Financial Advisers (who had been appointed as a result of the

project) were made redundant and their work re-centralised. Group Accounting Alpha NZ

Ltd. was merged with Group Accounting Beta Ltd. and there were a number of redun-

dancies here also. The newly merged company received a name change, and is now known

as Beta-Alpha Ltd. (a pseudonym).In October 1996 it was announced that Beta-Alpha Ltd. would be implementing Oracle

financials as their back office accounting system in place of the existing SAP system. Beta

Ltd. Australia (which owned the NZ organisation) mandated that the system they had

previously selected as their core financial MIS was to be implemented in their New

Zealand subsidiaries also. The devolvement of invoices to line managers was also re-

centralised to the new Group Accounting team. In effect, this meant that almost all of the

changes and systems that had been implemented as part of the BPR project at Alpha had

now been discarded.

5. Analysis of the case study

5.1. A summary of the case

We have seen that, although Alpha NZ Ltd. had developed its own approach to business

process improvement early on (called PQI), the consultants from Gamma Consulting

managed to convince the Alpha project team that the companys previous approach was

piecemeal. The consultants suggested that Alpha should use Gammas standard BPR

methodology, and that all of the accounting and management reporting processes should

be re-designed at once. Clearly, the consultants believed that their own professionalapproach to BPR was better than Alphas own in-house efforts, although it may well be the

case that the use of Gammas standard BPR methodology made it easier for them as well

as being in accordance with Gamma company policy (c.f. Orlikowski, 1991).2 The project

was thus redefined and renamed as BPR by this large international consulting firm.

It is somewhat debatable as to whether the project can be genuinely classified as BPR.

While the Gamma consulting methodology, as shown in Fig. 2, involved identifying and

documenting key processes for improvement, there was little business process mapping

and redesign as is usually associated with classical BPR methods. On the other hand, the


2 See also Orlikowski (1991), who discusses, amongst other things, the importance which one internationalsoftware consulting firm placed on the use of its standard information systems development methodology by its

clients.


15/23

two consulting firms (both of which are amongst the Big Five) unequivocally described the

project as BPR from start to finish. Their recommended BPR approach was to select an

integrated package in what can be best described as package-driven re-engineering.

Our view is that the package-driven re-engineering approach of the two internationalconsulting firms can be classified as business process re-engineering, even if it is not

classical BPR. The key idea of this approach is to redesign the business processesbefore

implementing an ERP system, but to limit the process changes to those are supported by

the best practices built into current ERP packages. The business processes themselves

are thenimplementedby installing an ERP system. In other words, the implementation of

an ERP enables the implementation of the redesigned processes, and both these events

occur simultaneously.

The objectives of the BPR project within Alpha NZ Ltd. were to improve customer

service and quality, and reduce costs. The immediate outcome was the creation of a new

accounting organisational structure, new work processes, and a new financial informationsystem. A 64% reduction in FTE accounting staff from 67 to 24 was experienced, with

projected savings of approximately $2.1 million per annum.

Some three months after the go live date, however, news of a merger halted all further

post-implementation work. This included the development of important user reports.

Following the merger, the structures of Alpha NZ Ltd. were merged with those of the

new owner, and many of the new processes and structures were undone. A new infor-

mation system was to be implemented by the end of 1997 to replace the SAP solution

implemented as part of the BPR project.

5.2. A BPR success or failure?

We would now like to consider the question of whether the BPR project at Alpha NZ

Ltd. was a success or a failure.

If we were to end the story of the BPR project in February/early March 1996, an

assessment of the project would most likely be favourable (if one excludes those made

redundant, that is). Everyone involved with the project agreed that the short term financial

savings were considerable, with a 64% reduction in FTE accounting staff and projected

savings of approximately $2.1 million per annum.

Some two months later, however, the picture had changed considerably. An unintended

consequence of the BPR project was that none of the original project team members were

left in group accounting, and all in-house expertise had disappeared from the central

accounting group. Those now in the accounting head office had a low skill level, and

morale was low.

It could be argued that the BPR project contained the seeds of its own destruction. Its

financial success was only achieved by a dramatic reduction in headcount, but those who

left the company were arguably the most skilled and capable within the Alpha accounting

function. The dramatic reduction in headcount looked good on paper, but by losing some

of its best people, the capacity of the organisation to respond to future events was drama-

tically impaired. It appears that the problems which emerged (such as the lack of manage-ment reporting with the new system, the low skill levels of staff) were a logical

consequence of the BPR project itself.



16/23

In our view the loss of the most skilled and capable people from the central accounting

team at Alpha was a serious mistake. A few months after implementation, not one person

in-group accounting had the expertise or the skills to use SAP properly. When the re-

engineered Alpha company was taken over by Beta Ltd., the latter company had anexcellent excuse to undo all of the changes which had been made. Indeed, it would appear

that this step was almost inevitable, given the inability of the remaining Alpha staff to use

the new system profitably.

Approximately six months after the project was completed, some of the various stake-

holders were asked their opinion concerning the success or failure of the BPR project.

The BPR guru from Gamma Consulting believed that the BPR project was a resound-

ing success. He said:

It was a phenomenal integrationIt was a piece of good professional work, that

went far beyond what I think they had expected of it. And the opportunities it gave

themIm proud of it. I think we did a good jobWe came up with something at

Alpha Ltd., which was out of this world. Nobody else up to that point had anything

like it.

The project manager from Omega Consulting also believed that the project was a success.

The project achieved what it set out to do, and Omega was paid its commission in full. He

explained:

Yes, (it was a success) because Alpha NZ Ltd. was always going to be sold off.

Right? It was targeted from the day I joinedThe payback on SAP was already

there by the time Beta Ltd. in fact took over. People ask me this question, and I think,yes absolutely. I mean we were packaging Alpha for sale. The market always knew

that Alpha was going to be taken over.

All of those involved in the BPR project team also believed that the project was

successful, although they were not as positive as the consultants from the two consulting

firms. One Group Manager on the project team commented that the success was due to

strong CEO commitment, good effective project sponsorship, good communication, and

regular planning, review and control. With further questioning, however, this manager

admitted that the lack of ongoing ownership by the head office group accounting team after

implementation was a problem and that the users were dissatisfied. She said that the

majority of people appointed to the new positions in head office did not have sufficient

skill and experience for the roles they were appointed to, and the ability and commitment

of these people was questionable.

I think the main reason things didnt work out like they were supposed to was

something that I didnt really have control overthe staff appointments in Group

Accounting, the peopleWe identified key people within the organisation to

trainand we had specific people down for training, and some of them just wouldnt

turn up for it.

Another person on the project team was the Group Accounting System Accountant. Hebelieved that the project was successful overall and attributed success to the key factor of

management commitment. However, he too commented that ownership of the system by



17/23

Group Accounting was a problem and said that the project could be seen as unsuccessful

in final delivery in terms of Group Accounting being the ultimate (end user) of the

system.

The reaction of the users was not nearly as positive as the consultants or those on theproject team. One of the newly appointed Regional Financial Advisers believed that the

project was a failure. While the new processes and structure had been put in place, the lack

of reporting was a serious problem. She commented:

The main advantage (of the project was supposed to be) the great computer system

with all reporting on the system, and therefore RFAs could analyse and interpret the

information and provide commentaryBut this never happened to the extent they

envisaged.

This person, along with all the other RFAs, was expecting a level of information to be

provided by the new system, which did not eventuate. The lack of management reports hadcaused considerable dissatisfaction.

The Manager of Retail Services said that the project was successful except that it failed

to deliver what was expected in terms of management reporting. He commented:

As users from the company, then, we did not get what we wanted out of the new

accounting system, and our requirements were actually quite clearly documented-

After he (a particular member of the project team) left, they seemed to be sidelined

on another task, and we then had to deal with X (another person) and say, look, we

need these, when are they going to be done?And the deadlines were not met, not

met, not met. And theyre still not met.Another user claimed that the project failed because of the lack of reporting. One Group

Accounting Manager commented that not retaining the in-house project team members

was a mistake.

It can be seen, therefore, that two main groups of stakeholders, the developers and the

users, did not agree on the success of the BPR project, neither did they agree on those

factors which led to success or failure. The one point on which almost everyone

agreed was that there was a lack of ownership from Group Accounting and the Group

Accounting Manager in the post-implementation phase. However, as we said earlier, the

low-skill level in-group accounting was a logical outcome of the BPR project itself.

It is also interesting to note the significant difference between what was proposed for

Group Accounting and the eventual outcome. According to the original project proposal

the new corporate accounting team was supposed to be a highly skilled and motivated

group of people, service driven and customer focused. The team members would be

highly paid, responsive to service requirements, and be comprised of members with

specialised expertise. But as all those involved with the project acknowledge, this vision

for Group Accounting did not eventuate. The majority of people appointed to the new

positions in head office did not have sufficient skill and experience for the roles they were

appointed to, and, according to some on the project team, the ability and commitment of

these people was questionable. Although most of those on the project team blamed thepeople themselves for their lack of commitment, it is hard to see why these people should

have been highly motivated and committed when all previous in-house expertise had



18/23

disappeared (either through redundancy or people obtaining work elsewhere). When the

company announced in 1994 that all accounting positions at Alpha would become dises-

tablished and that existing staff would need to apply for new positions, many of the best

people left for positions elsewhere, and many of those that stayed with the company feltinsecure about their positions. We suggest that the lack of expertise and low morale were

thus a logical consequence of the dramatic reduction in headcount that was envisaged and

achieved.

It is interesting to note that all the participants did not perceive the take-over of Alpha

by Beta Ltd. to have affected the success of the project. They all recognised that the

strategic direction, mission, and culture of the new company were different to Alphas.

As a subsidiary company, Alpha NZ Ltd. had no choice but to merge with Beta Ltd.,

therefore this was not believed to indicate (or be a factor in) the failure of the BPR project

in any way.

6. Discussion

As was mentioned earlier, most BPR implementation researchers have focused almost

exclusively on the factor research approach. This approach attempts to identify those

factors associated with BPR success or failure. In our literature review, however, we

showed that the factor research approach has been criticised in the IS implementation

literature. We suggested that an awareness of the criticisms of the factor research approach

could be helpful to BPR implementation researchers.

Further to that discussion, we are now in a position to comment further on the factorresearch approach. First, the Alpha NZ case has shown that attention to success factors can

limit the focus on success to immediate implementation outcomes. The package-driven

BPR project was deemed to be successful by Alpha management when SAP went live, and

Omega Consulting was paid its commission in full. The staff reductions and the projected

cost savings made the project look good on day one. But as we have seen, a focus on

immediate success does not necessarily equate to success a few months down the track.

The focus on immediate success is thus too narrow.

Second, package-driven BPR by its nature focuses consultants and vendors on imple-

menting the package rather than continuing operation. This case draws attention to the

dangers of concentrating too hard on factors leading to successful package implementa-

tion and immediate BPR savings. While the system was implemented on time and within

budget, the long-term implications of the changes were more worrying. The dramatic

reduction in headcountand the corresponding loss of knowledgeactually impaired

the capacity of the organisation to respond to future events.

Third, the key dependent variable in the factor research approach (success) has been

shown to be rather difficult to define. Success is open to many different interpretations.

Indeed, if one considers the views of the various stakeholders, as is suggested by Myers

(1995) and Sauer (1993), then it appears that the labelling is more of a political declaration

made by interested parties than it is a statement of factsuccess depends upon who youtalk to. From this perspective it is understandable why the various stakeholders voted the

way they did: firstly, the consultants judged the project an unqualified success since they



19/23

were the ones that promoted BPR in the first place and were paid to do it; those involved

with the project team unanimously viewed the project as a success since they were the

ones primarily responsible for the end result; the users, by contrast, were somewhat mixed

in their evaluation, since they seemed to have gained least from the new system. Also,those who were appointed to the new positions in Group Accounting were not the

highly paid, specialised experts that were promised.

It is rather difficult to definitively class the project as either a success or a failure.

The arguments in favour of the project being a success are as follows. First, most of the

factors (reviewed earlier) correlated with success were indeed present in this case (e.g.

senior management support and vision was present, as was a strong project leader).

Additionally, staff in the project team came from both the regions and the head office,

and could therefore understand the organisation structure, culture and processes from each

perspective. All members of the team indicated that the team environment and spirit was

one of the aspects they enjoyed most about the project.Second, it was suggested by some of our informants that the decision by Beta Ltd. to

merge the two companies, disregard the changes and replace the information system was

purely a political one (in fact one senior manager claimed that there was no review to

determine if SAP was the best product for the New Zealand operationsthe new owner

simply stated that Oracle was to be implemented). If this is the case, then those involved

with the BPR project at Alpha can hardly be blamed for failure.

Third, if one of the consultants from Omega Consulting is correctthat the whole point

of the BPR project was to prepare Alpha NZ Ltd. for salethen the project can be said to

have achieved its purpose. Taking all these things together, the project looks like a

resounding success.There are a number of reasons for regarding the BPR project as a failure, however. First,

the new system itself was discarded by Beta Ltd. Although Betas decision may have been

influenced by an overriding requirement to achieve integration between the two organisa-

tions, the user dissatisfaction with the new system and the lack of skill within Alpha group

accounting certainly gave Beta Ltd. an excellent reason to scrap the system. Second, the

claim that the BPR project was intended to prepare Alpha for sale was made by one of the

Omega consultants some six months after the project was completed. There was no hint of

a takeover earlier on in the project (for example, none of the consultants from Gamma

mentioned such a possibility). This leads us to believe that the claim of preparing Alpha

for sale was most likely one of post-hoc justification.

An assessment of the success or failure of the project also varies depending upon

the time at which the evaluation is done. In February/early March 1996, immedi-

ately after the new information system was implemented, the Project Sign Off

Report indicated that the success criteria as outlined earlier in the project plan

had been met. The projected financial savings were considerable. As a result

management agreed to pay Omega Consulting its 15% retainer for successful

completion of the project. Only a few months later, however, the post implementa-

tion review found that staff morale in the head office accounting team was low. The

newly appointed Regional Financial Advisers and the users in Group Accounting weredissatisfied with the lack of management reporting. Since the RFAs did not have the

necessary information to think strategically and proactively as was originally envisaged,



20/23

it is perhaps not surprising that they themselves were made redundant following the

merger with Beta Ltd.

This leads us to suggest that narrow-focused, head-count cutting BPR is particularly

susceptible to time-dependence of evaluation outcomes. As Galliers (1997) points out,there is a significant risk of loss of knowledge in radical BPR. But the realisation that

valuable knowledge has been lost might only occur when it is too late. This particular case

study has illustrated how a BPR project, deemed to be a success when it was first

completed, can soon turn to failure. The overriding goal to achieve short-term financial

success can lead to serious organisational problems over the longer term.

7. Conclusion

In this paper we have discussed a BPR project that involved the implementation of anERP software package. The BPR project involved redesigning the accounting processes of

a financial services firm in New Zealand.

Although the project was deemed to be a success when the system was first delivered,

the project ended up as a failure. While the short term financial results were spectacular

(e.g. headcount reduction of 68%), the long-term implications of the changes were more

worrying. At the conclusion of the project Alpha NZ Ltd. had staff in the newly centralised

accounting group with low skill levels and low morale. The loss of all in-house expertise

from the central accounting team was disastrous.

This case study has shown that IS success is a moving target. The attribution of

success can vary dramatically depending upon the time at which the evaluation is done.While the BPR project discussed here was regarded as a success at the time of imple-

mentation, it was not regarded as such just a few months later.

Our findings also call into question some of the underlying assumptions of factor

research. One of these assumptions is that the success and failure of any particular

project is relatively easy to determine (as if these terms represent objective states). The

assessment of success or failure is often taken for granted, not only of one project, but of

several. But as we have seen, the extent to which a project is successful or not is not easy to

gauge. The extent to which the project was seen as a success varied considerably amongst

the various stakeholders and their views changed over time. In this instance, the labelling

of the project as a success or failure seems to have been more of a subjective judgement

made by interested parties than an objective fact. We believe that some caution is

therefore advisable when researchers assume that one or more BPR projects are successes

or failures.

Another underlying assumption of the factor research approach is that, if only practi-

tioners can be made aware of the factors that lead to success (or failure), then BPR

implementation is more likely to be successful. But as we have seen in this case, short-

term success may lead to failure further down the track. While the success criteria as

outlined in the project plan were achieved, it was only some months later that serious

problems became apparent (e.g. the low level of skill and morale at head office). We hopethat further research will shed more light on the long-term implications of BPR and on its

implementation and evaluation.



21/23

Acknowledgements

We are grateful to all those who agreed to be interviewed and who gave access to

company data. We would also like to thank the Management Consulting staff in theKPMG Auckland office and the University of Auckland Business School for some finan-

cial assistance. Additionally, we are grateful to the Associate Editor and the reviewers for

their critical and constructive comments on an earlier version of the paper. This manu-

script is a substantially revised version of a paper which was presented at the Eighteenth

International Conference on Information Systems in Atlanta, Georgia, from 1517

December 1997, and was published in its proceedings.

References

Alavi, M., Joachimsthaler, E.A., 1992. Revisiting DSS implementation research: a meta-analysis of the literature

and suggestions for researchers. MIS Quarterly 16, 95113.

Bailie, J., 1995. Should personnel managers be more critical of BPR?. Personnel Management, 55.

Bambarger, B., 1994. Corning Asahi Video Products Co. Eliminates Cost of Errors for $2 Million Savings.

Industrial Engineering July, 2829.

Benjamin, R.I., Levinson, E., 1993. A framework for managing IT-enabled change. Sloan Management Review

34 (4), 2333.

Boland, R., 1985. Phenomenology: a preferred approach to research in information systems. In: Mumford, E.,

Hirschheim, R.A., Fitzgerald, G., Wood-Harper, A.T. (Eds.). Research Methods in Information Systems,

North Holland, Amsterdam, pp. 193201.

Bussen, W., Myers, M.D., 1997. Executive information systems failure: a New Zealand case study. Journal of

Information Technology 12 (2), 145153.

Caron, J.R., Jarvenpaa, S.L., Stoddard, D.B., 1994. Business reengineering at CIGNA Corporation: experiences

and lessons learned from the first five years. MIS Quarterly 18 (3), 233250.

Carr, D.K., Johansson, H.J., 1995. Best Practices in Reengineering: What Works and What Doesnt in the

Reengineering Process, McGraw Hill, New York.

Childe, S.J., Maull, R.S., Bennett, J., 1994. Frameworks for understanding business process re-engineering.

International Journal of Operations and Production Management 14 (12), 2234.

Davenport, T.H., Beers, M.C., 1995. Managing information about processes. Journal of Management Information

Systems 12 (1), 5780.

Davenport, T.H., Short, T.E., 1990. The New Industrial Reengineering: Information Technology and Business

Process Redesign. Sloan Management Review Summer, 1127.

DeLone, W.H., McLean, E.R., 1992. Information systems success: the quest for the dependent variable. Informa-tion Systems Research 3 (1), 6095.

Evans, R., 1994. The human side of business process re-engineering. Management Development Review 7 (6),

1012.

Fielder, K.D., Grover, V., Teng, J.T.C., 1995. An empirical study of information technology enabled business

process redesign and corporate competitive strategy. European Journal of Information Systems 4, 1730.

Galliers, R.D., 1997. Against obliteration: reducing risk in business process change. In: Sauer, C., Yetton, P.W.

(Eds.). Steps to the Future: Fresh Thinking on the Management of IT-Based Organizational Transformation,

Jossey-Bass, San Francisco, pp. 169186.

Ginzberg, M.J., 1981. Key recurrent issues in the MIS implementation process. MIS Quarterly 5, 4759.

Glasson, B.C., 1994. Business process reengineering: information systems opportunity or challenge?. In: Glasson,

B.C., Hawryszkiewycz, I.T., Underwood, B.A., Weber, R.A. (Eds.). Business Process Re-Engineering:

Information Systems Opportunities and Challenges, North Holland, Amsterdam, pp. 16.Grey, C., Mitev, N., 1995. Re-engineering organisations: a critical appraisal. Personnel Review 24 (1), 618.

Grint, K., Case, P., Willcocks, L., 1996. Business process re-engineering reappraised: the politics and technology



22/23

of forgetting. In: Orlikowski, W., Walsham, G., Jones, M.R., DeGross, J.I. (Eds.). Information Technology

and Changes in Organizational Work, Chapman and Hall, London, pp. 3961.

Grover, V., Jeong, S.R., Kettinger, W.J., Ten, J.T., 1995. The implementation of business process re-engineering.

Journal of Management Information Systems 12 (1), 109144.

Hall, G., Rosenthal, J., Wade, J., 1993. How to make reengineering really work. Harvard Business Review 71 (6),119131.

Hamilton, D., Atchison, M., 1996. The COMIS plan: IT mediated business reengineering in Telecom Australia

during the 1960s. In: Orlikowski, W., Walsham, G., Jones, M.R., DeGross, J.I. (Eds.). Information Technol-

ogy and Changes in Organizational Work, Chapman and Hall, London, pp. 89106.

Hammer, M., 1990. Reengineering work: dont automate, obliterate. Harvard Business Review JulyAugust,

104112.

Hammer, M., Champy, J., 1993. Reeingeering the Corporation: A Manifesto for Business Revolution, Nicholas

Brealey, London.

Hammer, M., Stanton, S.A., 1995. The Reengineering Revolution: a Handbook, Harper Collins.

Ives, B., Olson, M.H., 1984. User involvement and MIS success: a review of the research. Management Science

30 (5), 580603.

Jones, M.R., 1994. Dont emancipate, exaggerate: rhetoric, reality and reengineering. In: Baskerville, R., Smith-

son, S., Ngwenyama, O., Degross, J.I. (Eds.). Transforming Organizations with Information Technology,

North-Holland, Amsterdam, pp. 357394.

Kaplan, B., Maxwell, J.A., 1994. Qualitative research methods for evaluating computer information systems. In:

Anderson, J.G., Aydin, C.E., Jay, S.J. (Eds.). Evaluating Health Care Information Systems: Methods and

Applications, Sage, Thousands Oaks, pp. 4568.

Kettinger, W.J., Teng, J.T.C., Guha, S., 1997. Business process change: a studyof methodologies, techniques, and

tools. MIS Quarterly 21 (1), 5580.

Klein, H.K., Myers, M.D., 1999. A set of principles for conducting and evaluating interpretive field studies in

information systems. MIS Quarterly 23 (1), 6793.

Kwon, T.H., Zmud, R.W., 1987. Unifying the fragmented models of information systems implementation. In:

Boland, R.J., Hirschheim, R.A. (Eds.). Critical Issues in Information Systems Research, Wiley, New York,pp. 227251.

Lucas, H.C.J., 1975. Why Information Systems Fail, Columbia University Press, New York.

Lucas, H.C.J., 1981. Implementation: the key to successful information systems, Columbia University Press, New

York.

McCloud, J., 1993. McDonnell douglas Saves Over $1,000,000 per Plane With Reengineering Effort. Industrial

Engineering October, 2730.

Mouritsen, J., Bjorn-Andersen, N., 1991. Understanding third wave information systems. In: Dunlop, C., Kling,

R. (Eds.). Computerization and Controversy, Academic Press, San Diego, pp. 308320.

Myers, M.D., 1994. A disaster for everyone to see: an interpretive analysis of a failed IS project. Accounting,

Management and Information Technologies 4 (4), 185201.

Myers, M.D., 1995. Dialectical hermeneutics: a theoretical framework for the implementation of information

systems. Information Systems Journal 5 (1), 5170.

Myers, M.D., 1997. Qualitative research in information systems. MIS Quarterly 21 (2), 241242.

Nandhakumar, J., 1996. Design for Success?: critical success factors in executive information systems develop-

ment. European Journal of Information Systems 5, 6272.

Newman, M., Robey, D., 1992. A social process model of user-analyst relationships. MIS Quarterly 16, 249266.

Orlikowski, W.J., 1991. Integrated information environment or matrix of control? the contradictory implications

of information technology. Accounting, Management and Information Technologies 1 (1), 942.

Orlikowski, W.J., Baroudi, J.J., 1991. Studying information technology in organizations: research approaches and

assumptions. Information Systems Research 2 (1), 128.

Robb, D.J., 1995. Business Process innovation: re-engineering for operations renewal. Operations Management

Review 10 (3), 1215.

Robey, D., Smith, L.A., Vijayasarathy, L.R., 1993. Perceptions of conflict and success in information systemsdevelopment projects. Journal of Management Information Systems 10 (1), 123139.

Sauer, C., 1993. Why Information Systems Fail: A Case Study Approach, Alfred Waller, Henley-on-Thames.



23/23

Seddon, P.B., 1997. A respecification and extension of the DeLone and McLean model of IS success. Information

Systems Research 8 (3), 240253.

Stoddard, D.B., Jarvenpaa, S.L., 1995. Business process redesign: tactics for managing radical change. Journal of

Management Information Systems 12 (1), 81107.

Swanson, E.B., 1988. Information System Implementation: Bridging the Gap between Design and Utilization,Richard D. Irwin, Homewood, IL.

Teng, J.T.C., Jeong, S.R., Grover, V., 1998. Profiling successful reengineering projects. Communications of the

ACM 41 (6), 96102.

Walsham, G., 1993. Interpreting Information Systems in Organizations, Wiley, Chichester.

Walsham, G., 1995a. The emergence of interpretivism in IS research. Information Systems Research 6 (4), 376

394.

Walsham, G., 1995b. Interpretive case studies in IS research: nature and method. European Journal of Informa-

tion Systems 4, 7481.

Willcocks, L., Smith, G., 1995. IT-enabled business process reengineering: organisational and human resource

dimensions. Journal of Strategic Information Systems 4 (3), 279301.

Willmott, H., 1994. Business process re-engineering and human resource management. Personnel Review 23 (3),

3446.

Willmott, H., Wray-Bliss, E., 1996. Process reengineering: information technology and the transformation of

accountability: the remaindering of the human resource?. In: Orlikowski, W., Walsham, G., Jones, M.R.,

DeGross, J.I. (Eds.). Information Technology and Changes in Organizational Work, pp. 6288.


Larsen Case1

Documents

Transcript of Larsen Case1