Academic journal article Journal of Management Information and Decision Sciences

Business Process Reengineering with Grade

Academic journal article Journal of Management Information and Decision Sciences

Business Process Reengineering with Grade

Article excerpt

INTRODUCTION

Huge investments in ERP (Enterprise Resource Planning) have been made recently to replace legacy systems. However, the resulting efficiency of the entire organization often does not increase dramatically because information technology projects are carried out without first reengineering the underlying business processes (Davenport, 1993; Keller & Brenner, 1995).

What is different about the systems development methodology embedded in GRADE (Graphical Re-engineering, Analysis and Design Environment) is that it explicitly begins with the basic reengineering principle advocated by Hammer and Champy (1993) that business processes should be redesigned before information systems are developed. That is, information systems are typically developed to model the existing "as is" way of doing business. In Hammer and Champy's own words (1993), "we are merely paving the cow paths," when we use this approach. Other common methodologies such as De Marco (1978), Yourdon and Constantine (1978), and tools based on structured methodologies (e.g., IEW, IEF, Excelerator), do not explicitly link business process modeling and redesign to subsequent applications development (as does GRADE), at least in any internally consistent way. This does not mean that these methodologies cannot be used to develop "as proposed" systems, but that there is no explicit formal method for articulating, simulating, and linking business process models with subsequent applications development. The purposes of this paper are twofold. First, it proposes a methodology to support the main tasks involved in Business Process Reengineering (BPR). Second, it describes ah way to model Business Processes (both "as is" and "as proposed") using a graphical software tool called GRADE (Graphical Re-engineering, Analysis and Design Environment).

MAIN TASKS OF BPR METHODOLOGY

A model of business processes is required to develop a successful BPR. On the basis of such a model, three tasks of BPR can be performed using GRADE. First, the current business process is modified in order to improve it by means of static analysis. Next, a dynamic analysis is performed to effect further improvements of the business processes. Finally, it coordinates the redesigned business processes with the organizational structure and skill sets of the employees (performers of tasks). These tasks are discussed in more detail in the following sections.

Principles of Static Analysis

The 'static analysis' refers to the analysis of the structure of business processes without recourse to simulation experiments. The goal of static analysis is to improve or optimize the business processes in accordance with several recommendations. A summary of such recommendations follows.

1. Wherever possible, try to perform activities in parallel (concurrently) instead of in a sequential chain of tasks. This reduces the total duration of business processes considerably. According to Hammer and Champy (1993), a 50% reduction in total duration time is a realistic goal in BPR projects.

2. Avoid organizational breaks within one business process. This means that the same person should perform any two sequential tasks if this person is qualified to do both tasks. Furthermore, this tends to minimize both the number of employees in each business process and the number of employees in any one business process and the number of different employees required to perform any particular task.

3. Eliminate the execution of redundant tasks, especially those that do not add value or increase customer satisfaction.

Principles of Dynamic Analysis

Dynamic analysis of business processes consists of performing various simulation experiments in order to optimize the model. In order to obtain credible results the model requires a variety of process metrics, such as the duration of each task, transfer times, the expenses and productivity of each employee (referred to in the tool as "performer" of the task), the underlying logic behind business rules and the frequency of inputs. …

Search by... Author
Show... All Results Primary Sources Peer-reviewed

Oops!

An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.