Back to GRADE Modeler 4.0Introduction
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.
For successful BPR a model of business processes is required. On the basis of such model the following tasks of BPR can be solved:
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:
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.
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 -
Figure 3 The
2nd business process -
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:
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
Figure 10 CD diagram of Short Term Credit Department after
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
Figure 19 CD diagram of Long Term Credit Department
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.
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.
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.