The State of Business Process Reengineering: A Search for Success Factors

Total Quality Management
Vol. 16, No. 1, 121–133, January 2005

DAVID PAPER & RUEY-DANG CHANG
BISE Department, Utah State University, Logan, USA, Department of Business Management,
National Sun Yat-Sen University, Taiwan, Republic of China


In the early 1990s, business process reengineering (BPR) came blazing onto the business scene as the saviour of under-performing organizations. Early advocates of BPR (e.g.Harrington, 1991; Davenport, 1993; Hammer & Champy, 1993) touted it 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.

Clark et al. (1997) offered a five-component star model featuring people skills, structure, reward systems, processes, and change-ready IT capabilities. The components ‘structure’ and ‘reward systems’ fall into the ‘environment’ category developed by Paper (1998a). The component ‘strategy’ falls into the ‘vision’ category developed by Paper (2001). Paper (1999) extended the model to include IT capabilities. Paper et al. (2001) further extended the model to include vision that weaves the other components together with a ‘top-down’ imperative. Since the component ‘process’ is what organizations are attempting to change to improve performance (Broadbent et al., 1999; Davenport & Stoddard, 1994; Harkness et al., 1996; Kettinger et al., 1997; Nissen, 1998; Paper, 1999), we felt that it should not be a part of our theoretical lens.

Methodology Success Factors
Methodology provides a guiding blueprint for successful transformation. Methodology
success factors include appropriate guiding principles, buy-in, direction, continuous monitoring, graphical process map, and customer support. Transformation cannot be accomplished in the absence of fundamental guiding principles(Hammer & Champy, 1993; Tapscott & Caston, 1993). Existence of such principles allows people to challenge existing assumptions, recognize resistance to change, and establish
project buy-in (Kettinger et al., 1997). Also of critical importance is direction from top management (Paper&Dickinson, 1997),which is essential to identifying information-technology
opportunities, informing stakeholders, setting performance goals, and identifying BPR
opportunities. Direction can be formalized in the form of a process model (Harrington,1991; Davenport, 1993; Paper & Dickinson, 1997). A process model provides a graphical representation of the targeted processes and a starting point for measurement-driven inference(Nissen, 1998). We now articulate methodology success factors:

A customized BPR methodology (process map) facilitates business and contingency
planning for process transformation (Kettinger et al., 1997). It also provides a ‘stepby-step’ map of activities and resource-allocation requirements (Paper & Dickinson, 1997). Hence, a detailed methodology for addressing change must be devised and customized by management prior to undergoing change.
A process map, however, only maps tasks and activity requirements. It fails to provide high-level support and direction. Management is thereby responsible for budgeting along mapped activities, directing (redirecting) process workers, and exhibiting visible support. A map is just a blueprint. Management must lead change.
The process map must be based on sound business principles and be appropriate for each business. That is, it should be customized. As such, an organization’s map
should incorporate business-specific principles and undergo continuous refinement
based on current and ongoing business needs.
A BPR methodology is not a ‘turn-key’ program and should not be purchased as such. Each organization has its own special needs, environment, and business culture.
The process map should be represented as a graphical blueprint that depicts what needs to take place at each phase of a project so that everyone involved understands his or her role in the transformation (Paper, 1999). A graphical map makes it much easier for everyone to ‘see’ the phases and conditions necessary for success.
The customer should be the focus of any change event. Hence, the process map should reflect this focus. That is, customer demand should ‘pull’ the change plan.


The BPR methodology (process map) acts as a rallying point to keep people engaged
and to help management continuously monitor the transformation as it unfolds. Buy-in
of course is critical as management at all levels and people involved in change along
the process path need to understand and believe in its potential for success. Top management and project leaders must offer direction, as it is very easy for transformation projects to glide off track. Finally, customer support must be part of the change plan as they are the reason for transformation in the first place. An organization would not need to change if customers were already delighted. Given the cross-functional and radical nature of process redesign, a lot is learned by process workers (Paper & Dickinson, 1997). Further, new knowledge is created by those involved (El Sawy & Bowles, 1997). However, the organization can lose this valuable
knowledge through attrition if an effort is not made to capture the knowledge on an
organizational basis. As a result, the BPR methodology must move to a higher order of
analysis to formalize the way in which the ‘process’ learns during the redesign process. Thus, interactions between people, management, and the environment are necessary to enact a process map.









Giannis Giataganas
IT related