Larsen Case1

Journal of Strategic Information Systems 8 (1999) 395–417 www.elsevier.com/locate/jsis

When success turns into failure: a package-driven business process re-engineering project in the financial services industry M.A. Larsen a, M.D. Myers b ,* a

KPMG, 8 Salisbury Square, London, EC4Y 8BB, UK Department of Management Science and Information Systems, University of Auckland, Private Bag 92019, Auckland, New Zealand

b

Accepted 6 March 2000

Abstract

This article discusses a Business Process Re-engineering Re-engineering project that involved the implementation of an enterprise resource planning software package. Although the project was deemed to be a success success when the system system was first delivered, delivered, this initial initial success 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 “success “successful ful implementation implementation”” can, within a relatively relatively short space space of time, turn into failure. 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-engineering (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; * 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). 0963-8687/99/$ - see front matter  1999 Elsevier Science B.V. All rights reserved. PII: S0963-8687(00)00025-1

396

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

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 packagedriven re-engineering, the idea is to redesign the business processes before implementing an 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 implementation of information systems more generally. The primary contribution contribution of this paper is to suggest that “success” is a moving 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-term financial 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 packagedriven 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 industry. One of the purposes of the research was to understand the development and implementation of a BPR project over time. The paper proceeds as follows: the following section discusses BPR, focusing specifically 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


397

simply using Hammer and Champy’s 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 as cost, 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; Davenport and Beers, 1995; Stoddard and Jarvenpaa, 1995; Teng et al., 1998). BPR is not without its critics. BPR has been criticised for increas ing 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 of research 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 established 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 communication regarding the re-engineering process (Evans, 1994). Grover et al. (1995) identified a large number of problem or “failure” factors associated

398


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 management; 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 phenomenon, 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 success assumes that each factor is an independent variable and overlooks the interaction betwee n 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 development 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 implementation had a greater influence than previously identified narrowly focused factors. The two concepts of success and failure warrant further discussion. In the BPR literature, 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 considerable disagreement concerning how these concepts should be defined (Lucas, 1975; DeLone and McLean, 1992; Sauer, 1993; Myers, 1995; Seddon, 1997). Following


399

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 researc h, therefore, was participants’ evaluations of the success or failure of the project and the way in which their assessment 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 appropriate research 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 context of the information system, and the process whereby the information system influences and is influenced by the context” (Walsham, 1993). The main value of the interpretive case study lies in its depth: 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 does not 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, consult ants 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 newspapers 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, and explored the multiple interpretations of various participants over time. The primary criterion we used for assessing the validity of our interpretations was the hermeneutic one of

400


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 from them (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 separate regional subsidiary financial service companies, all offering the same core financial services. Each of the nine regional companies had their own regional head office which served 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 PQI—short 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 senior management 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 s enior 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


401

Fig. 1. The PQI initiative.

its “Service 2000” quality process with the launch of a PQI programme. PQI is designed to bring together the Group’s 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 everything that was done in the organisation…It was really saying that in the competitive environment…(that we found ourselves in) we couldn’t 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 functions 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 in turn 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 accounting processes. Five people from Alpha were appointed to the project team, including senior accounting people from both the head and regional offices.

402


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

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 don’t you? They wanted a 30 K deal to redesign the accounting process…By the time we’d finished, we had explained to them we were going to try to find out what accountants did, and do it properly. You can’t 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 piecemeal approach, 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


403

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 recommenda tions that they believed were 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 mos t 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, Gamma Consulting agreed to continue with the project. A benchmarking study against Alpha’s 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 Zealand—this contrasted with one competitor where 80% of its employees were accredited. 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 benchmarking 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 by the “BPR guru” from Gamma Consulting. The project team agreed on the following recommendations: (1) re-engineer the recording and reporting process—put responsibility

404


Fig. 3. The proposed organisational structure.

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 information—develop 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 specialised expertise. The team would have responsibility for accounts payable, accounts receivable 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.


405

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 implementation-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 firm’s 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 managem ent. 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 January 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 technology 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 management 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 implementation 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 Request for 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

406


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

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 Omega’s implementation methodology) is summarised in Fig. 4 above. The second sub-phase of Omega’s methodology for the selection and implementati on of integrated packages now began (i.e. implementation). In March the project team attended a three-week in-depth training course in Sydney, Australia, while the hardware and software 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. 5. The SAP implementation process.


407

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 31 January 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 Omega’s 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 Consulting 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 uncompleted task of the project, and some new report development was also suggested (the identification 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 reporting 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 difficulties. One Regional Financial Adviser (RFA) commented “There was a lack of leadership and buy-in from Group Accounting—it 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 resources were diverted to develop these reports for the new owners. A post implementation review was conducted in early April. Th is involved interviewing

408


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 adequa tely supported 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 redundancies 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 sys tem. 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 recentralised 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 ow n approach to business process improvement early on (called PQI), the consultants from Gamma Consulting managed to convince the Alpha project team that the company’s previous approach was “piecemeal.” The consultants suggested that Alpha should use Gamma’s 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 “professional” approach to BPR was better than Alpha’s own in-house efforts, although it may well be the case that the use of Gamma’s 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 international software consulting firm placed on the use of its standard information systems development methodology by its clients.


409

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 international consulting 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 processes before 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 then implemented by 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 information system. 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 information 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 dramatically impaired. It appears that the problems which emerged (such as the lack of management reporting with the new system, the low skill levels of staff) were a logical consequence of the BPR project itself.

410


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 reengineered Alpha company was taken over by Beta Ltd., the latter company had an excellent 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 stakeholders 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 resounding success. He said: It was a phenomenal integration…It was a piece of good professional work, that went far beyond what I think they had expected of it. And the opportunities it gave them— I’m proud of it. I think we did a good job…We 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 joined…The 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 didn’t work out like they were supposed to was something that I didn’t really have control over—the staff appointments in Group Accounting, the people…We identified key people within the organisation to train…and we had specific people down for training, and some of them just wouldn’t turn up for it. Another person on the project team was the Group Accounting System Accountant. He believed 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


411

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 the project 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 commentary…But 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 had caused considerable dissatisfaction. The Manager of Retail Services said that the project was succes sful 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 they’re 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 the people 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

412


disappeared (either through redundancy or people obtaining work elsewhere). When the company announced in 1994 that all accounting positions at Alpha would become “disestablished” 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 felt insecure 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 Alpha’s. 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 factor research 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 implementing the package rather than continuing operation. This case draws attention to the dangers of concentrating too hard on factors leading to “successful” package implementation 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 headcount—and the corresponding loss of knowledge—actually 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 fact—“success” depends upon who you talk 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


413

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, cultur e 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 operations— the 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 correct— that the whole point of the BPR project was to prepare Alpha NZ Ltd. for sale—then 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 Beta’s decision may have been influenced by an overriding requirement to achieve integration between the two organisations, 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, immediately 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 implementation 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 were dissatisfied with the lack of management reporting. Since the RFAs did not have the necessary information to think “strategically and proactively” as was originally envisaged,

414


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 an ERP 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 implementation, 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 practitioners 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, shortterm 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 hope that further research will shed more light on the long-term implications of BPR and on its implementation and evaluation.

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

415

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 the KPMG Auckland office and the University of Auckland Business School for some financial 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 manuscript is a substantially revised version of a paper which was presented at the Eighteenth International Conference on Information Systems in Atlanta, Georgia, from 15– 17 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, 95–113. 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, 28–29. Benjamin, R.I., Levinson, E., 1993. A framework for managing IT-enabled change. Sloan Management Review 34 (4), 23–33. 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. 193–201. Bussen, W., Myers, M.D., 1997. Executive information systems failure: a New Zealand case study. Journal of Information Technology 12 (2), 145–153. 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), 233–250. Carr, D.K., Johansson, H.J., 1995. Best Practices in Reengineering: What Works and What Doesn’t 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), 22–34. Davenport, T.H., Beers, M.C., 1995. Managing information about processes. Journal of Management Information Systems 12 (1), 57–80. Davenport, T.H., Short, T.E., 1990. The New Industrial Reengineering: Information Technology and Business Process Redesign. Sloan Management Review Summer, 11–27. DeLone, W.H., McLean, E.R., 1992. Information systems success: the quest for the dependent variable. Information Systems Research 3 (1), 60–95. Evans, R., 1994. The human side of business process re-engineering. Management Development Review 7 (6), 10–12. 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, 17–30. 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. 169–186. Ginzberg, M.J., 1981. Key recurrent issues in the MIS implementation process. MIS Quarterly 5, 47–59. 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. 1–6. Grey, C., Mitev, N., 1995. Re-engineering organisations: a critical appraisal. Personnel Review 24 (1), 6–18. Grint, K., Case, P., Willcocks, L., 1996. Business process re-engineering reappraised: the politics and technology

416


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. 39–61. 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), 109–144. Hall, G., Rosenthal, J., Wade, J., 1993. How to make reengineering really work. Harvard Business Review 71 (6), 119–131. 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 Technology and Changes in Organizational Work, Chapman and Hall, London, pp. 89–106. Hammer, M., 1990. Reengineering work: don’t automate, obliterate. Harvard Business Review July–August, 104–112. 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), 580–603. Jones, M.R., 1994. Don’t emancipate, exaggerate: rhetoric, reality and reengineering. In: Baskerville, R., Smithson, S., Ngwenyama, O., Degross, J.I. (Eds.). Transforming Organizations with Information Technology, North-Holland, Amsterdam, pp. 357–394. 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. 45–68. Kettinger, W.J., Teng, J.T.C., Guha, S., 1997. Business process change: a study of methodologies, techniques, and tools. MIS Quarterly 21 (1), 55–80. 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), 67–93. 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. 227–251. 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, 27–30. 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. 308–320. 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), 185–201. Myers, M.D., 1995. Dialectical hermeneutics: a theoretical framework for the implementation of information systems. Information Systems Journal 5 (1), 51–70. Myers, M.D., 1997. Qualitative research in information systems. MIS Quarterly 21 (2), 241–242. Nandhakumar, J., 1996. Design for Success?: critical success factors in executive information systems development. European Journal of Information Systems 5, 62–72. Newman, M., Robey, D., 1992. A social process model of user-analyst relationships. MIS Quarterly 16, 249–266. Orlikowski, W.J., 1991. Integrated information environment or matrix of control? the contradictory implications of information technology. Accounting, Management and Information Technologies 1 (1), 9–42. Orlikowski, W.J., Baroudi, J.J., 1991. Studying information technology in organizations: research approaches and assumptions. Information Systems Research 2 (1), 1–28. Robb, D.J., 1995. Business Process innovation: re-engineering for operations renewal. Operations Management Review 10 (3), 12–15. Robey, D., Smith, L.A., Vijayasarathy, L.R., 1993. Perceptions of conflict and success in information systems development projects. Journal of Management Information Systems 10 (1), 123–139. Sauer, C., 1993. Why Information Systems Fail: A Case Study Approach, Alfred Waller, Henley-on-Thames.


417

Seddon, P.B., 1997. A respecification and extension of the DeLone and McLean model of IS success. Information Systems Research 8 (3), 240–253. Stoddard, D.B., Jarvenpaa, S.L., 1995. Business process redesign: tactic s for managing radical change. Journal of Management Information Systems 12 (1), 81–107. 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), 96–102. 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 Information Systems 4, 74 –81. Willcocks, L., Smith, G., 1995. IT-enabled business process reengineering: organisational and human resource dimensions. Journal of Strategic Information Systems 4 (3), 279–301. Willmott, H., 1994. Business process re-engineering and human resource management. Personnel Review 23 (3), 34–46. 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. 62–88.

Larsen Case1

Recommend Documents