Business process reengineering with grade.

Lockwood, Diane ; Tenteris, Janis ; Ansari, A. 等

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. Such information often is readily available in some form in many organizations, although it must often be reorganized in order to be put to use in the model.

Coordination of New Business Processes with Organization Structure

This step of BPR can be performed only after the dynamic analysis of the business process is completed. Coordination means that changes in the structure of the organization are needed to reflect changes in the new business process. Preferably this should be done for the system as a whole. If such activities are performed for separate subsystems (departments, branch offices, etc.) there is always a risk that these local changes might not improve the characteristics of the entire system.

GRADE provides a unique function 'Build System Model' (1999) to implement these recommendations. This function extracts the information from multilevel business process diagrams and organization charts and generates Communication Diagrams (CD). The CD's represent communication between different performers. In simple cases a visual inspection of the CD's is enough to make conclusions on how to restructure the organizational optimally. It is easy to determine from the CD's whether the performers that belong to the same organizational unit communicate intensively among themselves. If external communication (with performers from other branches) is more intensive than internal communication, appropriate changes in the structure of the organization (redeployment of performers) should be considered.

CREDIT PROCESSING CASE

Realistically, it is often necessary to redesign several complex cross-functional business processes in a large application development project. However, to illustrate the methodology, the scope of this paper will be limited to two main business processes in the credit department of a commercial bank. The organization unit (credit department) involved and the two business processes are represented in Figures 1 and 2, respectively. The GRADE software tool produced all figures used in this paper.

[FIGURE 1 OMITTED]

In addition to organization structure analysis, business processes are also required to undergo static analysis. The two main business processes, 'Short Term Credit' and 'Other Credit', reflect the current situation (as is) model, shown in Figure 2. The first model depicts the short term credit process for small and medium size credits, for current customers of the bank. The second model demonstrates the approval of other credits (large and/or long term and/or credits for new customers).

[FIGURE 2 OMITTED]

Application of Static Analysis

First Requirement: Perform Activities in Parallel. Although both business processes seem to be quite similar, the parallel execution of tasks can be introduced only in the first process, as show in Figure 2-a. The only input document required to start the task Compare Request and Debts is Registered Request. This task does not require Financial Statement which is produced by the previous task Credit Check. Thus, the first business process can be transformed so that the tasks Compare Request and Debts and Analyze Credit History are executed in parallel with the task Credit Check. The modified version of this business process is depicted in Figure 3.

However, as shown in Figure 2-b, a similar modification for the second business process is not possible. This is due to the fact that the task Register Guaranties and Collateral is initiated by Copies of Documents that are received from the previous task Receive Documents.

Second Requirement: Same Performer for Sequential Tasks. The tasks Compare Request and Debts and Analyze Credit History are performed in sequence by two different performers (Junior Expert and senior Expert in Figure 2a. This causes an extra transfer of work materials from Junior Expert to Senior Expert. It is assumed that the task Analyze Credit History does not require the qualification of a Senior Expert, in which case a Junior Expert can manage it. This, consequently, leads to a change in the structure of the organization. Thus, we could reduce the number of Senior Experts and increase the number of Junior Expert positions. These changes in the organization diagram are reflected in Figure 4.

[FIGURE 3 OMITTED]

[FIGURE 4 OMITTED]

Application of Dynamic Analysis

A number of simulation experiments were carried out with the model obtained after static analysis. During these experiments the number of positions was changed and the duration of the tasks and the utilization of the employees were varied. The number of concurrently active transactions and the lengths of queues were reasonably low and the Credit Division, as a whole, was able to manage the volume of incoming Credit Requests.

The utilization of performers (depending on the number of assigned performers) is represented in comment fields of the organization diagram in Figure 4. The optimal number of positions was determined experimentally (utilization analysis is not discussed herein for reasons of page limitations) but the results are represented graphically by comparing Figure 1 with Figure 4. Some comments on these results are:

1. The utilization of two Loan Officers is not sufficient (less than 40 %) and even when reduced to one, the utilization is not more than 80 % of the total work time;

2. The number of Senior Inspectors was reduced from four to three which gave an average utilization of 81.79%. Even two Senior Inspectors could manage the work load but then their high utilization (99.52%) would likely result in a waiting queue which would cause an increase in the cycle time of the process.

3. The replacement of one Senior Experts with another Junior Expert has proven to be successful from a utilization viewpoint. The two Junior Experts now have a combined load factor of 89%.

4. The utilization of Senior Expert and Expert is still too low (around 52%). In this case the options are to a) combine the two positions into one if the skills are transferable or b) give additional tasks to these experts in order to reduce slack time.

5. The total number of employees in the Credit Division can be reduced from 15 (see Figure 1) to 13 (see Figure 4). The tasks of Senior Expert and Expert would be combined in Figure 4 since the current utilization rate is low (around 50%).

The duration of business transactions after reducing the number of performers is depicted in Table 1. Although the duration of each task was given (see Figures 2, 3 and 4) as a constant value (which is an obvious simplification of reality), the duration of business transactions varied from 50 minutes to as long as 14 hours.

The range of task duration for the second Business Process is relatively small when compared to the duration for the first Business Process. This can be explained on the basis of performer utilization. The average utilization of performers for the second Business Process is around 82% while that for the first Business Process, which has two Inspector positions, is 98%. The execution of the tasks of the Inspectors might often be delayed because they are still busy with the previous transaction.

This situation could be improved by increasing the number of Inspectors to three but this would decrease their utilization to 66 % (see Figure 4). This would also increase the total costs (14 employees versus 13). The positive result of such a change would be a shorter duration and range of the Business Process. This should be done if the customers consider the total processing time of Short Term Credit applications to be rather lengthy and if there is a risk that they might switch to another bank.

New Organization Structure According to the Business Processes

One of the Communication Diagrams (CD) obtained after the modification of the organization chart is represented in Figure 5.

[FIGURE 5 OMITTED]

This example shows that the Guaranty and Collateral Department has an isolated (stand-alone) object--Senior Expert. However, the Senior Expert communicates with other objects (external to this department). This is depicted through external (dashed line) communication paths X--Sen Exprt and Sen Exprt--X where the Senior Expert sends messages to Senior Loan Officer and Senior Inspector of Long Term Credit Department.

These observations could lead us to the first modification step--move Senior Expert to the Long Term Credit Department thus improving the communication within the Long Term Credit Department. In contrast, analysis of additional interface tables (not shown here) for Expert and Junior Expert reveals that they are communicating mostly internally with performers of the Short Term Credit Department, i.e., the Loan Officer and the Inspector. This could be the basis for a major change in the organizations-move the Expert and the Junior Expert to the Short Term Credit Department and eliminate the Guaranty and Collateral Department.

Dynamic experiments with such changes are easy to make in the GRADE tool: one need only move (by drag and drop) both experts to another branch in the organization diagram. Then, with the push of a button, one can regenerate the communications structure of the Credit Division while maintaining referential consistency. Such changes in the organization of Credit Division might also reduce the total duration of each business process because the transfer time of messages between tasks (and their performers) would decrease as a result of the close proximity of each performer to his partners in the Business Process. In order to keep the model simple the transfer times are not represented in this case.

CONCLUSION

Notice in this study that when the organizational changes are completed we have followed a strategy of maintaining a "flat" organization. The main results of these reorganizations can be summarized as follows:

* Instead of three departments we now have just two--one for each business process. Both departments have similar numbers of employees, six to seven, and they both have intensive internal communication;

* The two new departments do not interact with each other. The next transformation possibly could be the elimination of the unit Credit Division in the next superordinate hierarchy level. This change would reduce the number of hierarchy levels, the number of manager positions, and make the entire organization more "flat".

However, our goal was not to build a flat organization. GRADE equally well could help one follow the opposite strategy and create a traditional organization with specialized departments and a multilevel hierarchy.

A tool like GRADE can be helpful in understanding the current situation and in managing the changes to be made. GRADE consists of two primary components-Business Process Modeling and Information Systems Specification and Development. The front-end computer assisted systems engineering component (Business Process Modeling), can be used in undergraduate and graduate level MIS courses in Systems Analysis and Design, as well as in Operations Management courses where the focus is on process and work flow modeling.

The back-end application development component, Information Systems Specification and C-code Generation, can be used in upper division capstone MIS/CIS courses where the focus is project-oriented (i.e., the specification and development of a working prototype application). Ideally, GRADE should be used in a two-course sequence consisting of: (1) Business Process Modeling, and (2) Information Systems Specification & Development. Currently, GRADE is being used in a an MBA Business Process Re-Engineering course to model "as-is" processes, simulate and identify bottlenecks, and model proposed "as-redesigned" processes. A follow-up Computer Information Systems course on Applications Development could use the "as-redesigned" process as a starting point for applications protoptyping. It would capture re-useable entity relationship data models, document detailed process specifications, and automatically generate C-code for applications. All the model elements previously described (data, processes, performers, and user interfaces) are still kept in a central repository in a consistent and integrated manner. This makes any changes easy to accomplish. Used in this way, the emphasis on C-programming, per se, is minimized in favor of learning formal modeling and specification methods.

The BPR methodology and tool described in this paper are only one example of how Business Process Modeling can be systematically approached. Other methodologies and tools exist, but the integrated nature of the GRADE tool and documentation merits further examination and empirical testing of competing products.

REFERENCES

Business Modeling Language GRAPES-BM and Simulation Tutorial. (1999). Infologistik, Holzkirchen, Germany.

Davenport, T. (1993). Process Innovation. Boston: Harvard Business School Press.

De Marco, T. (l978). Structured Analysis and System Specification. NY: Yourdon Press.

Hammer, M. & Champy, J. (1993). Reengineering the Corporation, NY: Harper Collins.

Yourdon, E. and L. Constantine (l978). Structured Design. NY: Yourdon Press.

Keller G., Brenner, W. (1995). Business Reengineering mit Standartsoftware, Frankfurt: Campus Verlag.

ENDNOTES

** The GRADE tool is available for education institutions from Infologistik, 3 Wagnerbreite, Holzkirchen, D-83607, Germany. Phone: +49-8024 30450. Web sites: www.infologistik.com and www.gradetools.com. Contact Mikus Grasmanis for further details on educational versions.

Diane Lockwood, Seattle University

Janis Tenteris, Infologistik Holdings, Inc.

A. Ansari, Seattle University

Table 1: Elapsed Duration of Business Processes (results of
simulation experiments)

Value 1st Business Process 2nd Business Process

Minimum 50 m 2 h 32 m

Average 6 h 41 m 3 h 25 m

Maximum 14 h 24 m 6 h 17 m