Business Process Reengineering
with GRADE

Back to GRADE Modeler 4.0


Huge investments have been made lately for the improvement of legacy information systems. This is done in accordance with the principles of down-sizing, right-sizing, reverse engineering, re-engineering, client - server architecture etc. Although most of these projects end up successfully, the total efficiency of the entire organization did not increase dramatically. This happened because the IT projects were carried out without reengineering of the business processes, including both manual and automated tasks.

So now BPR (business process reengineering) is a critical issue in the strategic development of large organizations.

What is a "business process"' ? According to a widely accepted definition (Hammer & Champy) a business process is "a set of activities that produces a result which is valuable from point of view of the customer or buyer". The main question of BPR is not to improve the process but to conclude weather this process is needed (weather it produces something attractive for the customer).

Widely accepted are also other less revolutionary definitions of what a business process is, e.g. business process is not simply a set of activities, but it also represents the sequence of these activities (process) which produce the expected result; Another remark concerns the receiver of the result. This can be both an external agent (customer or buyer) and also another organization unit within the same system.

  1. Main Tasks of BPR and GRADE

For successful BPR a model of business processes is required. On the basis of such model the following tasks of BPR can be solved:

  1. determine the expected result (which is valuable or critical from the viewpoint of receiver) of the system under consideration (organization, enterprise, etc.);
  2. modify the current business process in order to improve it. Here the information carriers and support of DP system is always critical;
  3. coordinate the new business process with the structure of organization (performers of tasks);

The most advanced tool for solving these tasks is GRADE (Graphical Re-engineering, Analysis and Design Environment) which provides user friendly support for consistent and effective BPR:

The mentioned components of GRADE tool and the GRADE methodology do not replace the system / business analyst. However, GRADE makes the BPR works more productive, provides systematic and consistent approach and eliminates error-prone routine works. The GRADE user will benefit from the following automated features of the tool:

2. Dynamic Analysis of Business Processes

The dynamic analysis of business processes is based on simulation experiments with the model. In order ot insure credible results the model requires a variety of numeric information, such as duration of each task, transfer times, expenses and productivity of each performer, branching conditions of decision tasks, frequency of input signals, etc. Such information often is readily available in technological systems. This explains why GRADE is used more often for reengineering of technological systems (here the numeric attributes of processes are available in the form of precise schedules, job descriptions and statistical summaries).

Good examples of GRADE use for technology are the production line model for circuit board assembly and testing in Ericsson Radio Systems and GRINDEX model for production and packaging of medicine.

Simplified version of the Production line model is included in GRADE BM (business modeling) Tutorial and GRADE BM Simulation Guide.

The second part of this brochure is an example of how similar techniques would be applied for a typical business system - Credit Division of bank.

3. Static Analysis

By 'static analysis' here we mean analysis of the structure of business processes without simulation experiments with the model. The goal of static analysis is to improve (optimize) the business processes according several empirical recommendations.

A summary of such recommendations is as follows:

  1. Wherever possible, try to perform activities in parallel (concurrently) instead of sequential chain of tasks. This reduce the total duration of business process considerably. A 50 % reduction is a quite realistic goal in BPR projects.
  2. Avoid organizational breaks within one business process, i.e. any two sequential tasks should be performed by the same performer unless this does not contradict the qualification and specialization requirements. This also means:
  3. Provide homogeneous information media between tasks (activities):
  4. Provide support by Information System everywhere where this is reasonable;
  5. Eliminate redundant execution of tasks and functions.

These principles are illustrated by example in GRADE BM tutorial, chapter 21. This example concerns the business processes for training and licensing of personnel in a large airline company.

4. Coordination of Business Processes and their Performers

This step of BPR can be performed only after the two former steps are completed, i.e. the results to be produced are discussed and the structure of business process is ready (after static and/ or dynamic analysis of business process model). Besides, this BPR step should be done preferably for the system as a whole. If such activities are done for separate subsystems (departments, branch offices, etc.) then there is always a risk that these local changes might not improve the characteristics of the entire system.

For this step GRADE provides a unique function 'Build system model'. This function extracts the information from multilevel business process diagrams and organization charts and generates Communication Diagrams (CD) and other model views automatically. The CD diagrams represent communication between performers. In simple cases just a visual inspection of the CD diagrams is enough to make conclusions on how to perform optimally restructuring of the ORG diagram. It is easy to notice from CD diagrams weather the performers that belong to the same organization unit communicate intensively among themselves. If external communication (with performers from other branches) is more intensive than the internal one then appropriate changes in the organizations structure (subordination of performers) can be done easily.

In more complex situations the intensity of communications between performers can be analyzed from Interface Tables (generated by GRADE automatically). These tables display information about messages transferred between performers.

5. Example

In general it would be necessary to discuss in details all steps of BPR for a large organization, however, this would take too much space and time for a small brochure.

As an example here we will use a fragment of business model of one Western bank giving credits for known and unknown customers. This example is slightly modified and simplified (see chapter 5.6, Comments on the model) to emphasize use of the basic techniques of BPR with GRADE.

5.1 The current situation ('as is' model)

Instead of the entire bank we will discuss two major business processes only:

The organization units involved in these business processes are represented in Figure 1.

Figure 1 Structure of the performers (ORG diagram)

We believe that this diagram is understandable without detailed explanation. The graphical symbols have the following meaning:

The two main business processes are represented in Figure 2 and Figure 3.

Figure 2 The 1st business process -
short term credits

Figure 3 The 2nd business process -
other credits

The following graphical notation is used within a TCD - business process diagram:

5.2 Statical Analysis of Business Process

The requirements (3) - (5) of the business process (see chapter 3) will be taken into consideration during new system implementation. Therefore we shall concentrate here mostly on requirements (1) and (2).

Requirement (1). Although both business processes seem to be quite similar, parallel execution of tasks can be introduced in the 1st process only (Figure 2). In order to start the task Compare Request and Debts only the input document Registered Request is required. This task does not require Financial Statement which is produced by the previous task Credit Check. Thus the 1st 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 new version of this business process with parallel branches is depicted in Figure 5.

Similar modification is not possible for the 2nd business process, because the task Register Guaranties and Collateral is initiated by Copies of Documents that are received from the previous task Receive Documents.

Requirement (2). The tasks Compare Request and Debts and Analyze Credit History are performed in sequence by 2 different performers which causes an extra transfer of work materials from Junior Expert to Senior Expert. Let us assume that the task Analyze Credit History does not require the qualification of a Senior Expert and a Junior Expert can manage this. This consequently leads to a change in the organization structure. Thus we could try to reduce number of Senior Experts by 1 and accordingly increase the number of positions of Junior Expert.

These changes in ORG diagram are reflected in Figure 4.

Figure 4 ORG diagram after static analysis

Figure 5 1st business process with parallel tasks after static analysis and modification

5.3 Dynamic Analysis

A number of simulation experiments were carried out with the model obtained after static analysis. During these experiments the number of positions (see Figure 6) was changed and the duration of tasks and utilization of performers was explored.

Firstly, it was provided that after warm up period (see GRAPES-BM V.3.0. Simulation Tutorial) a stable functioning of the system was maintained. In this mode the number of concurrently active transactions and the lengths of queues was reasonably low and the Credit Division as a whole managed with the incoming Credit Requests.

The utilization of performers (depending on the number of assigned performers) is represented in comment fields of ORG chart in Figure 6. The optimal number of positions was detected experimentally and is represented in this diagram graphically.

Figure 6 Number of performers and their utilization

Some comments on these results:

The duration of the business transactions according this reduced number of performers is depicted in Table 1. Although the duration of each task was given (see Figures 2, 3 and 5) as a constant value (which is an obvious simplification of the reality), the duration of business transactions varies in a relatively large interval. This happens because:

Table 1

Duration of business processes
(results of simulation experiments)

1st business process
2nd business process
50 m
2 h 32 m
6 h 41 m
3h 25 m
14 h 24 m
6h 17 m

The dispersion of duration for the 2nd business process is relatively small, but the duration of the 1st business process is dispersed considerably. This can be explained on the basis of performer utilization. The average utilization of performers for the 2nd business process is around 82 % but the 1st business process uses 2 positions of Inspector with the average utilization of 98 %. The execution of their tasks might often be delayed because these Inspectors are still busy with the previous instance of the corresponding task.

This situation could be improved by increasing the number of Inspectors to 3, however, this would decrease their utilization down to 66 % (see Figure 6) and also would increase the total costs (14 employees versus 13). The positive result of such change would be smaller duration of the business process and its dispersion. This should be done if the customers consider the total processing time of short term credit applications as rather long and there is a risk that they might switch to another bank.

5.4 Modification of the Organization Structure

The modifications of the organizations structure with a GRADE model can be done easy and effectively. For this purpose the function Build System Model is developed. This functions generates the Communication Diagrams (CD) automatically from the business process diagram and organization chart. The CD diagrams represent communication paths between performers of the tasks.

In simple cases just a visual inspection of CD diagrams is enough to see if the performers of one organization unit communicate among themselves. This information can be utilized to change the clustering and subordination of performers.

In more complex situations the contents of Interface Tables (IT) should be analyzed. These tables represent transfer of messages between performers and also are generated and filled out automatically. Each IT represents the contents of one communication path between two performers (see example in Figure 11 and Figure 12).

The CD diagrams obtained after the modification of ORG chart are represented in Figures 7-10.

Figure 7 CD diagram of Credit Division after dynamic analysis

Figure 8 CD diagram of Guaranty and Collateral Department after dynamic analysis

Figure 9 CD diagram of Long Term Credit Department after dynamic analysis

Figure 10 CD diagram of Short Term Credit Department after dynamic analysis

These Diagrams show, that the objects of Long Term Credit Department (Senior Loan Officer and Senior Inspector) do not communicate among themselves (at least - not within these 2 business processes). The Guaranty and Collateral Department also has an isolated (stand alone) object - Senior Expert. However, the Senior Expert communicates with other objects (external for this department). This is depicted through external (dashed line) communication paths X - Sen Exprt and Sen Exprt - X. The corresponding Interface Tables (see Figure 11 and Figure 12) show that Senior Expert communicates (sends and receives messages) with Senior Inspector and Senior Loan Officer. They both belong to Long Term Credit Department.

Figure 11 Interface Table Sen. Expert - X

Figure 12 Interface Table X - Sen. Expert

These observations could encourage us for the first modification step - to move Senior Expert to the Long Term Credit Department (see Figures 13-15).

Figure 13 Organization structure fragment after move of Senior Expert

Figure 14 CD diagram of Guaranty and Collateral Department after move of Senior Expert

Figure 15 CD diagram of Long Term Credit Department after move of Senior Expert

Now, the Communication within the Long Term Credit Department seems to be improved, however, analysis of interface tables for Expert and Junior Expert (see Figure 14) reveals that they are communicating mostly with performers of the Short Term Credit Department, i.e. Loan Officer and Inspector. This could be the basis for a major change in the organizations:

Such changes are very easy to make in GRADE model: we only need to move (by drag and drop) both experts to another branch in the ORG diagram (see Figure 16) and after that with a push of a button we can regenerate the communications structure of Credit Division anew. The regenerated communication structures are depicted in Figure 17 - 19.

Figure 16 Organization structure with two departments

Figure 17 CD diagram of Credit Division with two departments

Figure 18 CD diagram of Short Term Credit Department after reorganization

Figure 19 CD diagram of Long Term Credit Department after reorganization

Such change 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 more compact location of performers of each business process. In order to keep the model simple the transfer times are not represented in this case.

5.5 Conclusions

Now when the organizational changes are already completed we can easily notice that in this study we have followed the strategy of "flat structures". The same strategy was used also for the changes during the static and dynamic analysis.

The main results of these reorganizations can be summarized as follows:

However, our goal was not to insist in building "flat" structures. GRADE equally well could also help one to follow the opposite strategy and create a traditional organization with specialized departments and multilevel hierarchy. In this case the best version would be the one represented in Figures 6-10, where the performers are grouped upon their functions and skills although they possibly do not participate in the same business process and consequently do not communicate among themselves.

Finally - we have to remember that in practice there is always a trade off between both strategies. The finding and implementing of this trade off version is rather "art" than "science" because the human factors also should not be forgotten. Anyway a tool like GRADE will be very helpful to understand exhaustively the current situation and to manage the changes to be done, as well as to represent in graphical easy-to-read form all these business modeling aspects.

5.6 Comments on the model

The business process model used in this brochure is simplified and modified to emphasize the basic principles of static and dynamic analysis of process and organization structure. The following intentional simplifications should be mentioned:

These changes and simplifications were introduced also to convert this model into a generic example, so that it is practically impossible to recognize the bank used for this case study.

6. References

1. Hammer, M., Champy, J. Reengineering the Corporation, Harper Collins, New York, 1993.

2. Ganesh D. Bhatt. 1996. "Enterprise Information Systems Integration and Business Process Improvement Initiative: an Empirical Study". Http://… r/acis/papers/bhatt.htm.

3. Davenport T. Process Innovation, Harvard Business School Press, Boston, 1993.

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

5. Business Modeling Language GRAPES-BM V.3.0. Language Guide. 1996. Infologistik GmbH, 23 Budapester st., Munich, 114 p.

6. GRAPES-BM V.3.0. Simulation Tutorial. 1996. Infologistik GmbH, 23 Budapester st., Munich, 104 p.