3 - BPR Tools

Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP
Change Management BPR ISO9000 Business Process Improvement

Workflow Implementation TOOLSERP FOR
EFQM Financial Modelling TQM System Integration
Business
Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning
Business Process Improvement ISO9000 Change Management BPR
Process
SAP EFQM Financial Modelling TQM System Integration Workflow Implementation
Re-engineering
Workflow Implementation ERP EFQM Financial Modelling TQM System Integration
Strategy Planning Activity Based Costing (ABC) Business Contingency
Orthodox Planning SAP
technique
Change Management
Co-ordination
and control
BPR ISO9000 Business Process Improvement
Financial Modelling TQM System Integration Workflow Implementation
SAP EFQM Alignment
and stance
Tools for Business Process Re-engineering
Contents
1.0 Introduction 1
2.0 Process Modelling 2

2.1 What Makes a Good Process Model? 2
2.2 Selection Criteria for Process Modelling Tools 3
2.3 Process Capture 5
2.3.1 IDEF Diagrams 5
2.3.2 Flow Charts 7
2.3.3 Action Workflow Diagrams 7
2.3.4 Role Activity Diagrams (RAD) 8
2.3.5 Business Process Dynamics Diagrams 9
2.4 Process Measures 10
2.5 Process Analysis and Redesign 11
2.5.1 Peer Group Review 11
2.5.2 Static Analysis 12
2.5.3 Dynamic Analysis 12
2.5.4 Rule Based Modelling 12
2.5.5 Comparing Analysis Mechanisms 13
2.6 Limitations of Information Engineering Tools 13
3.0 Computer-Based Re-engineering Tools 14

3.1 Six Categories of BPR Tools 14
3.2 Computer-Aided Software Engineering (CASE) Tools 15
3.3 Capabilities of CASE Systems 15
4.0 Conclusions 17
Figures
Figure 1: Open Loop View of the World 4

Figure 2: Closed Loop View of the World 4
Figure 3: Basic Building Block of an IDEF0 Model 6
Figure 4: Decomposition of an IDEF0 Model 6
Figure 5: A Typical Flow Chart 7
Figure 6: The Action Workflow Loop 8
Figure 7: A RAD Showing Part of an Insurance Process 9
Figure 8: A Business Process Dynamics Diagram 10
Figure 9: Upper and Lower CASE Tools 16
Figure 10: The Key Components of a CASE Tool 17
Appendices
APPENDIX "A" Techniques to Foster Creativity 19
Copyright© CASEwise 1999

Tools for
Business Process Re-engineering
R.F. Pearman
1.0 Introduction
The essential component for a Business Process Re-engineering initiative is a team of people
with enquiring and creative minds who collectively represent the enterprise under
examination. Experience suggests that technology represents just one facet of the re-
engineering effort and will not, in itself, bring about sustainable improvements.
Nevertheless, the use of technology is relevant in two areas of any BPR initiative. The first
is the use of computer systems to automate and assist in the support and management of
the re-engineered business. A discussion of the role of IT as an enabler of the re-engineered
business is found in the first of this series of white papers "The Theory of Business Process
Re-engineering". Secondly, technology can assist the re-engineering effort to help in
analysis, redesign and communication of business processes. This forms the basis of our
discussion in this white paper.
This white paper opens with a discussion on process modelling techniques. Firstly we
examine the ways in which process models can aid the re-engineering team in the BPR
initiative. Then we present the view that a good process model contains four perspectives:
functional, behavioural, organisational and informational.
Criteria relating to how to select a process modelling tool is presented, listing seven
measures that should be considered by the analysts and managers who have to understand
how changes to processes will actually improve organisational performance. This is
followed by a brief review of some process modelling techniques including: Business
Process Dynamics, IDEF, Flow Charts, Action Workflow Diagrams and Role Activity
Diagrams. The section continues with a review of frequently used process analysis and
redesign techniques. Finally, the section ends with a discussion into why some classic
Information Engineering techniques are inadequate for BPR.
The second section within this white paper covers computer-based re-engineering tools.
Firstly, we examine a range of different types of tools that may need to be used in the re-
engineering effort. The final aspect of this white paper considers CASE (Computer-Aided
Software Engineering) tools, and their value within the re-engineering effort.

1
2.0 Process Modelling
Business Process Engineers are interested in the way people work together to achieve
business objectives, generally with a view to making them more effective and more
efficient. Process models can help them in several ways:
• A good modelling technique, with sound syntax and semantics, and accompanied by a
disciplined process for undertaking business modelling, will help us ask the right
questions about the real-world and tease out the important points for discussion and
agreement.
• Communicating a process to others. People not involved in developing the model may
review it or use it as a basis for approving a new or changed process. A model of an
approved process may serve as a guide to those who have to carry it out.
• Analysis of the model can reveal weak points in the process, for example actions that
add little value or are potential bottlenecks. With the benefit of simulation tools, the
model may then be used to explore the effects of changes.
• As a baseline for continuing process improvement. Suggestions for change can be

expressed as changes to the model. For those interested in collecting metrics, a model
is not only necessary for a clear understanding of what the metrics mean, but the
model itself may suggest useful areas of the business to measure.
• As a program for controlling the real-world process. A sufficiently formal model may
be used to drive an enaction system, such as a Workflow Management System. This
executes the process within a computer system and can ensure that the process is
carried out faithfully every time it is used, that deadlines are met, and that accurate
metrics and audit trails are maintained automatically.
• Last but not least, for designing a new business process.
2.1 What Makes a Good Process Model?
Models are a means of showing the essentials of complex problems. They allow us to
abstract from the real world, highlighting those objects and relationships that are of interest
and ignoring those that are not. The relevant abstractions for assisting business process
1
Curtis, W., Kellner, M.I., Over, engineers were classified by Curtis et al. (1992)1 into four perspectives:
J., (1992), "Process Modelling",
Communications of the ACM,
• Functional, representing what activities are being performed and what data flows
Vol. 3 No9.
connect them.
• Behavioural, representing when activities are performed, with sequencing, feedback

loops, iteration, decision making, triggering conditions, etc.
• Organisational, representing where and by whom activities are performed.
• Informational, information produced or manipulated by a process.

2
The key perspectives for the Business Process Engineer are behavioural and organisational.
The rules that govern sequencing and decision-making are at the very heart of the process,
and the parts that people play in the process are exactly the components that are likely to
be rearranged when it comes to improving the process. Many organisations are using (and
selling) little more than Data Flow Diagramming tools for "process modelling"; these only
address the functional perspective. It is possible to use several different modelling
techniques to cover all perspectives, but then these views need to be integrated in some
way. Some form of automated repository can help avoid inconsistencies, but this still leaves
the problem of integrating the different perspectives in one’s head - essential for a
thorough understanding of the process.
Other characteristics of a good modelling technique include:
• The models should be diagrammatic rather than textual so that they are easier to
comprehend and manipulate.
• The objects and relationships represented in the model should be intuitively familiar so
that people can readily understand and talk about them with little training.
• The modelling notation should have formal syntax and semantics so that it can be
analysed and possibly enacted.
• The model must be able to handle complexity.
2.2 Selection Criteria for Process Modelling Tools
The following criteria need to be considered in the selection of process modelling tools.
They can be used not only by analysts but also by managers, who have to understand how
changes to processes will actually improve enterprise performance.
Sound Conceptual Framework

To be credible to managers, tools need a convincing framework. The Framework needs
to be sufficiently simple to describe system and process structures in terms that can be
readily grasped, sufficiently rigorous to provide a clear link between structure and
dynamic behaviour, and sufficiently generic to describe a wide range of systems and
processes.
High Level Perspective

Modelling tools should be capable of describing corporate strategies and the
operational processes that underlie them. This implies a ‘high level’ perspective, which
can first capture a minimum level of detail consistent with reality but has the capability
to disaggregate progressively to lower levels of detail as necessary.
Dynamic Capabilities
It is common that process behaviour in the short term may be different from longer-
term behaviour - process changes that appear to provide short-term benefits may even
be damaging if viewed with a different time horizon. Most people find it difficult to
think through the dynamics of process behaviour - yet many people are good at

3
describing process structure in maps and diagrams. It should therefore be possible to

describe structures in maps, then to translate the same maps directly into simulation
models that help managers to understand consequential dynamic behaviour.
Language Discipline
Seeing relationships within and between processes is vital to understanding structure
and behaviour. This need implies a mapping language having a symbol set which is
simple, comprehensive and wholly consistent in its ability to describe very different
processes. For example the same symbol set should be equally capable of mapping
problems in production logistics, administration work processes, manpower planning,
sales and marketing strategies, and so on.
Closed-Loop Perspective of Structure

Most mapping tools and simulation languages treat structural relationships within
processes as if they were linear or "open loop" (Figure 1). In fact, close examination of
any real world process will reveal that relationships are in fact circular. This is illustrated
in Figure 2. Feedback loops are fundamental components of processes - indeed any
process that does not contain feedback would quickly rage out of control. It is vital to
capture feedback relationships in order to understand how processes will behave.
Action
Information
Feedback
Loop
Result
Figure 2: Closed Loop View of the World
Management-Friendly Graphical Interface

High-level process engineering methods and tools must be used in the boardroom
rather than the back room. This implies that models must be driven from a graphical
interface - very few managers have the time or inclination to learn complex
programming languages. Ideally it should be possible to construct and simulate models
directly from graphical "maps" of process structures that are drawn on a computer
screen.
Learning and Communication

At the end of the day, process changes have to be implemented - often by different
managers from those who do the planning. Modelling tools should therefore facilitate

4
clear communication of process improvement initiatives to those not directly concerned

in the planning activity. Process maps and simulation models are the best way to
disseminate insights - far more effectively than written reports.
2.3 Process Capture
The right diagram, like a picture, speaks a thousand works. Diagrams underpin the
description, analysis and communication of ideas. They normally form the core of the
models that we use to describe the processes of the business. Sometimes referred to as a
process map, diagrams are an essential element in the visualisation of the process and
provide a basis on which to maintain process measures.
Diagrams afford a great deal of information. To be understandable, the diagram needs to

clearly depict the order of activities, flow type, organisational responsibility, role
interactions, location and decision points. In this section we briefly review a number of
diagramming techniques:
2.3.1 IDEF Diagrams
During the 1970s, the U.S. Air Force Program for Integrated Computer Aided
Manufacturing (ICAM) sought to increase manufacturing productivity through the
systematic application of computer technology. The ICAM program identified the need for
better analysis and communication techniques for people involved in improving
manufacturing productivity.
• As a result, the ICAM program developed a series of techniques known as the IDEF
(ICAM Definition) techniques, which included the following:
• IDEF0 used to produce a "function model". A function model is a structured

representation of the functions, activities or processes within the modelled system or
subject area.
• IDEF1 used to produce an "information model". An information model represents the

structure and semantics of information within the modelled system or subject area.
• IDEF2 used to produce a "dynamics model". A dynamics model represents the time-
varying behavioural characteristics of the modelled system or subject area.
In 1983, the U.S. Air Force Integrated Information Support System program enhanced the
IDEF1 information modelling technique to form IDEF1X (IDEF1 Extended), a semantic data
modelling technique.
IDEF is a modelling technique based on combined graphics and text that are presented in
an organised and systematic way to gain understanding, support analysis, provide logic for
potential changes, specify requirements, or support systems level design and integration
activities. The basic building block of an IDEF0 diagram is shown in Figure 3.

5
Figure 3 Basic Building Block of an IDEF0 Model
An IDEF0 model is composed of a hierarchical series of diagrams that gradually display

increasing levels of detail describing functions and their interfaces within the context of a
system (Figure 4). There are three types of diagrams: graphic, text, and glossary. The
graphic diagrams define functions and functional relationships via box and arrow syntax
and semantics. The text and glossary diagrams provide additional information in support
of graphic diagrams.
Figure 4: Decomposition of an IDEF0 Model

6
The IDEF technique should not be used in the early stages of a BPR initiative. When
modelling the existing business processes, the use of existing data and documents should
be specifically excluded from the model as the inputs and outputs of activities are, by
definition, the things used to co-ordinate the process. If these items are included as a
central part of the model it becomes far more difficult to break down links with the past
when seeking redesign options. The use of data and documents are important
implementation details but should not be considered relevant until that phase.
2.3.2 Flow Charts

Flow charts are commonly used to support the definition of processes. Although this
diagramming style may be familiar it is not particularly useful except to convey the order of
activities. It is not uncommon for a process map based on a flow chart to cover several walls
when printed out. Given the size of the diagrams people usually find it difficult to decide
whether or not the diagram represents a good process because the evidence is simply a
process map. The following diagram illustrates a typical flow chart.
Figure 5: A Typical Flow Chart
Users of flow chart diagrams commonly annotate them with role information in order to
convey more meaning. This effectively adds another dimension to the diagram. This is
commonly done by:
• Highlighting activities with different colours.

• Segmenting the diagram with "swim lanes" to show where the activities cross role
boundaries.
• Placing a role icon on the diagram beside the activity and using an arrow connector to
join the activity.
2.3.3 Action Workflow Diagrams

This method focuses on modelling roles and their interactions and was formulated
following research into linguistics and the network of commitments that people make with
one another. The things people talk about are represented within an elliptical loop.

7
Figure 6: The Action Workflow Loop
Each quadrant within the loop represents one of the four phases of activity in any human
interaction. The role of the "Customer" (either internal or external, is always shown on the
left and the role of the "performer" is on the right.
Every business process could be defined with several of the Action Workflow loops
connected to each other, moving through all four phases of activity. For example, when
modelling the sale of a product or service, the salesman might prepare the sale, negotiate
the terms with the customer, and delegate the despatch and shipment. The customer
would not have expressed satisfaction until the invoice was paid. Each one of these
interactions might be represented as a separate Action Workflow loop connected to the
main process definition using arrows.
2.3.4 Role Activity Diagrams (RAD)

This method of modelling processes observes the process from the point of view of the roles
capturing the interactions. Roles carry out actions (activities) and make decisions about
what to do and when, according to the business rules. Roles may carry out activities in
parallel, interacting with each other to progress the work and achieve the goals of the
process. Actions may involve the use or production of information or documents.
Individuals identify the actions that are normally their responsibility leading to rapid
identification of variations between the perceived method of operation and reality. Roles
that do not add value become apparent, usually in "hand-off" procedures. In most cases
the modelling process leads to the identification of redesign options.
RADs support process modelling at any level of abstraction, such as the interactions
between functions and customer/suppliers or the detail of a sub-procedure. The technique
also permits examination of how computer systems communicate with each other and the
business.
RAD diagrams should be read from top to bottom with the triggering action being where
the customer decides to apply for the policy (see figure 7). The only real actions in the
process are those for the Underwriter (in assessing the risk), the clerk who either checks

8
existing payment records or contacts an external credit agency. The supervisor takes the
final decision and either sends a standard rejection letter or generates the desired policy.
The waiting time of the customer could be an attribute of the state represented with the
circle.
Figure 7: A RAD Showing Part of an Insurance Process
2.3.5 Business Process Dynamics Diagrams

Business Process Dynamics offers a well established, easy to understand, simple business
notation that supports both management and the business analyst. Dynamics diagrams are
fast and easy to create and show the business events that trigger processes; the results that
the business achieves at the end of the process; and the process steps, activities, conditions,
iterations and process breaks that effect and control processes in business procedures.
Business Process Dynamics is a technique used in business analysis, detailed analysis and
information systems design. In business analysis and detailed analysis it is used as a
feedback tool for end users. Different ways of dealing with the same process can be easily
generated and discussed. In detailed analysis and information systems design, Dynamic
models are used to produce the system specification for program coding.
Diagrams are often exploded or decomposed. Drilling down or decomposing an object

shown at one level on a Process Dynamics diagram leads to the creation of a diagram at a
lower level, representing the decomposed process. There is no practical limit to the number
of levels that a Process Dynamics diagram can be decomposed.
Process dynamics diagrams may also be used to map organisations and locations;
organisations and locations can be shown as process rows (swim lanes), creating the effect
of a striated map, onto which the process steps can be placed, see Figure 8.

9
Figure 8: A Business Process Dynamics Diagram
Essentially, a Dynamics Diagram comprises:
• Events, which start processes.

• Processes, which transform inputs and add value. You are able to specify different
types of processes to differentiate between the level of detail they represent.
• Results, which mark the end points of processes.
• Connectors, which link objects together and indicate the sequence of the process.
There are nine object types in total that can be diagrammed. You can create different levels
of diagrams, each one with a different focus. For example, a Business Dynamics Model
(BDM) models the strategic requirements of a process whereas a System Dynamics Model
(SDM) models the high level design for the implementation of a process. Dynamics
Diagrams are most useful for:
• Building process models using an intuitive yet structured technique.

• Simulating processes before they are implemented so they can be designed for optimal
performance.
• Documenting business processes so that they provide:
- The basis for improvement.
- A mechanism for control.
- Ensuring consistent implementation.
2.4 Process Measures

Process measures are an integral part of the modelling exercise and are important for later
analysis and re-design. Typical measures are:
• Cost
• Capital Employed
• Overall Cycle Time
• Value Added content and quality

10
Usually the measures that will be of interest will be influenced by the overall aim of the BPR
effort and the issues being addressed.
The modelling tools should be able to deal with a number of formats because process
measures are usually "local" - they have no meaning outside the context of the business.
For instance, the definition of a quality measure would differ greatly between an insurance
company and a steel works. The formats that should be typically supported are as follows:
• Numbers, dates, text strings, costs and times.
• A simple list of values, where the user of the tool is presented with the allowable list of
potential values and must choose only one.
• A multiple list of values, where the user is presented with the list and may choose any
number of values (e.g. for skills or specialisation’s required in a role)
The definition and explanation of these measures should be stored within a tool.
There is a requirement in some modelling exercises to store a different set of process

measures for different parts of the business. This means the same process model might be
applicable to a number of functional or geographical units. Each of these functions might
have process measures that must be taken into account when analysing and simulating the
process.
2.5 Process Analysis and Redesign

The objective of the analysis phase is to understand exactly where and how effort is
currently applied and where the problems lie. The redesign phase seeks to use these new
found insights and combine them with an array of other inputs to generate options for
redesign. Both of the activities can take many forms and usually involves varying amounts
of computer support. However, human insight and creativeness are of great importance.
Tools can rarely replace this.
The best tool for the analysis of business processes is in the human mind. No technology,
tools or products can replace the creative insights that people within business produce
when asked to examine the criticality of each action and interaction within a process. An
overview of eight techniques to foster creativity are given in Appendix "A" at the end of
this white paper.
2.5.1 Peer Group Review

The specialists from the business working within the BPR study team will identify the large
majority of all workable redesign options. Apart from the diagramming techniques
described earlier, technology has yet to make a big impact here. Drawing tools largely
support the models used in the communication of ideas.

11
2.5.2 Static Analysis

Static Analysis of the process models refers to the direct calculation of the critical measures
identified for the process. The measures, which were built earlier in the process capture
stages, are manipulated to provide insights into the validity of alternative ‘what-if’ scenarios
or to show the implications of the existing process.
The software used to aid this analysis and to build static models is usually spreadsheet
software. Static models can be used for a variety of purposes such as calculating the
approximate number of resources needed, the cycle time for the process, or costs being
incurred to support a particular product.
The downside to this approach is that all possible paths through a complex process provide
different implications for cycle time, cost and so on. It then becomes very difficult to
maintain an accurate image of the process being examined as the number of alternate
paths increase.
2.5.3 Dynamic Analysis

Dynamic analysis has a strong concept of time and tends to be based on statistical sampling
techniques to maintain a more accurate image of the process and the various cases of work
running through it. These types of model permit the analyst to take into account the
influences of one case of work on another.
There are a number of approaches that can be taken in building a dynamic analysis model
of the process. The common techniques are based on discrete event simulation and
systems dynamics. Discrete event models concentrate on the state changes and
interactions of individual entities. Systems dynamics models operate at a much more
aggregate level by concentrating on the rate of change of entities. The issue of whether
systems dynamics (continuous) or discrete event simulation is most appropriate is one of
perspective. If we are concerned with a high level, aggregated view of a business or
process, continuous simulation is most appropriate. As we disaggregate, individual units
(people, batches of material, etc) become more important.
Building a dynamic model with spreadsheet technology is possible but complex, time
consuming, and difficult to maintain. Generally, dynamics models have been used to prove
the "business case" or to reduce the risks associated with implementation.
2.5.4 Rule Based Modelling

An emerging area of process analysis is in the use of rule-based modelling, also known as
Case-Based Reasoning. The technique centres on the idea of "exercising" the network of
business rules within the model. Users may focus on the qualitative aspects of the model,
removing the restriction for calculations to be purely qualitative (i.e. numerical). One does
not always have to think of the model in a mathematical context reflecting the real world,
which is not always based on numbers.

12
2.5.5 Comparing Analysis Mechanisms

When considering techniques for analysis and redesign, one must not forget the power of
the creative human mind. No technology tool can replace the creative insights that people
within business produce when asked to examine the criticality of each action and
interaction in the process.
The static analysis and dynamics modelling tools described above will provide ways of
approximating the implications of change as a snapshot of the process and, in some
situations, achieve greater understanding amongst the BPR team. Furthermore, simulation
products can be used to validate and prototype options described by the people working
within the Re-engineering team. Rule-based modelling can reflect the language and ideas
that prevail in the business domain. However, the problem with rule-based modelling is its
technological user requirement, i.e. programming skills.
2.6 Limitations of Information Engineering Tools

2
Davenport (1993)2 contends that Information Engineering methods and tools, while helpful
Davenport, T., (1993), "Process
for some areas such as documenting process designs, are not very well suited to Process Re-
Innovation: Re-engineering
Work Through Information engineering. He claims to have recorded a number of cases where companies have
Technology", Harvard Business attempted to use Information Engineering for Re-engineering but have been unsuccessful.
School Press.
Davenport submits three criticisms regarding Information Engineering as a tool for Re-
engineering.
• Process redesign occurs too late in the Information Engineering process.

• The processes that Information Engineering defines are too small to be useful.
• Information Engineering calls for a data model that is too complex and takes too long
to develop.
However, Davenport points out that there are some pieces of an information systems
methodology that are useful. He believes the two most useful are process modelling and
data modelling. Process modelling is explained in this white paper. As for data modelling,
he typically refers to entity-relationship diagramming to represent and define the data used
within an area being studied.
One Information Engineering technique is Data Flow Diagrams (DFDs). Although DFDs are
quite useful in modelling functions and data processing, they have a number of limitations
in modelling business processes, as follows:
• The traditional structured systems analysis approach and DFD tool are function
oriented. They are useful in describing the functions of a business system in static
circumstances, but for a dynamic Re-engineering environment, a change in functional
representations may result in serious changes in the data flow diagrams of the system.
• DFDs ignore the time dimension. They do not provide timing elements to specify the
sequence of processes. They fail to model business processes due to the lack of a
behavioural perspective.

13
• DFDs fail to specify who performs the process. It lacks the capability of representing
organisational perspectives.
• The definition of a data store is ambiguous in that is does not specify whether it is used
for an entity or a database. A data store usually represents a data file, which is not
appropriate for contemporary business information systems because databases are
commonly used for data stores. On the other hand, in the view of process modelling,
a data store should represent an entity because it is not supposed to assume any form
of database in the process modelling stage. However, if the data store represents an
entity, the data flow diagram becomes disorganised.
3.0 Computer-Based Re-engineering Tools
The previous section described the use of process modelling tools and techniques used in
Re-engineering projects. This section will discuss the actual computer-based tools available,
which can be used in Re-engineering. Tools for business Re-engineering are used more
frequently on methodology based BPR projects than on intuitive ones. In some instances,
methodologies are based on the use of specific tools. See the second white paper in this
series – "Implementing Business Process Re-engineering".
Through using these tools, the Re-engineering teams expects to improve productivity, finish
projects faster, produce higher quality results and eliminate tedious jobs in order to
concentrate on value-added work. To reproduce these benefits, the BPR tool should be easy
to use and not directly focused for use by technicians; managers and professionals will need
to use the tool. Furthermore, they should enhance clarity. They should enforce consistency
in analysis and design and they should ideally permit iterative, top-down refinement from
the BPR project goals to the solution.
3
3.1 Six Categories of BPR Tools
Klein, M.M., (1994), "Re- Klein (1994) 3 observes six different types of tools that can be used in the Re-engineering
engineering Methodologies
and Tools: A prescription for effort.
Enhancing Success", Journal of
Information Systems Project Management
Management.
These tools are typically used for planning, scheduling, budgeting, reporting and
tracking projects. An example of a standalone, off-the-shelf, project management tool
would be Microsoft Project.
Co-ordination
These tools are primarily used as a form of distribution and communication, elements
which are of paramount importance in the Re-engineering effort. They can distribute
plans and communicate updated details of projects. The primary categories are E-mail,
scheduling applications, shared spreadsheets, bulletin boards, and groupware.
Modelling
In most cases a process can be readily understood in terms of its structure and workings
if it is modelled. Modelling tools aid this purpose. Most of the tools currently available

14
for this category are integrated Computer-Aided Software Engineering (CASE) toolsets
for integrated analysis, design and development of computer systems.
Business Process Analysis

These tools are used for systematic reduction of a business into its constituent parts and
the examination of the interactions among those parts. In general, the same tools used
for modelling are used for business process analysis, although not necessarily vice versa.
Human Resource Analysis and Design

These tools are used to design and establish the human or social part of the re-
engineered process and are often standalone. One sub-category of this type of tool is
used for requisition/candidate tracking and position history. Others include skill
assessment, team building, compensation planning and organisation charting.
Systems Development
These tools automate re-engineered business processes. Categories include visual
programming tools, application frameworks, coding workbenches and object reuse
libraries.
3.2 Computer-Aided Software Engineering (CASE) Tools
CASE tools can be defined as "any computer software or system which aids a software
engineer in the specification, design, development, testing or maintenance of other
computer software or any aspect of the management of this process" Ince (1994)4. The
principal advantage of a CASE tool is that it offers an integrated package of capabilities for
4
Ince, D., (1995), "The CASE these tasks. This has proved more productive than standalone tools.
Market – A Review", Institute
of Software Engineering. The CASEwise Corporate Modeler software, for example, is a windows-based Computer
Aided Software Engineering (CASE) tool which allows you to design systems using the
general Information Engineering techniques provided with it. The techniques supported by
the tool are:
Hierarchical Decomposition
Business Process Dynamics Modelling and Simulation
Matrices Diagramming
Entity Relationship Diagramming
Data Flow Diagramming
Further details of these techniques can be found in the Corporate Modeler Overview
document available from CASEwise.
3.3 Capabilities of CASE Systems
Various CASE tools have different capabilities that can be summed up by the terms upper
and lower CASE, see figure 9.

15
Figure 9: Upper and Lower CASE Tools
Upper CASE tools assist the developer in producing complete and consistent process and
system specifications, which are then entered into the data dictionary (repository) facility
offered by the tool. Documentation, the preparation of which is a significant drain on
resources when structured techniques are used, is generated automatically by CASE tools.
Lower CASE tools can be used independently of upper CASE tools. The general objective
of these lower CASE tools is to generate code from the specifications of the database
structure and from screen and report layouts. The programmer can often use a simple
interface to input the information, i.e. dialogue box, which the generator uses to produce
executable code. This code may then be refined by the programmer.
CASE tools are an excellent vehicle for prototyping. They help to specify the hierarchy of
menus for the user interface, and to specify screens and reports in consultation with the
users. The code generator then produces the necessary code.
5
Martin, J., (1990) "Information A CASE system may also be considered as a delivery vehicle for structured methodologies
Engineering", Englewood Martin (1990)5. Empirical observations suggest that with CASE, quality-enhancing
Cliffs, N.J. Prentice Hall. methodologies can be used more productively (a 30 to 40 per cent productivity increase
6
Zwass, V., (1992) was reported by Zwass (1992)6). Further studies point to higher productivity, improved
"Management Information software product quality and better project management as benefits associated with CASE
Systems", Wm. C. Brown tools.
Publishers
The focal facility of a CASE tool is the repository, a central database for storing and
managing project data, which contains all the information about the system being
developed from the plans through to the entities that appear in Data Flow Diagrams, on to
the code and even to project management information. This is illustrated in figure 10
below.

16
Figure 10: The Key Components of a CASE Tool
Going beyond development, CASE tools also make it possible to easily maintain system
specifications as changes are recorded in the tool's repository. CASE tools facilitate trace-
ability - the ability to relate program code to the analysis and design entities it implements.
The capability to develop software faster thanks to the use of CASE technology has been
recognised as one element in the formula for significantly reducing time-to-market for
products and services, and thus as a component in the search for competitive advantage.
When evaluating the organisational effectiveness of CASE technology, we must consider its
three dimensions. Namely, CASE is not only a software production technology, but also a
technology for co-ordinating a team effort and an organisational technology that helps to
shorten the time-to-release software across the enterprise.
The ability to build up libraries of reusable code has long had an understandable appeal.
Developers can now reach for software components that had been developed for other
systems.
4.0 Conclusions
By using tools for business process re-engineering, BPR practitioners should expect to
improve productivity, finish process designs faster, produce higher quality results and
eliminate routine cumbersome work in order to concentrate on value-added work. This
white paper has primarily focused on process modelling as a method of modelling business
processes, and the characteristics of computer-based re-engineering tools that are currently
available, including CASE tools. The Business Process Dynamics Modeler, which is one such
CASE tool product, is an integral part of the CASEwise Corporate Modeler software
package.
Process modelling offers a way for the BPR practitioners to facilitate discussion,
communication and analysis between the members of the re-engineering team. They allow
17
the team to abstract from the real world, emphasising objects and relationships that are of
interest. For a modelling tool to be effective, especially in the re-engineering initiative, it
must represent relevant perspectives and satisfy certain criteria. For instance, the tool
should ideally represent the four perspectives, organisational, behavioural, informational
and functional views outlined earlier in this document. Also, the tools must be easy enough
for management as well as the business analyst to use.
The white paper has also reviewed various process capture and analysis techniques which
are available. Process capture basically requires representing the relevant perspectives as
described above. There are a number of techniques that effectively support process
capture, e.g. Business Process Dynamics diagrams, IDEF and Role Activity diagrams. Also,
the tool must effectively allow the users to employ the information captured in the models
and combine it with other data to generate feasible options for redesign. Such models,
include static analysis and system dynamics models.
Finally, many of the integrated process capture, analysis and redesign tools are computer-
based. However, apart from these aspects, other tools such as project management, human
analysis design and systems development may be required in a re-engineering initiative.
Having all the relevant tools will allow the practitioner to use the set of tools from
beginning to end. Furthermore, to be most effective the tools should, where appropriate,
integrate through a common repository.

18
APPENDIX "A"
Techniques to Foster Creativity
Blue-Slip Technique
One of the simplest yet most effective creativity generation techniques. It can be used
to collect a large number of ideas in a short time. Also, the ideas are recorded and
shared without disclosing the name of the originator, making people feel more
comfortable about expressing ideas.
Each person receives a stack of blue slips for which they write an answer to a pre-
specified how to question, i.e. how can our company improve its service to customers.
On completion the slips are collected and sorted and related ideas are grouped.
Brainstorming Technique
There are two principles for the brainstorming procedure: deferring judgement and
quantity breeds quality. By withholding evaluation until ideas have been generated,
people are not threatened by criticism of their ideas. Vocalising the ideas stimulates
others to give their ideas. This freewheeling and piggy backing activity often produces
many creative solutions.
Dyad Technique
Creativity research reveals that the most productive group size is two. Two people
serving as a sounding board for each other produce more ideas per person than any
other group technique.
Interrogatories: 5Ws/H Technique

Who-what-where-when-how and why questions help the people involved expand their
view of a problem or opportunity. This questioning also makes sure that all related
aspects have been considered. By going through several cycles of this technique,
alternatives related to the problem or opportunity can be explored exhaustively.
Nominal Group Technique

This technique uses the positive features of brainstorming. The group members
generate ideas silently in writing, followed by round-robin recording of ideas, serial
discussions for clarification, then subsequent rounds of writing. This approach reduces
the inhibiting factors of brainstorming whilst the public sharing of ideas stimulate new
ideas.
Peaceful Settings Technique

This technique allows people to mentally remove themselves from present
surroundings, giving them access to a less cluttered, more open mental process. The
goal is to try to eliminate the constraints of the normal work environment that impede
full use of the individual’s native creative ability.
Progressive Abstraction Technique

By moving progressively through higher levels of problem abstraction, alternative
problem definitions are generated. When a problem is systematically enlarged in this
way, new definitions emerge that can be evaluated for their usefulness and feasibility.
Once an appropriate level of abstraction is reached, possible solutions become easier to

19
identify. This technique is excellent in that it provides a structure to the problem solver
for systematically examining problem sub-structures and connections.
Wishful Thinking Technique

When applied properly this technique frees people from unnecessary but unrecognised
assumptions that are made concerning the scenario of concern. Proven steps that
should be taken when using this approach are as follows;
• State the question, goal situation or problem.

• Assume anything is possible.
• Using fantasy, make statements such as ‘What I really want to do is….’,
Examine each fantasy statement and, using it as stimulation, return to reality and make
statements such as: ‘Although I cannot do that, I can do this by….’

20
Workflow Implementation ERP EFQMAbout Financial
CASEwise...
Modelling TQM System Integration
CASEwise has, since the company's formation in 1989, concentrated on
Business Process providingImprovement ISO9000range
the most functional and comprehensive Change Management BPR
of packaged business
SAP EFQM Financial modelling
Modelling software TQM
availableSystem Integration
for the Microsoft Windows market. Workflow Implementation
CASEwise's Corporate Modeler™ software provides a common platform that
Change Management BPR
enables Finance, ISO9000
Information Technology,Business
Human Resources,Process
and Business Improvement
Workflow Implementation ERP EFQM andFinancial Modelling TQM System Integration

Processes to be modelled, explored and understood in a totally integrated
holistic manner.
To compliment its modelling technology, CASEwise offers a full range of
professional services to ensure successful implementation. CASEwise
SAP EFQM Financial Professional
Modelling ServicesTQM SystemandIntegration
include education training, methodologyWorkflow Implementation
development, on-site consultancy services and a series of seminars, all of
which provide potential users with a greater understanding of the capabilities
Change Management BPR
and benefits ISO9000
of Business Business
Process Modelling Process Improvement
within the enterprise.

For more information, contact:
CASEwise
www.casewise.com
Workflow Implementation EUROPE
House 9–13EFQM
Station ERP Financial
Swiss Terrace Modelling
Reservoir
USA
TQMRoadSystem Integration
Place 1601 Trapelo
Activity Based Costing London NW6 4RR

Telephone:(ABC) Business
+44 (0)171 722 4000 Contingency
Telephone:Planning
Waltham, MA 02451
ERP Strategy Planning
+1 781.895.9900
Facsimile: +44 (0)171 722 4004 Facsimile: +1 781.895.9914

3 - BPR Tools

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3 - BPR Tools

Uploaded by

Copyright:

Available Formats

Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP

Change Management BPR ISO9000 Business Process Improvement

2.0 Process Modelling 2

3.0 Computer-Based Re-engineering Tools 14

Figure 1: Open Loop View of the World 4

APPENDIX "A" Techniques to Foster Creativity 19

Copyright© CASEwise 1999

Copyright© CASEwise 1999

2.0 Process Modelling

• As a baseline for continuing process improvement. Suggestions for change can be

• Last but not least, for designing a new business process.

2.1 What Makes a Good Process Model?

• Behavioural, representing when activities are performed, with sequencing, feedback

• Organisational, representing where and by whom activities are performed.

• Informational, information produced or manipulated by a process.

Copyright© CASEwise 1999

Other characteristics of a good modelling technique include:

• The model must be able to handle complexity.

2.2 Selection Criteria for Process Modelling Tools

Sound Conceptual Framework

High Level Perspective

Copyright© CASEwise 1999

describing process structure in maps and diagrams. It should therefore be possible to

Closed-Loop Perspective of Structure

Figure 2: Closed Loop View of the World

Management-Friendly Graphical Interface

Learning and Communication

Copyright© CASEwise 1999

clear communication of process improvement initiatives to those not directly concerned

2.3 Process Capture

Diagrams afford a great deal of information. To be understandable, the diagram needs to

2.3.1 IDEF Diagrams

• IDEF0 used to produce a "function model". A function model is a structured

• IDEF1 used to produce an "information model". An information model represents the

Copyright© CASEwise 1999

Figure 3 Basic Building Block of an IDEF0 Model

An IDEF0 model is composed of a hierarchical series of diagrams that gradually display

Figure 4: Decomposition of an IDEF0 Model

Copyright© CASEwise 1999

2.3.2 Flow Charts

Figure 5: A Typical Flow Chart

• Highlighting activities with different colours.

2.3.3 Action Workflow Diagrams

Copyright© CASEwise 1999

Figure 6: The Action Workflow Loop

2.3.4 Role Activity Diagrams (RAD)

Copyright© CASEwise 1999

Figure 7: A RAD Showing Part of an Insurance Process

2.3.5 Business Process Dynamics Diagrams

Diagrams are often exploded or decomposed. Drilling down or decomposing an object

Copyright© CASEwise 1999

Figure 8: A Business Process Dynamics Diagram

Essentially, a Dynamics Diagram comprises:

• Events, which start processes.

• Building process models using an intuitive yet structured technique.

2.4 Process Measures

Copyright© CASEwise 1999

• Numbers, dates, text strings, costs and times.

There is a requirement in some modelling exercises to store a different set of process

2.5 Process Analysis and Redesign

2.5.1 Peer Group Review

Copyright© CASEwise 1999