Business Services Industry

Simulation of Business Re-Engineering Processes: Case Study of a United States Motor Manufacturing Company

International Journal of Management, Dec 2007 by Hauser, Karina, Paper, David

The purpose of the paper is twofold. First, we believe that the current definition of business process reengineering is too restrictive and offer an alternative definition. An actual case study at the Toyota plant in Kentucky in the United States is used as an instance to demonstrate the viability of such a definition. Second, we introduce a methodology rarely used for process reengineering, namely simulation, to identify potential cost savings from process manipulations. We simulate the incoming volume of material, percentage of parts that need to be crossdocked and the overall layout of the crossdocking area to show their effects on the workload of the team members. Crossdocking in this study is the process of sorting the incoming material and transporting it directly to the point of use on the assembly line. We found that simulation offers managers a cost effective means to explore process reengineering alternatives without actually modifying manufacturing plant layouts.

1. Introduction

Business process reengineering (BPR) has been a popular topic for both academic and practitioner discourse over the past decade. Sarker and Lee (2002) define BPR as "... an organization's activities of redesigning and implementing broad cross-functional business processes with the aid of Information Technology (IT) enablers and/or organizational enablers in order to obtain significant performance improvements" (p. 4).

Beginning around 1990, BPR came onto the business scene as the savior of under performing organizations. Early advocates of BPR (Davenport, 1993; Hammer and Champy, 1993; Harrington, 1991) touted it as the next revolution in obtaining breakthrough performance via process improvement and process change. However, BPR, in many cases, has failed to live up to expectations in many organizations (Davenport, 1993; Hammer and Champy, 1993; Kotier, 1995; Bergey et al, 1999). Some of the possible 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 witfi BPR objectives, an inflexible management team, and a lack of long-term commitment (Bergey et al, 1999). BPR failure possibilities were not however derived from theoretical discourse, but radier from practitioner-oriented, anecdotal origins (Sarker and Lee, 2002). As a result, Sarker and Lee suggest a socio-technical theoretical lens for further BPR exploration. The socio-technical orientation being one that, "... gives equal consideration to me technical and social dimensions, and the interactions between the social and the technological" (Sarker and Lee, p. 2).

We agree that the current definition of BPR (Sarker and Lee, 2002) can be useful, but believe it to be restrictive for two reasons. First, several prominent BPR studies (Broadbent et al., 1999; Caron et al., 1994; Hammer and Champy, 1993; Davenport and Stoddard, 1994; Paper and Dickinson, 1997) suggest that the processes being redesigned do not always require enabling from IT or social motives. second, BPR initiatives do not always need to be cross-functional. Thus, we view BPR in a less restrictive sense.

We believe that BPR does not necessarily have to be cross-functional in scope, nor does it always require technical and/or social enablers to be successful. Most critical, and consistent with Paper and Dickson (1997), we believe that BPR should be based on and aligned with sound business objectives. Business objectives are developed based on me performance goals of the organization and the context within which these goals are to be reached. Therefore, BPR should also be context-specific. We thereby offer a less restrictive definition of BPR as context-specific process change that is meaningful to the organization by being based on (and aligned with) sound business objectives. Our definition places no restrictions whatsoever on the scope of the project. By context-specific, we mean mat the change initiative should depend on the required business objectives in a given situation. If me change initiative is not context-specific, we fail to see how it can address the needed change. By meaningful, we mean that the change initiative must meet agreed upon performance requirements to be considered successful. If a meaningful change is needed to a cross-functional process to enhance performance, the scope of BPR should be cross-functional. If a meaningful change is needed within a specific functional area, the scope of BPR should be limited to the processes within mat function. By basing the change initiative on business objectives, we guarantee that the goal of change is based upon needs of the business.

Our characterization of BPR is, for the most part, aligned with the original definition of BPR offered by Hammer and Champy (1993) as "the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service, and speed" (p. 32). We agree that BPR should focus on process. Moreover, by basing BPR on sound business objectives it is, by default, fundamentally sound. We consider meaningful change to be even more important to the organization than Hammer and Champy's dramatic change. A meaningful change is by definition one that is valuable, but a dramatic change doesn't necessarily have to be meaningful. The last component of the definition is radical. Again, meaningful change offers value to the organization while radical change may not. Hammer and Champy viewed radical change as "... throwing away the old" (p. 33). Many BPR critics have questioned this notion of radical change. Their argument is that existing processes that work well need not be discarded. Ramer, each process should be examined for value prior to any action (Paper, 1998; Paper and Dickinson, 1997).

 

BNET TalkbackShare your ideas and expertise on this topic

Please add your comment:

  1. You are currently: a Guest |
  2.  

Basic HTML tags that work in comments are: bold (<b></b>), italic (<i></i>), underline (<u></u>), and hyperlink (<a href></a)

advertisement
advertisement
  • Click Here
  • Click Here
  • Click Here
  • Click Here
advertisement

Content provided in partnership with ProQuest