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:

• for the representation of business process model, including sequence of tasks, branching conditions and performers of tasks, graphical editor of TCD (Task Communication Diagram) and other diagrams are used;
• the organization chart and required skills of performers can be described in ORG (Organizational chart) diagram and CMP (Competence) table;
• the data used and stored within the system is represented as ER (Entity Relationship) and DD (Data definition) diagrams;
• the dynamics of the business processes can be simulated, animated and analyzed via BM (business model) Simulator, Animator and Trace Browser.

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:

• GRADE supports easy to read graphical representation of alternative versions of business processes and organization chart in the form of TCD and ORG diagrams. They can be built in a consistent manner and displayed via several automatic layout algorithms (vertical or horizontal automatic layouts of model according task sequence, according performers of tasks, etc.);
• The statical analysis of business processes can be performed according empirical guidelines and recommendations;
• The simulation of the dynamic model aspects can be done repeatedly after modifying the internal (duration of task, number of performers) and external (number and intensity of incoming signals) parameters of the model;

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:
   • try to minimize the number of different performers involved into one business process;
   • try to minimize transfers from one performer to another within one business process;
3. Provide homogeneous information media between tasks (activities):
   • avoid different information carrier types (network, diskettes, courier, mail, etc.) within one business process;
   • elude repeated request and entering of the same information
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:

• Short term small and medium size credits for known customers of the bank;
• Approval of other credits (large and/or long term and/or credits for new customers);

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:

• rectangular boxes represent organizational units of the organization;
• rounded boxes represent positions;
• dashed line symbols represent external objects (e.g. Customer, which does not belong to the Bank, however, communicates with bank within these business processes;
• number in the top right corner of the symbol represents number of available performers (or number of positions);

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:

• Line with an arrow from clock symbol represents time events (moments) while the other arrows represent the events of sending and receiving messages or documents.
• Each task symbol (rounded box) has two sections:
  • Above the horizontal line the name of task, comment (if any) and triggering conditions are displayed; The triggering condition is used for tasks with several inputs and might be constructed as a logical expression;
  • Below the line the name of performer (reference to elements of ORG diagram) and duration of task is shown. Instead of a single performer, a more comprehensive description may be used, e.g. Senior Inspector & any with competence = business plan analysis;

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 utilization of 2 Loan Officers is not sufficient (less than 40 %) and even in a case of 1 position the utilization is not more than 80 % of the total work time;
• The replacement of Senior Expert by Junior Expert has proven to be reasonable also from utilization viewpoint. Now 2 Junior Experts are loaded for 89%.
• The number of senior Inspectors was reduced from 4 to 3 with the average utilization of 81.79 %. Even 2 Senior Inspectors could manage with the work load but then their high utilization (99.52 %) would most likely cause an increase of the business process duration and the queues.
• The utilization of Senior Expert and Expert is still too low.
• The total number of employees in the Credit Division can be reduced from 15 (see Figure 1) to 14 (see Figure 6).

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:

• the Credit Division employees are rather busy and there is a considerable waiting time of tasks for available performers;
• the statistical summaries include also the warm up period of the simulation process. Although GRADE BM Simulator provides a possibility to exclude the influence of warm up period, it still exists in the real life (e.g. in the beginning of every week or every weekday the workload in first few minutes is always different from the rest of the working time).

Table 1

Value	1st business process	2nd business process
Minimum	50 m	2 h 32 m
Average	6 h 41 m	3h 25 m
Maximum	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:

• move Expert and Junior Expert to Short Term Credit Department;
• eliminate Guaranty and Collateral Department.

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:

• Instead of 3 departments we now have just two - one for each business process. Both departments have similar number of employees (6-7) and they both have intensive internal communication;
• Both new departments do not interact between themselves, so the next transformation possibly could be the elimination of the organization unit of Credit Division in the next superordinate hierarchy level. As a result the short and long term credit departments could be attached directly under the parent of Credit Division (if only the manager of this level does not already have more than 7-9 subordinate departments). This change would reduce the number of hierarchy levels and make the entire organization more "flat". As a result the number of manager positions also could be reduced because we would not need any more to manage the non-existent Credit Division.

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:

• the business process models do not represent the payment of interest and payments to return the credit;
• Some of the tasks in the business process have decisions with branching into multiple output flows; They are replaced by simple transformation tasks with most probable output;
• the names of positions (performers) are changed so that each department has unique names of positions which are different from the positions in other departments. This is done in order to simplify this description of processes in this study. In the original model qualified (compound) names of positions were used;
• The duration of tasks is reduced proportionally for all tasks. This allowed us to ignore the availability (office hours) of bank employees and perform the simulation as if the entire business transactions starts and finishes within one day. In the real example the availability of performers was used accordingly.

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://hsb.baylor.edu/r… 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.