Breaking the rules: success and failure in groupware-supported business process reengineering

Abstract

In the information economy, businesses are changing more often and more rapidly than ever before. The lessons learned from a decade of business process reengineering (BPR) research may provide insights to researchers and managers trying to understand and successfully navigate these changes. This paper examines the successes and failures of groupware-supported BPR processes in four organizations. Two were successful and two were failures. Groupware allowed certain tasks to be performed faster, added structure to the BPR process and facilitated participation by more people. The key difference between the successful and the unsuccessful cases was when and how senior management was involved.

Introduction

With the rise of e-commerce, enterprise systems, customer relationship management and other technology-enabled new business practices, businesses now face major changes in much shorter time periods. The challenges of the new Internet economy may offer an opportunity to apply the lessons learned from a decade of business process reengineering (BPR) efforts, which likewise sought ways to manage major change [5], [20], [28]. Notwithstanding the hype and the many reported failures, reengineering efforts of the 1990s were often focused on the same areas now linked to e-commerce disasters, such as poor inventory management, fulfillment or shipping processes [28]. These are not technology problems. These are process problems—problems that result from a failure to recognize that process excellence [28] or “process think” [20] is necessary to make e-commerce sites succeed. Here is where BPR knowledge can help.

BPR has been defined as a fundamental redesign of business processes to achieve dramatic improvements in critical areas such as cost, quality, service and speed [22]. In its classic form, BPR had at least three key elements or “rules” [22], [25]. First, the goal was large, dramatic improvements, not incremental or marginal improvements. Second, because the changes were radical, there was an emphasis on “clean-slate” changes, where current processes were ignored or thrown away. Third, the BPR project typically was driven from the top of the organization using small teams of top managers.

BPR has been a high-risk, high-reward proposition. BPR has the potential to significantly improve business performance, but as many as 70% of all BPR projects have failed [25]. Many reasons have been given for BPR failure [3], [7], [23], [25]. Some projects did not follow the clean-slate approach and therefore died off before implementation because of the high cost and lengthy time spent in analysis. Others died in the implementation phase (or shortly thereafter), because the radical, clean-slate approach caused important factors to be overlooked or top management teams neglected to involve the middle managers charged with implementation and therefore they were not committed to the changes.

Several articles suggest that a groupware-based BPR approach may mitigate some of these causes for failure. Groupware may significantly reduce the time and cost of the analysis phases and, by enabling more middle managers to participate in the analysis and design, may ease some of the implementation issues [10], [13], [48].

In this study, we sought to address two questions: Do the classic BPR rules still apply in a groupware-supported BPR environment? And, if not, what is a “best practice” groupware BPR process? In the following sections, we explore the interactions between BPR in its traditional sense and groupware-supported BPR in practice. Then, we describe four case studies using groupware in varying ways to facilitate the BPR effort. We conclude with an analysis of the case outcomes and identify factors in the groupware BPR process we believe led to success and describe a groupware BPR “best practice.”