SETTING THE STAGE

Vicro is a conservative organization in that (it purports that) it doesn't embrace "bleeding edge" technology to obtain a competitive advantage. It has been in existence for many years and depends on a good reputation with its clients and positive "word-of-mouth" to attract and maintain its client base. Hence, Vicro wants to deploy proven technology that will help satisfy and exceed customer requests and expectations. The major technologies utilized include mainframe systems to store centralized production data and serve the core applications of the business and client-server technologies for development and daily operations such as e-mail, file transfer, web access, etc.

Vicro Communications was chosen as a case study because the authors knew that it had experimented with business process reengineering (BPR) to streamline its operations and that information technology (IT) was intended as a key facilitator. Since we were interested in why BPR efforts (facilitated by IT) succeed or fail, and had contacts at Vicro, we initiated this research project. We chose the case study approach to gain a rich understanding of what really happened and why events unfolded as they did.

Business process reengineering (BPR) was used as a literature base to frame the study. The BPR literature reveals that many BPR efforts are unsuccessful. Based on this premise, it seemed a good research undertaking to explore why this is the case.

A synopsis of salient BPR literature is included as a resource for the reader. In the early 1990s, business process reengineering (BPR) came blazing onto the business stage as a savior of under performing organizations. Early advocates of BPR (Davenport, 1993; Hammer & Champy, 1993; Harrington, 1991) touted BPR as the next revolution in obtaining breakthrough performance via process improvement and process change. However, BPR has failed to live up to expectations in many organizations (Davenport, 1993; Hammer & Champy, 1993; Kotter, 1995; Bergey et al., 1999). Some of the reasons include adoption of a flawed BPR strategy, inappropriate use of consultants, a workforce tied to old technologies, failure to invest in training, a legacy system out of control, IT architecture misaligned with BPR objectives, an inflexible management team, and a lack of long-term commitment (Bergey et al., 1999). As one can see from this list, it seems obvious that many organizations failed to realize the scope and resource requirements of BPR.

Patience is another key aspect. BPR initiatives can lose momentum as managers face limited resources, slow pay-off, diminished employee enthusiasm, and increased resistance to change (Harkness et al., 1996). When short-term BPR results are not obtained, management tends to lose interest and top management is less willing to allocate new resources to the project (Paper, 1998a). One solution to this problem is targeting a BPR initiative that is ‘manageable’ and that will garner quick results (Paper, 1998a). Another solution is for top management to be actively involved in the effort (Kettinger et al., 1997).

Assuming that the organization understands the scope of BPR and is patient, the project still may not succeed without careful consideration of the type of process initiative. Paper (1998a) argues that the BPR initiative should be driven by a focus on the customer, strategic business issues or senior management directives. Failure to do so greatly reduces the chances for success.

IT has been touted as one of the key enablers of BPR (Davenport, 1993). However, IT can be one of the biggest obstacles if not properly aligned with business objectives (Broadbent et al., 1999). The heritage of a legacy system can contribute greatly to BPR failure (Bergey et al., 1999). Many legacy systems are not under control because they lack proper documentation, historical measurements, and change control processes (Bergey et al., 1999; Paper, 1998b). Due to the scope and complexities inherent to a typical legacy system infrastructure, it should be treated with the same priority as the cultural and organizational structures when undergoing process change (Broadbent et al., 1999; Clark et al., 1997; Cross et al., 1997).

Although the proliferation of research articles has been abundant, research findings have provided limited explanatory power concerning the underlying reasons behind BPR failure. To address this problem, several recent in-depth case studies have appeared in the IS literature to add explanatory power to this issue (Broadbent et al., 1999; Clark et al., 1997; Cooper, 2000; Cross et al., 1997; Harkness et al., 1996; Paper, 1999). However, much more work of this type needs to be undertaken. Hence, we embarked on a case study to gain insights into the IT-enabled BPR phenomenon.