Professional Documents
Culture Documents
3 - BPR Tools PDF
3 - BPR Tools PDF
Business
Process
Re-engineering
Contents
1.0
Introduction
2.0
Process Modelling
2.1
2.2
2.3
Process Capture
2.3.1
IDEF Diagrams
2.3.2
Flow Charts
2.3.3
2.3.4
2.3.5
2.4
Process Measures
10
2.5
11
2.5.1
11
2.5.2
Static Analysis
12
2.5.3
Dynamic Analysis
12
2.5.4
12
2.5.5
13
13
2.6
3.0
4.0
14
3.1
14
3.2
15
3.3
15
17
Conclusions
Figures
Figure 1:
Figure 2:
Figure 3:
Figure 4:
Figure 5:
Figure 6:
Figure 7:
Figure 8:
10
Figure 9:
16
Figure 10:
17
Appendices
APPENDIX "A" Techniques to Foster Creativity
Copyright CASEwise 1999
19
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 reengineering 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 reengineering effort. The final aspect of this white paper considers CASE (Computer-Aided
Software Engineering) tools, and their value within the re-engineering effort.
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 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.
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
engineers were classified by Curtis et al. (1992)1 into four perspectives:
Functional, representing what activities are being performed and what data flows
connect them.
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 ones 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.
Action
Information
Feedback
Loop
Result
As a result, the ICAM program developed a series of techniques known as the IDEF
(ICAM Definition) techniques, which included the following:
IDEF2 used to produce a "dynamics model". A dynamics model represents the timevarying 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.
Copyright CASEwise 1999
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.
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:
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.
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.
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:
10
Cost
Capital Employed
Overall Cycle Time
Value Added content and quality
Copyright CASEwise 1999
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:
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 specialisations 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.
11
12
Davenport (1993)2 contends that Information Engineering methods and tools, while helpful
for some areas such as documenting process designs, are not very well suited to Process Reengineering. He claims to have recorded a number of cases where companies have
attempted to use Information Engineering for Re-engineering but have been unsuccessful.
Davenport submits three criticisms regarding Information Engineering as a tool for Reengineering.
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.
Klein (1994) 3 observes six different types of tools that can be used in the Re-engineering
effort.
Project 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 reengineered 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.
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
these tasks. This has proved more productive than standalone tools.
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.
15
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
A CASE system may also be considered as a delivery vehicle for structured methodologies
Martin (1990)5. Empirical observations suggest that with CASE, quality-enhancing
methodologies can be used more productively (a 30 to 40 per cent productivity increase
was reported by Zwass (1992)6). Further studies point to higher productivity, improved
software product quality and better project management as benefits associated with CASE
tools.
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
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 traceability - 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
Copyright CASEwise 1999
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 computerbased. 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 prespecified 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 individuals 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
Copyright CASEwise 1999
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;
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
Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP
Change Management BPR ISO9000 Business Process Improvement
Workflow Implementation ERP EFQM Financial Modelling TQM System Integration
Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning
Business Process Improvement ISO9000 Change Management BPR
SAP EFQM Financial Modelling TQM System Integration Workflow Implementation
Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP
Change Management BPR ISO9000 Business Process Improvement
Workflow Implementation ERP EFQMAbout
Financial
Modelling TQM System Integration
CASEwise...
Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning
CASEwise has, since the company's formation in 1989, concentrated on
Business Process
Improvement
ISO9000range
Change
Management BPR
providing
the most functional and comprehensive
of packaged business
software TQM
availableSystem
for the Microsoft
Windows market.
SAP EFQM Financial modelling
Modelling
Integration
Workflow Implementation
Strategy Planning Activity
Based Costing (ABC) Business Contingency Planning SAP
CASEwise's Corporate Modeler software provides a common platform that
enables Finance,
Information
Technology,
Human Resources,Process
and Business Improvement
Change Management
BPR
ISO9000
Business
Processes to be modelled, explored and understood in a totally integrated
Workflow Implementation
ERP EFQM andFinancial
Modelling TQM System Integration
holistic manner.
Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning
To compliment its modelling technology, CASEwise offers a full range of
Business Process
Improvement ISO9000 Change Management BPR
professional services to ensure successful implementation. CASEwise
SAP EFQM Financial Professional
Modelling
SystemandIntegration
Workflow Implementation
ServicesTQM
include education
training, methodology
development, on-site consultancy services and a series of seminars, all of
Strategy Planning Activity
Based Costing (ABC) Business Contingency Planning SAP
which provide potential users with a greater understanding of the capabilities
Change Management
BPR
ISO9000
Business
Process Improvement
and benefits
of Business
Process Modelling
within the enterprise.
Workflow Implementation ERP EFQM
Financial Modelling TQM System Integration
For more information, contact:
Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning
Business Process Improvement ISO9000 Change Management BPR
SAP EFQM Financial Modelling TQM System Integration Workflow Implementation
CASEwise
Strategy Planning Activity Based Costing
(ABC) Business Contingency Planning SAP
www.casewise.com
Change Management BPR ISO9000 Business Process Improvement
USA
EUROPE
Workflow Implementation
Financial
Modelling
TQMRoadSystem Integration
Reservoir
Place 1601 Trapelo
Station ERP
House 913EFQM
Swiss Terrace
Waltham, MA 02451
London NW6 4RR
Activity Based Costing
Business
Contingency
ERP Strategy Planning
Telephone:Planning
+1 781.895.9900
Telephone:(ABC)
+44 (0)171 722
4000
Facsimile: +1 781.895.9914
Facsimile: +44 (0)171 722 4004
Business Process Improvement ISO9000 Change Management BPR
SAP EFQM Financial Modelling TQM System Integration Workflow Implementation
Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP
Change Management BPR ISO9000 Business Process Improvement
Workflow Implementation ERP EFQM Financial Modelling TQM System Integration
Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning
Business Process Improvement ISO9000 Change Management BPR
SAP EFQM Financial Modelling TQM System Integration Workflow Implementation
Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP
Change Management BPR ISO9000 Business Process Improvement