8 BPR METHODOLOGIES:

METHODS AND TOOLS

Minder CHEN
George Mason University

Introduction

Hammer and Champy (1993) defined reengineering as "the fundamental

rethinking and radical redesign of core business processes to achieve dramatic
improvements in quality, cost, and cycle time." Earlier literature on business
process reengineering (BPR) focused only on the principles of BPR and provided
us with cases of successful BPR projects [(Hammer, 1990); (Davenport and Short,
1990)] that address only the "what" and "why" questions (What is reengineering?
Why is reengineering necessary?). However, no comprehensive and
methodological approach to conducting BPR projects to answer the "how" question
has been developed. Once many organizations have committed to initiating BPR
projects, there is a great need to provide a "how-to" guide for managing them,
giving rise to the development of BPR methodologies by many practitioners and
academicians.

In this paper, we first present a generic meta-model of BPR methodology. On

the basis of the meta-model, we have developed a BPR methodology called BPR
Life Cycle (BPR-LC) that can be customized by organizations for their own BPR
projects or used to evaluate other methodologies.

The BPR-LC methodology decomposes a business reengineering project into

interrelated phases in which a set of integrated structured methods and tools is
applied to specific tasks in each BPR phase. Each phase and its detailed tasks
contain clearly defined goals and deliverables. We will also discuss several
methods and tools that are appropriate for supporting BPR projects.

BPR Methodologies

Reengineering is not automation of an existing system (i.e., computerization) or

doing less with less (i.e., downsizing). It is the obliteration of what now exists
conceptuaLLy and starting over with the design of a process on a clean sheet of

D. J. Elzinga et al. (eds.), Business Process Engineering: Advancing the State of the Art
© Kluwer Academic Publishers 1999
188 BPR Methodologies

paper (Hammer, 1990). Reengineering sometimes will transfonn every aspect of

an organization, including organization structures, values, reward systems, etc.
All of these aspects should be considered concurrently to ensure successful
implementation of a BPR project.

Objectives of companies initiating reengineering projects include: improved

customer satisfaction, shortened process cycle time, improved product/service
quality level, reduced costs in production and marketing, and increased
competitiveness in the marketplace. Because of the complexity of reengineering a
process, a systemic approach to managing a BPR project is needed.

Meta-Model for BPR Methodology

A BPR methodology called BPR-LC that uses a life-cycle approach is described

in this paper. The development of this methodology was guided by a meta-model
that defines all aspects of a BPR methodology. Because a BPR project is itself a
process that needs to be analyzed and managed (Moad, 1993), users can use the
meta-model to customize a proposed BPR methodology for their BPR projects or
use it to compare various BPR methodologies.

The meta-model of the BPR methodology is depicted in Figure I in which the

BPR project is divided into major phases that are further broken down into tasks
and steps. Each element in the work breakdown structure can be defined in terms
of the inputs required for starting the work and the deliverables to be created by the
work.

BPR Work Breakdowns

I Phase I require ·1 Input

I
I Task I
I Step
create
.joeliverable
I
are involved in apply to

BPR Team Structures BPR Methods and Tools

I and Principle
Concept I
I Role
I
serve as
use
BPR

~PPlyto
BPR I I BPR
IparticiPant I Method I supported I
by
Tool I

Figure 1. The Meta Model for a Business Process Reengineering Methodology

BPR Methodologies 189

The BPR team consists of participants who play different roles at various phases
of the BPR project. We suggest that the core team size should be kept under 12.
The core team can be supported by subject-matter experts when needed. The team
members should be sincerely committed to the project and should have a mixture
of the following skills: teamwork, process engineering, quality management,
information systems, benchmarking, organizational and job design, and change
management. Team members can include employees, customers, suppliers, and
external consultants.

BPR methods and tools can be applied to various phases, tasks, or steps of the
BPR Life Cycle. A clear understanding of BPR concepts is critical in the earlier
stages of the BPR phases to ensure that initiatives are appropriate for the
circumstances. BPR principles are useful in guiding the redesign of new processes,
as are methods such as business process modeling and analysis methods (e.g.,
IDEFO and Activity Based Costing). BPR tools are computer-aided tools that
support specific methods. Deliverables from BPR work include items such as
process diagrams, analysis reports, or design documents that are often created,
maintained, and generated by BPR tools.

Review of BPR Methodologies

Many BPR methodologies have been proposed. One suggested by Davenport

(1993) emphasizes the importance of process visioning and the identification of
information technology levers. The methodology ends at the designing and
prototyping stage and no implementation or improvement phases are mentioned in
this high-level approach to process innovation.

Hammer (1991) has presented a simple four-stage model that includes: (1)
Mobilization: BPR teams need to create a sense of urgency about the need to
reengineer. Tasks include: Develop organizational commitment, establish
governance structure, formulate a vision of the enterprise, communicate a case for
action, and assess the readiness, capabilities, and barriers. (2) Diagnosis: The
objective is to discover the root problems in the existing process. Tasks include:
Identity a process to be reengineered, understand the customer, analyze the current
process, and set targets for the new process. (3) Redesign: The BPR team needs to
be very creative in coming up with innovative solutions. Tasks include: Reach
breakthrough concepts, develop new designs, re-orchestrate the business system,
conduct pilot projects and evaluate their results. (4) Realization: Face and handle
the challenges of implementing the technologies and changing the organizational
culture. Tasks include: Formulate implementation strategies, start change
campaign, develop supporting infrastructure, and institutionalize the change.
Hammer did not emphasize the importance of methods and tools in his BPR
methodology.
190 BPR Methodologies

Coopers & Lybrand's BreakPoint BPR Methodology has only three major
phases: Discover, Redesign, and Realize [(Johansson, et aI., 1993); (Coopers &
Lybrand, 1994)]. Each phase is divided into 4 or 5 modules. Each module is
divided into 2 to 5 tasks. The methodology combines the first two phases of
Hammer's approach into one discovery phase. Coopers & Lybrand's internal
methodology manual classifies core techniques used in BPR into the following
categories: basic consulting techniques, process oriented techniques, resource
utilization techniques, structure techniques, and change management techniques.
However, the reader still has to go to other resources to learn the specifics of these
techniques.

Rapid Re BPR Methodology developed by Manganelli & Klein (1994) provides

a step-by-step guide to a five-stage BPR methodology: Preparation, Identification,
Vision, Solution (technical and social design), and Transformation. Each stage is
broken down into tasks. That the first three stages do not have distinct boundaries
is one major weakness of the methodology.

James Martin's (1995) Enterprise Engineering methodology represents an effort

to integrate TQM, procedure redesign, value stream reinvention, enterprise
engineering, and strategic visioning. These approaches build upon each other and
should be chosen based on the degree of change involved. Some information
engineering techniques have been incorporated into the methodology. Two
infrastructure change processes (information technology development and human
and culture development) are required to support these change initiatives in
organizations.

A BPR Life Cycle Methodology

Based on these existing BPR methodologies describ~d in the literature and used by
BPR consulting firms, we have synthesized a comprehensive life cycle approach to
conducting BPR. The BPR Life Cycle Methodology presented in Figure 2 has
seven phases:

1. Visioning: Companies engage in a reengineering effort because they want

to catch up with their competitors, to stay ahead of the competitors, and/or
to respond swiftly to the changing structures and dynamics of the
marketplace (Hammer and Champy, 1993). Visioning is required for an
enterprise-wide reengineering effort. Employees should be involved in the
creation of a shared new vision. This stage includes several tasks:
• Develop an overview of the current organizational
structure and business processes. The real
BPR Methodologies 191

organizational chart and macro-level processes are

identified.
• Develop an organizational commitment to
reengineering. Without a firm commitment from top
management and broad-based support throughout the
whole organization, a successful reengineering
initiative is difficult to achieve in the long run.
• Develop and communicate a business case for action.
The mandate for change needs to be communicated
consistently and constantly to all parties involved in
the reengineering initiative. A business case that
forcefully and convincingly argues the need for
dramatic change is necessary to mobilize the troops.

IBPR-LC©I
Identity business Enterprise-wide engineering
processes to be
reengineered

Process-specific

I~edeslgnlngI
engineering

IEvaluating I
IImplementing I
IImproving I
Manage change and stakeholder interests

Figure 2. Business Process Reengineering Life Cycle Methodology

• Create a new corporate vision and strategies. The new

vision is used to guide the formulation of strategies
and goals; and strategies may help organizations in
focusing on core processes that are critical to the
business success. Stretch goals need to be set to
challenge traditional wisdom and to force participants
to think "out-of-the-box."
192 BPR Methodologies

• Assess capabilities and barriers. Change management

for a reengineering initiative needs to be managed
from day one. Assessing the capabilities and barriers
for introducing drastic technical, organizational, and
cultural change is the first step toward change
management in a BPR project.

2. Identifying: Based on the macro-level process map, the BPR team needs to
identify which business processes are to be reengineered. Tasks in this
phase include:
• Develop a high-level process map based on the value-
chain model to show dependency among processes.
One can use a systemic and exhaustive bottom-up
approach to create macro-level processes based on
cluster analysis of a process/data matrix (Davenport
and Linder, 1991). Another more common approach
is to use facilitated workshops or extensive interviews
involving senior management to identify critical
business processes (Davenport, 1993). People tend to
pay attention to operational processes and often
neglect high-level managerial processes such as
business and strategy development.
• Evaluate and select processes to be reengineered.
There are two factors involved in selecting processes
to be reengineered. The first is the impacts of the
process to be reengineered. The second factor is the
difficulty of implementing the BPR project. Ideally,
we would like to select projects that have high impacts
and will be easy to implement. However, such
projects are difficult to come by. Typical processes
that are selected for BPR projects are: processes that
are broken; core processes that have high impacts and
high added-value; cross-functional processes;
customer-facing processes managed by front-line
workers; new processes that offer new products and
services.
• Identify owners of business processes. All the
processes selected should have committed process
owners who have vested interests and enough political
clout in the organization to marshal the resources
needed to support the project.
• Prioritize selected processes to be reengineered. Two
to five business processes at a time should be targeted
BPR Methodologies 193

for reengineering to ensure that proper resources are

made available to BPR teams.
3. Analyzing: Once a process has been selected to be reengineered, the BPR
team enters into stages specific to an individual BPR project. The specific
business process needs to be analyzed in detail. Tasks in this stage include:
• Conduct a preliminary study. Determine the right
scope of the process such that it is not so broad that it
cannot be handled with existing resources nor so
narrow that the impacts of reengineering will be too
limited.
• Develop a high-level AS-IS baseline process model of
the existing process. A decomposed process model of
three to four levels deep is sufficient. The purpose of
this stage is to find problems and opportunities that
are faced by the business process. Once these
problems/opportunities have been identified, the
analysis of the existing process model should be
terminated to avoid the "analysis paralysis" trap.
• Perform activity-based costing if cost cutting is the
primary objective of the BPR project. Expose waiting
time and non-value-added activities so that costs can
be assigned based on productive activities.
Productivity and profitability can be measured in
terms of task, product, and customer type.
• Measure critical process metrics. Measurement of an
existing process can be very useful in benchmarking.
It also helps in determining the root causes of
problems and should be used to gauge the
improvement made over time.

4. Redesigmng: Identify enabling IT and create design alternatives to

reengineer the process. Creative ideas may come from understanding
potential IT enablers. Tasks at this phase include:
• Create ideas for dramatic changes. 'Thinking-out-of-
box" is required to come up with innovative ideas to
reach a conceptual breakthrough. Willingness to
challenge the very basic assumptions of the process
and the business is the key to a breakthrough.
• Explore enabling technologies. BPR project should
not be driven by information technology, but, if used
properly, information technology can be a great
enabler. There always is an emerging technology on
the horizon that may be the right tool for the right job.
194 BPR Methodologies

Identifying and evaluating IT enablers are critical

tasks in the BPR redesign phase.
• Identify core sub-processes. Sub-processes can be
eliminated, simplified, made parallel, or integrated.
Core sub-processes that are causing a bottleneck in the
system or are contributing most to added-value should
be the focus of the redesign effort.
• Design alternative new processes. Two or three
alternative designs of new processes should be
proposed based on different assumptions in terms of
resource requirements and degree of change required.

5. Evaluating: Evaluate redesigned alternative process models and select a

design alternative to use in proceeding with the implementation phase.
• Develop criteria to evaluate alternatives of redesigned
processes.
• Estimate costs, benefits, and risks involved in
proposed designs. Identify all the hidden costs and
intangible benefits involved. Major BPR investments
often are justified by their intangible benefits such as
time for customer service, speed to market (Violino,
1997).
• Evaluate design alternatives based on costs, benefits,
and risks, as well as any additional criteria identified.
• Select and recommend a reengineered process.

6. Implementing: Implement the reengineered process. Implementation is as

important as redesign because "even when breakthroughs are achieved on
the conceptual level, implementation can be daunting." (Price Waterhouse,
1995).
• Plan IT implementation. Development tools and
development team members should be chosen
carefully. Rapid application development or a
packaged solution should be considered as alternative
implementation strategies.
• Plan organization implementation. BPR and
technology change always cause organizational
change. Detailed organizational change plans should
be designed to ensure that appropriate changes are
introduced to guarantee successful process change.
• Develop a prototype system. For a large BPR project
that needs to be implemented in multiple locations, the
BPR team should consider conducting pilot projects.
BPR Methodologies 195

Results from a pilot should be used to revise the

prototype system before a large-scale rollout.
• Develop new performance measures. These measures
will be used for evaluating BPR results and for the
continuous improvement of the process.

7. Improving: Process owners of the reengineered processes should measure

the performance indicators of the process to evaluate the impacts of BPR
and try to improve the process continuously. They should use and
implement continuous process improvement (CPI) to amend the process on
an on-going basis (Robson, 1991).
• Implement large-scale rollout. The know-how of
conducting BPR projects should be transferred to other
teams for future BPR projects to institutionalize BPR
practices in the organization.
• Monitor process performance constantly. Tools such
as data warehouse technology can be used to support
the collection, measurement, and reporting of the new
process.
• Improve the process continuously. Over time, it may
be demonstrated that CPI is not sufficient to improve
the reengineered process enough to be competitive in
the marketplace. Then is the time to consider
reengineering the process again.

The first two phases are required for an enterprise-wide reengineering effort.
The third to seventh phases are for process-specific reengineering projects. The
most difficult issue facing the BPR team is resistance from people to introduction
of dramatic changes. Therefore, a BPR team needs to manage the BPR project as a
planned change. To rally support and minimize resistance, stakeholders' interests
need to be accounted for from the beginning.

The BPR-LC methodology can be used to support BPR project scheduling and
management. It also helps in selecting proper techniques and tools for specific
tasks during a BPR project.

Several guiding principles in applying BPR methodology include:

1. Customer focus: Focus on customer-facing processes and support of front-line

workers. Understanding who are customers of a process and what their
requirements are is the first step in any BPR project.
2. Cycle-time reduction: The major improvement of many successful BPR cases
is the reduction of the cycle-time of the process.
196 BPR Methodologies

3. Sustaining continuous support and commitment from top managers and people
involved in the process. BPR teams should consider selecting one or two
"low-hanging fruits" (i.e., quick hits) that are easy to implement but may not
have high impacts. Using these quick hits to build up continuous
commitment, the BPR team can focus on long-term strategic process redesign
and change.
4. Focus on core business processes, but during redesign and implementation also
take into consideration all aspects of the process.
5. Use information technology to enable new business processes, not just to
automate existing ones. The awareness of emerging technologies in the
redesign phase of the BPR project can help BPR teams select appropriate
technologies for their redesign.
6. Start with a clean sheet of paper during redesign and think out-of-the-box by
going back to the basic purposes of the process. Don't be afraid of asking
why. BPR principles and methodology can be used to create new processes to
support new products/services. The creation of new processes may create more
added value than the redesign of existing processes.
7. Adopt a BPR methodology and use proven methods and tools in analyzing and
redesigning the process. Many BPR projects fail because people do not follow
a proper BPR methodology.
8. Manage the change and implementation process from the beginning of the
project by identifying issues involving all the stakeholders. Constantly
communicate reasons for change with all the parties involved and use a team
approach to getting broader participation.
In the next section, we will discuss several important BPR methods and tools
that can be used to support BPR-LC.

BPR Methods and Tools

A survey of the top one-third of Fortune 500 companies found that 61 % of the
respondents had process management programs (Deloitte & Touche, 1993).
However, most companies did not have enough knowledge of methods and tools for
process modeling. Methods and tools are critical to the understanding of complex
business processes. However, integration among existing methods and tools was
poor. In this section, we will discuss several representative methods and tools for
business reengineering and propose a framework for integrating them.

Modeling Business Processes

Both Total Quality Management (TQM) and BPR have a process orientation.
The assumption is that the quality of a product is based on the quality of its
BPR Methodologies 197

process. We will first define what a process really means and then introduce
several business process modeling methods.

Understanding the Process

A process is an end-to-end set of activities that collectively create value for a

customer. A process can be categorized according to the following dimensions
(Davenport and Short, 1990):

1. Organizational boundary: Inter-organizational (i.e., interactions with

customers or vendors), inter-functional (i.e., cross-functional boundaries), or
interpersonal (i.e., work group within a functional area). The greater the
scope of the process organizational boundary, the more difficult it is to
implement the process.
2. Central objects processed: physical objects or information objects. When a
process deals mainly with an information object, it is more difficult to
understand and analyze such a process.
3. Level of activity: operational or managerial. Earlier BPR projects tended to
focus on operational-level processes such as order fulfillment and
procurement. Without changing the corresponding managerial process, the
benefits ofBPR may not last long (Champy, 1994).
As an example of using these dimensions to analyze a process, we can
characterize an order fulfillment process as an operational-level and inter-
organizational process in which the order (i.e., information) is the central object to
be processed.

Capturing important attributes of a process is essential to the analysis of the

process. These attributes include:

1. Basic information: including process name, description, and its author.

2. Importance of the process: core, critical, and supporting.
3. Value: value-added or non-value-added.
4. Cycle time: the mean, variance, and distribution of the cycle time.
5. Cost: Unit cost of each primary output unit.
6. Problem/Opportunity: Major problems and opportunities challenging the
process.
198 BPR Methodologies

Process Modeling Methods

Processes interact with other objects in the system. They are represented as
relationships. For example, a process can have outputs, inputs, and controls. A
process can also be decomposed into sub-processes. Sometimes people referring to
process at different levels of abstraction may use terms such as function, activity,
and task. Dependencies among processes are represented in a process dependency
diagram or in a process chain diagram.

Business process methods are designed to capture the relationships of a process

with other objects in the system. To model processes, Harrington (1991) suggested
using more traditional diagramming techniques often employed by industrial
engineers, including ANSI standard flowcharts, Functional Process Flowcharts,
functional time-line flowcharts, and geographic flowcharts.

Functional Process Flowchart

The most commonly used process modeling method is Functional Process

Flowchart, an example of which is depicted in Figure 3. One major advantage of
such chart is that it illustrates which organizational unit is responsible for a sub-
process and thereby helps business re-engineers identify crossing of organizational
boundaries which may cause major breakdown of a business process. Another
advantage of the Functional Process Flowchart is that, because it is commonly used
by many organizations to document workflow and procedures, little training is
required for people to create and evaluate the process models. Some companies
display process models on a big conference-room wall and invite employees who
are involved to "brown bag" sessions to evaluate the models and to suggest ways to
redesign the process. Processing time and cycle time of each activity (sub-process)
can be used to identify opportunities for improvement (cycle time = processing
time + waiting time). The lower the ratio of processing time divided by cycle time,
the better the chance to improve overall cycle time of the business process.
BPR Methodologies 199

P
A R
C 0 C
T C Y
I E C
Customer Credit v s L
Customer Inventory Shipping I s E
Service Checking T
Y Q) Q)

rt
( Begin)- HEnter~
Order
1 1 1
Credi 2 0.1 4
3 0.2 1
No
4 ... ...
Ye
...
Order
Update
Processing I
Inventory I
I II Waitfor)
-.
•I shipping,

II Ship
(End J order I
Figure 3: A Sample Functional Process Flowchart.

IDEFO

Another popular business process modeling technique used in practice is IDEFO

(Marca and McGowan, 1988), which has been adopted as a standard for process
modeling in the US Department of Defense and other agencies of the federal
government.

A system can be modeled as an interrelated set of IDEFO diagrams, texts, and

glossaries. Diagrams are the major components of an IDEFO model. The highest-
level IDEFO diagram, called the AO diagram, represents the whole system. An AO
diagram has only one box and is annotated by purpose and viewpoint. The purpose
of a system's IDEF model is to answer questions about the system; that is the
reason the model is developed. For example, the purpose of an order processing
system could be "Identify the business processes in the order processing function
area in order to streamline and simplify the business processes." A system can be
described from several perspectives (i.e., that of a person or an organizational
unit). An IDEFO should be developed from a single perspective that is the called
the viewpoint of the model.
200 BPR Methodologies

Boxes in IDEFO represent functions, activities, or processes of a system. A

process can be decomposed into a detailed IDEF diagram as shown in Figure 4.
Arrows represent collections of things such as objects and data that are
interconnections among boxes. Arrows represent how boxes influence or constrain
each other. A box can send its output to another function for further
transformation or provide a control that governs what another function must
perform. The side of the box at which an arrow enters or leaves determines the role
of an arrow (i.e., a thing) related to the box. Such a role is called ICOM (an
acronym that stands for input, control, output, and mechanism). The left side of a
box is reserved for inputs, the top is reserved for controls, the right side is reserved
for outputs, and the bottom is reserved for mechanisms. A generic IDEFO function
or activity can be described as: "Inputs are transformed by the function into
outputs according to controls, using a mechanism. "

The input and output reveal WHAT is done by the function. The control
explains WHY the function is performed. The mechanism represents HOW the
function is done and with what resources. IDEFO requires that 3-6 boxes appear on
anyone diagram except the AO diagram (i.e., the highest-level system diagram).
These requirements keep the diagrams comprehensible. IDEFO tends to be used as
a physical model because it can describe the implementation mechanism of systems
functions. However, if only the inputs, outputs, and controls of the systems
functions are considered, IDEFO can be used to provide a logical (i.e., essential)
model of the system. IDEFO can be used to show not only data flows, but also
material flows. It represents not only the process aspect, but also the control aspect
of a system. However, the definition of control in IDEFO is much broader than the
control flow and control process used in the real-time Data Flow Diagram.

Role Activity Diagram (RAD)

The RAD method represents roles, actIVItIes, and goals, as well as their
interactions. Decision making, sequencing, and concurrent activity can be
represented. The role is similar to Function Unit or Positions. Goals define states
to be reached (i.e., immediate or final states of a process). However, other than the
differences of graphical notations between a RAD and a Functional Process
Flowchart, the major improvement of a RAD over a Functional Process Flowchart
is its explicit representation of the concurrency of activities. RADitor developed by
Co-ordination Systems Ltd. supports RAD (Jennison. 1995).

TeamFlow from eMF represents an extended version of Functional Process

Flowcharting and is depicted in Figure 5. It is probably easier to understand than
RAD. Several enhancements include:

1. Roles (including organization unit and job title) are represented in a

hierarchical format at the top of this figure.
BPR Methodologies 201

C1

GENERAL

I
The diagram AO Is
the "parent" of the
dlagramA4.

DETAILED

Figure 4: A Set of Decomposed IDEFO Diagrams

2. Goals (i.e., deliverables or documents) can be shown explicitly on the diagram

as documentation icons.
3. A task assigned to a cross-functional area team can be shown as boxes
connected by dotted lines.
4. Decisions are shown as diamond icons.

Object-Oriented Method

Object-oriented methods have been proposed as a modeling technique for

business process modeling [(Wang, 1994); (Jacobson, et aI., 1994); (Taylor,
1995)). Although it is theoretically feasible, there is as yet no practical evidence
for its successful use in practice.
202 BPR Methodologies

f! TedmFlow 4 INEWPHOD TMF New PlOducl Developmenl P,oq.dm) (llIJI~E:J

Mark.ling
President I--,.-----,-----.-------l'------,---r---,.---I
er CEO Mfg
Support
Control

Figure 5. An Extended Functional Process Flowchart in TeamFlow

0-0 process model (Wang, 1994) is an integration of Object Model in Object

Modeling Technique (OMT) (Rumbaugh, et aI., 1991) with Functional Process
Flowchart. It captures additional information about process. Many people argue
that 0-0 modeling may reduce the semantic gap between process in the real world
and process in the abstract (Jacobson, et aI., 1994). However, the abstraction
through class hierarchy and the encapsulation of data inside methods of a class can
be difficult for BPR teams to understand. Use cases and interaction diagrams
(Jacobson, et aI., 1994) can be very useful in defining the flow of business events.
However, the interaction diagram can be viewed as a variation of a Functional
Process Flowchart.

Data Flow Diagram

Some people use Data Flow Diagram to define business processes (Johansson,
et aI., 1993). When DFD diagrams are used to analyze and design information
systems, the "process" becomes data processing activities. Other business activities
are not modeled directly in DFD. For example, when moving a piece of WIP
(work-in-progress), the moving activity should be represented as a process. But in
a DFD, only the corresponding data processing activity called "create new moving
slip" will be represented. Looking closely at a business process model and
BPR Methodologies 203

corresponding DFD model, one can see that they are almost mirror images of one
another. In our experience, business users and managers who are the primary
participants in BPR project can more effectively identify business processes
intuitively.

Selection ofProcess Modeling Methods

We have developed the following criteria for selecting business process

modeling methods. They should:

1. Be easy to learn by BPR teams who use them, and they should be intuitive,
easy for their intended end users to understand.
2. Capture all the necessary static and dynamic information of a business process
in a structured format so that the process models also can be further analyzed.
3. Support decomposition of a process into sub-processes each of which can
represent a sub-process at the proper level of abstraction.
4. Have computer-aided BPR software tools to support the drawing,
documentation, analysis, and storage of captured models. These BPR tools
can be integrated with other BPR tools.
There are several other process modeling methods that are less rigorous but
more intuitive than IDEFO. In our experiences, some organizations have a
tendency to over-analyze an existing system and therefore get stuck in the analysis
phase of the project (i.e., analysis paralysis) from which they are never able to
move on. The objectives of using business process modeling tools are: (1) to help
the BPR team obtain a holistic view of the process under study, (2) to identify areas
for improvement, and (3) to visualize the impacts and implications of new
processes. Therefore, the process should be modeled only at a level of detail
sufficient to achieve these objectives.

Analyzing Business Processes

A process model developed using methods such as IDEFO is a static model. It

may give a BPR team a holistic view of what a process is about and can provide
some qualitative and quantitative information about the process. It relies on BPR
team members' intuition and expertise in identifying opportunities for
improvement. More rigorous analysis of process cost or performance can be done
using activity-based costing or process simulation. We will also discuss change
management as a technique that may help BPR teams to examine all the human
and organizational factors surrounding a reengineered process.
204 BPR Methodologies

Activity-Based Costing (ABC)

ABC is a technique that measures the cost of activities. Costs that are generally
treated as overhead are allocated to activities identified in the process model. ABC
can provide insight into overhead -- the fast-growing and least visible element of
cost (Brimson, 1991). ABC is a very useful tool when cost saving is the major
goal of a BPR project.

According to the CIM Process Improvement Methodology (D. Appleton Co.,

1993), there are five steps in conducting ABC:

1. Analyze activities: This step is typically done during the development of

process models. A bill of activities (i.e., a decomposition of processes) is
defined during this step.
2. Gather costs: Collecting costs could be the most difficult aspect of conducting
ABC because of lack of historical data for existing activities. The overhead
cost of producing products or delivering service often represents a larger
percentage of total costs than material, labor, or machinery.
3. Trace costs to activities: Cost is traced to an activity based on the charges for
each activity and the dominance relationship described in IDEFO diagrams.
Resources used by activities, and hence their costs, are traced to activities.
The total input cost of each secondary activity is allocated to the primary
activities it supports. Total input cost for each activity can be calculated at this
stage.
4. Establish output measures: Each activity may have more than one output. One
primary output must be identified and it should be quantifiable. The unit cost
of an activity is calculated by dividing the total input cost of the activity by its
primary output volume.
5. Analyze costs: Cost analysts can use cost driver analysis to identify activities
or factors that influence the cost and performance of other activities. The
cause for high cost should be treated at its source (Brimson, 1991). Cost data
can be analyzed based on cost elements (i.e., labor, material, service, and
supplier) in order to compare alternative designs to the baseline. Non-value-
added activities are targets for elimination or improvement.
A process decomposition, called Bill of Activities, is required in the ABC
method. The data collection of a very detailed ABC model can be too time-
consuming. ABC does not pay attention to values added by these activities in its
analysis. One potential and major pitfall when using ABC to analyze processes is
that new processes or new products always tend to cost more than the analysis
generated by traditional cost accounting. One should take into consideration the
learning curve when applying ABC; otherwise, all the new initiatives might be
cancelled as a result of ABC analysis.
BPR Methodologies 205

Process Simulation

Dynamic features of a process model must be analyzed to ensure that the newly
designed process can meet performance standards. "What if?" questions related to
process performance may be asked. For example, "What is the cycle time of the
overall process if all the non-value-added activities have been eliminated?"
Discrete event simulation or dynamic simulation can be used in analyzing process
models. Senge and Sterman (1991) have used system dynamic simulation models
in assisting Hanover Insurance to understand and redesign its claim management
process. The strength of a systems dynamic model is that it helps managers
understand critical concepts such as delays, feedback loops, and cause-effect as
major factors in a system and also helps managers form a mental model about the
overall system and its dynamic behaviors (Senge, 1990).

Simulation tools such iThink (Stevenson, 1993) and SIMPROCESS (CACI,

1992) are useful in analyzing the dynamic characteristics of a process. These tools
can be used to identify the bottleneck of an existing process or a newly designed
process. Some process models developed in a static business process modeling tool
can be exported to a process simulation tool.

Change Management

The dramatic transformation caused by BPR initiation requires that the BPR
project be handled from a change management perspective. The basic philosophy
of change has been discussed in the Book of Change (I-Ching), which suggests that
one should be aware of where others stand in a given situation (price Waterhouse,
1995). There are several key concepts in the Book of Change that may improve
management of change:

1. Trends: Understanding of social, technology, market, and culture trends may

help in defining customers, products, or services of the future and, therefore,
what changes are necessary in the future. Sensing trends before a paradigm
has shifted may help in making proactive moves that anticipate changes.
2. Timing: The introduction of change should be properly timed. Pushing a
change initiative too early before there is enough support and awareness of the
need for change can be fatal. However, waiting too long is not an option in
today's highly competitive and fast-changing world.
3. Positioning: Stakeholder analysis may help BPR teams understand the
positions and assumptions of various stakeholders. The positions and actions
taken by process owners and BPR sponsors as well as how they communicate
BPR initiatives to others at different stages of BPR projects can determine how
various stakeholders may respond to change.
206 BPR Methodologies

BPR initiatives change not only business processes, but also other dimensions of
an organization, including: job skills, organization structures, performance
measures and rewarding systems, as well as values and organizational culture
(Hammer and Champy, 1993). A BPR team should proactively tackle these
dimensions during the process redesign and implementation phases. Focusing only
on process dimension and ignoring others will make the successful implementation
of the new process difficult. All these dimensions are inter-related. Process
change requires new job skills from people assigned to the process. New cross-
functional process flow may demand some structural change within the
organization.

It is our observation that the most important dimension is the performance

measure and the reward system associated with it. People impacted by the BPR
initiatives will always ask "What is in it for me?" It is naive to assume that people
will change for the good of the enterprise (price Waterhouse, 1995). However, the
reward should not be limited to money; career growth and satisfying working
environments are equally important.

Performance measures to direct people's energy toward the desired outcomes

should be designed into the new process. The measures should be clearly defined
and easy to calibrate. The measures should reflect a balanced view of the effects of
cost, quality, and speed on business processes. In addition, the new process vision
and strategy should be translated into a balanced scorecard covering such areas as
customer relations, internal business processes and finance, as well as learning and
growth (Kaplan and Norton, 1996). Metrics must be designed to measure business
objectives of new processes. Goals must be set and initiatives taken to achieve the
designated targets must be launched as part of the BPR project. Learning and
growth is an often-neglected area, so metrics that encourage learning and growth
should be put in place to make the change sustainable.

It takes time and incentive to foster a new organizational culture. Positive

measures and rewards are the incentive to create and change an organization
culture toward one that emphasizes more innovation, empowerment, and self-
motivation. At the beginning of a BPR project, a culture audit may be helpful to
identify potential organizational and human barriers (Stoddard, 1992). Proper
actions should be taken in the redesign and implementation stages to address these
issues. A study has found that the more in-depth the redesign of each dimension
and the broader the scope of the process (cross-functional process), the better
bottom-line return a BPR project may generate (Hall, et aI., 1993). All these
dimensions (process, job skill, organization structure, performance measures and
reward system, and organizational culture and value) are levers of change. BPR
teams should also incorporate markets and customers, products and services, as
well technologies as additional change levers (Price Waterhouse, 1995). Change
BPR Methodologies 207

management techniques should be considered as an integral part of the BPR

methodology.

A Framework of Applying BPR Methods and Tools in Business

Reengineering

Developing a business process model is a user-driven and team-based effort.

Once a process to be reengineered has been defined, a set of methods and tools can
be used to support the development of business process models. On the basis of our
experience in conducting BPR projects [(Chen and Sibley, 1992); (Chen, et aI.,
1992)], we have developed a framework using software tools for business
reengineering, particularly for process modeling and analysis. The framework is
depicted in Figure 6.

cost and
performance data
compared to the
baseline
-1 Analyze the I
activity costs of -
the process

+
-
activity

-
cost data ABC Tool
In fonmtion
of a - (IDEFCost, Easy ABC)
Elicit Construct!
I
Tl
process
sem-formal revise ~~ormancel Analyze the
process .."t-formll static business
::=0 ~ I
dynamcs of
and data
models
process models the process I
+
t Pro. Modtling Tools
«(DEFine, BOF,
Design/IDEF)
I Simulation Tool
(SIMPROCESS, iThink)
Model Elicitation Tools
(GroupSystems V)
L Construct!
J finolized
process
model Construct formal
Tafget
information
system
revise ~ IS models & generated
8emi.fonnaf~ business data generate ~
data model models information

t
systems

Data Modeling Tools CASE & worktow Mgm!. Tools

(ERWin, BDF) (IEF,ADW)

Figure 6: A Framework for Integrating BPR Methods and Tools

Since no one person in a company is likely to have complete knowledge of

existing process or be able to envision new processes, a collaborative effort to
create a shared mental model of the business process model is needed. A group
decision support system (GDSS) can be used to support process definition and
redesign meetings by assisting the elicitation of semi-formal process models (Liou
and Chen, 1994). Semi-formal process models elicited in this way can be formally
represented as business process models using methods such as IDEFO. The cost
data and the bill of activities (i.e., a decomposition of the process) can feed data
208 BPR Methodologies

into activity-based costing (ABC) tools to analyze the costs of an existing process
or a redesigned new process. Performance data such as input volume and
frequency, as well as process cycle time can feed into simulation tools in order to
analyze the dynamic characteristics of the process. As an example of tool
integration, IDEFine from Wizdom can be integrated with its own IDEFCost for
ABC analysis and with CACI's SIMPROCESS for discrete event simulation
(CACI, 1992).

The cost and performance data produced by ABC tools and simulation tools can
be used to compare new process models with the baseline model. Design of the
new process may be revised, and then re-evaluated with ABC tools and simulation
tools until a finalized process model is determined. A BPR project is usually
followed by the development of an information system to support the new process.
The business process model can be exported to a computer-aided software
engineering (CASE) tool or Work Flow Management Software tool in order to
construct information systems models and generate target systems.

Conclusions

BPR has passed the hype phase and is becoming one of the approaches to bringing
about changes to organizations. In this paper, we have presented a meta-model
for BPR methodology and reviewed several existing methodologies. We have
discussed the BPR-LC methodology, which has been used for training more than
1,000 BPR practitioners for the last four years. Several process modeling and
analysis methods that can be used in BPR projects have been discussed. We have
also developed a framework for using methods and tools in modeling and
analyzing business processes. Currently, we are gathering examples of successful
BPR efforts and are planning to develop an expert system that can recognize
patterns of business processes and can suggest ideas for process improvement or IT
deployment.

References

Brimson, James A., Activity Accounting: An ActiVity-Based Costing Approach,

New York: John Wiley & Sons, Inc., 1991.

CACI, A Quick Look at SIMFACTORY JJ.5ISIMPROCESS, CACI, Products Co.,

1992.

Champy, James, Reengineering Management: The Mandate for New Leadership.

New York: HarperCollins Publishers, Inc., 1994.
BPR Methodologies 209

Chen M. and Edgar H. Sibley, Using IDEFO in Functional Economic Analysis,

Working Paper, George Mason University, VA: Fairfax, 1992.

Chen, M., P. Evans, and c.L. Beaulieu, A Case Study of Using Group Decision
Support Systems in the Public Sector, Journal of Information Technology
Management, Vol. 3, #2 (1992), 7-13.

Coopers & Lybrand, BreakPoint BPR: Business Process Reengineering

Methodology - Pocket GUide, 1994.

D. Appleton Co., Corporate Information Management (CIM) Process Improvement

Methodology for DoD Functional Managers, 2 nd edition, revised and expanded,
D. Appleton Company, 1993.

Davenport, Thomas H., Process Innovation: Reengineering Work through

Information Technology, Boston: Harvard Business School Press, 1993.

Davenport, Thomas H. and Jane Linder, Rank Xerox U.K. (A), Harvard Business
School case #9-192-071, 1991.

Davenport, Thomas H. and James E. Short, The New Industrial Engineering:

Information Technology and Business Process Redesign, Sloan Management
Review, (Summer, 1990), 11-27.

Deloitte & Touche, Leading Trends in Information Services: Deloitte & Touche
Information Technology Consulting Services Fifth Annual Survey of North
American CIOs-1993, Deloitte & Touche Information Technology Consulting
Services, 1993.

Hammer, Michael, Reengineering Work: Don't Automate, Obliterate, Harvard

Business ReView, (July-August, 1990).

Hammer, Michael, "Making Reengineering Happen," Reengineering: The

Implementation Perspectives (Course Materials), The Center of Reengineering
Leadership, August 1991.

Hammer, Michael and James Champy, Reengineering the Corporation: A

Manifesto for Business Revolution, New York: HarperCollins Publishers, Inc.,
1993.

Harrington, James H., Business Process Improvement: The Breakthrough Strategy

for Total Quality, Productivity, and Competitiveness, New York: McGraw-Hill
Inc., 1991.
210 BPR Methodologies

Hall, G., 1. Rosenthal, and 1. Wade, How to Make Reengineering Really Work,
Harvard Business Review, (November-December, 1993), 119-131.

Jacobson, Ivar, Maria Ericsson, and Agneta Jacobson, The Object Advantage:
Business Process Reengineering with Object Technology, Workingham, UK:
Addison Wesley, 1994.

Jennison, Leslie, Some Tools for Business Re-Engineering, in Kathy Spurr, et al.
(Eds.) Software Assistance for Business Re-Engineering, Chichester: John
Wiley & Sons, 1995, 198-224.

Johansson, Henry 1., Patrick McHugh, and William A. Wheeler, III, Business
Process Reengineering: BreakPoint Strategies for Market Dominance,
Chichester: John Wiley, 1993.

Kaplan, S. Robert and P. David Norton, The Balanced Scorecard, Boston: Harvard
Business School Press, 1996.

Liou, Irene Y. and Minder Chen, Using Group Support Systems and Joint
Application Development for Requirements Specification, Journal ofMIS, Vol.
10, #3 (Winter, 1993-1994), 25-41.

Manganelli, R. L. and M.M. Klein, The Reengineering Handbook, AMACOM,

September 1994.

Martin, James, The Great Transition: Using the Seven Disciplines of Enterprise
Engineering to Align People. Technology. and Strategy, AMACOM, 1995.

Marca, David and Clement L. McGowan, IDEFO/SADT Business Process and

Enterprise Modeling, Eclectic Solutions Co., 1988.

Moad, 1., Does Reengineering Really Work? Datamation, August 1, 1993, 22-24,
28.

Price Waterhouse, Better Change: Best Practices for Transforming Your

Organization, The Price Waterhouse Change Integration Team, Irwin, 1995.

Rumbaugh, 1., et aI., Object Oriented Modeling and Design, Englewood Cliffs:
Prentice Hall, 1991.

Robson, George D., Continuous Process Improvement: Simplifying Work Flow

Systems, New York: Free Press, 1991.
BPR Methodologies 211

Senge, Peter, M., The Fifth Discipline: The Art & Practice of the Learning
Organization, New York: Doubleday, 1990.

Senge, Peter, M. and John D. Stennan, Systems Thinking and Organizational

Learning: Acting Locally and Thinking Globally in the Organization of the
Future, in T. Kochan and M Useem (Eds.), Transforming Organizations,
Oxford: Oxford University Press, 1991.

Stevenson, Richard, Strategic Business Process Engineering: A Systems Thinking

Approach Using iThink, in Kathy Spurr, et al. (Eds.) Software Assistance for
Business Re-Engineering, Chichester: John Wiley & Sons, 99-118.

Stoddard, Donna, Capital Holding Corporation - Reengineering the Direct

Response Group, Harvard Business School case # 9-192-001,1992.

Taylor, David, Business Engineering with Object Technology, John Wiley & Sons,
Inc., 1995.

Violino, Bob, Measuring Return on Investment, Information Week, June 30, 1997,
36-44.

Wang, Shouhong, 00 Modeling of Business Processes. Information Systems

Management, (Spring, 1994),36-43.