Você está na página 1de 27

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

Change Management BPR ISO9000 Business Process Improvement


Workflow Implementation I M PERP
L E M EEFQM
N T I NFinancial
G 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
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 EFQM Financial Modelling TQM System Integration
Activity Based Costing approach (ABC) Business Contingency Planning ERP Strategy Planning
A balanced

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
Advanced
SAP EFQM Financial Modelling TQM System Integration Workflow Implementation
performance

Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP
Change Management BPR ISO9000 Business Process Improvement
Workflow Implementation
Flexibility 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 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
Implementing Business Process Re-engineering

Contents

1.0 Introduction 1
1.1 Methodology versus Intuition 1
1.2 What Does a Methodology Offer ? 2
1.3 Problems with Methodologies 3
1.4 A Framework for Implementation 4
2.0 Identifying Processes for Redesign 5
3.0 Process Visualisation 8
4.0 Understanding Existing Processes 14
5.0 Redesigning New Processes 16
6.0 The Structure of Re-engineering Teams 19
6.1 The Re-engineers 20
6.2 The Insiders 21
6.3 The Champion 21
6.4 The Public Relations Person 21
7.0 Conclusion 21

Tables

Table 1: Two Re-engineering Frameworks 5


Table 2: Common Symptoms of Process Distress 6
Table 3: Davenport’s Method for Selecting Processes for Redesign 6
Table 4: Davenport’s Method for Process Visualisation 9
Table 5: Davenport’s Method for Understanding the Existing Process 15
Table 6: Process Methods Overview 16
Table 7: Davenport’s Method for Redesigning the New Process 17
Table 8: Level of Process Design 17

Figures

Figure 1: Business Vision, Strategy and Process Visualisation


Hierarchy 9
Figure 2: The Visioning Process 12

Copyright© CASEwise 1999


NOTE: REVERSE OF
CONTENTS IS BLANK
Implementing Business Process Re-engineering

Implementing
Business Process Re-engineering
R.F. Pearman

1.0 Introduction

Creating the new enterprise involves considerable change in virtually everything to do with
people’s working lives. Rather than fixing the old, we set out to create the new. There is
a fundamental transformation occuring in business - in terms of its structure, processes,
people, and technology - as described in the first part of this series of white papers; "The
Theory of Business Process Re-engineering".

The primary objective of this white paper (part 2) is to examine how to go about re-
engineering business processes. Research in this area reveals that papers that actually deal
with radical redesign are more difficult to find than papers that merely encourage the use
1
Lorenz, C., (1993), of BPR. It is far easier to be converted to a new religion than to practise it1.
“Management: Uphill Struggle
to Become ‘Horizontal’”,
This white paper begins with a discussion of the two opposing views that currently exist,
Financial Times.
i.e. whether re-engineering should be conducted from a methodical or an intuitive view
point. We highlight the fact that it is difficult to assess the value of either approach because
2
Davenport, T., (1993), “Process there are numerous examples relating to the success of both techniques. Therefore, we
Innovation: Re-engineering
Work Through
discuss only two approaches, one proposed by Davenport (1993)2 and the other from
Information Technology”, Hammer and Champy (1993)3, which contrast the differences between methodology and
Harvard Business School Press. intuition.
3
Hammer, M., Champy, J.,
(1993) “Re-engineering the From these two approaches, we identify four steps that are of paramount importance in
Corporation: A manifesto for the re-engineering effort. We describe each step and compare the two practitioners'
Business Revolution”, Nicholas approaches.
Brealey Publishing.

A brief discussion on the structure of re-engineering teams follows. This supports the
analysis conducted in the third in this series of white papers, “Tools for Business Process Re-
engineering”, which identifies how the project team can use the CASEwise Corporate
Modeler software to support a re-engineering project.

1.1 Methodology versus Intuition

A number of approaches have been developed for business re-engineering. The most
hyped by far is that proposed by Michael Hammer and James Champy in their book, Re-
engineering the Corporation. They focus on defining the “hard” aspects of re-engineering
(i.e. process and enabling technology). The virtue of their book is its brevity, readability, and
clarity. The book explains the "nuts and bolts" of the re-engineering process and illustrates
them with case studies.

Copyright© CASEwise 1999


1
Implementing Business Process Re-engineering

Another book that provides a useful insight into the re-engineering effort is Process
Innovation (Davenport, 1993). This book does a better but less readable job of relating all
the soft and hard elements of re-engineering to each other.

The primary difference between the two is "methodology" versus "intuition". Some BPR
practitioners rely on a more intuitive approach, rejecting analysis in favour of what they see
as a "higher level understanding". People in this camp believe that over-attention to
4
Klien, M.M., (1994), current practices is an obstacle to breakthrough thinking4. They believe in starting with a
“Re-engineering
clean slate and rely on their imagination and experience. For instance, James Champy
Methodologies and Tools:
A Prescription for Enhancing states that re-engineering is "contextual" - i.e. it is a function of how an enterprise
Success”, Information behaves, of its belief systems, of its position in the marketplace, and of the character of its
Systems Management people. Therefore, it is absolutely impossible to have a structured approach.
Journal.

However, the methodologists, such as Davenport, argue that sitting down with a blank
piece of paper with no guidance on how to begin is dismaying. They observe that people
who use intuitive approaches, although frequently becoming enthusiastic proponents of
BPR, still end up not knowing how to do it.

Roy Thompson, Principal consultant with CASEwise with many years experience of practical
BPR projects in major corporations, states

“ BPR is itself a process, its steps can be easily described.


However, the techniques employed at each step of a project
are highly context sensitive which makes a BPR
initiative appear intuitive.


The main distinction between the two approaches is that intuitive tells you “where to go”
while methodological approaches tells you “what to do to get there”. The latter can be
further decomposed into prescriptive and descriptive. Descriptive simply tells you what to
do while prescriptive tells you how to do it.

1.2 What Does a Methodology Offer ?


5
Olle, T.W., Hagelstein, J., Olle et al (1991)5 define an information systems methodology as “a methodical approach
McDonald, I.G., Rolland, C., Sol,
to information systems planning, analysis, design, construction and evolution”, and
H.G., Van Assche, F.J.M.,
Verrijn-Stuart, A.A, (1991), characterise different methodologies primarily by their “steps” and “components” (or
“Information Systems deliverables). The key idea of a methodology is that it has some level of universality; it can
Methodologies - A Framework be applied or adapted to a variety of business domains4.
for Understanding”, 2nd
edition, Addision Wesley.
Simison (1994)6 observes that using a methodology is appealing for a number of reasons.
6
Simison, G. C., (1994), “ A Specifically, it:
Methodology for Business
Process Re-engineering?”, IFIP
Transactions.
• Introduces a minimum level of discipline into the task - the alternative to this is
summarised in the classic example where a project team starts coding from the outset
giving insufficient attention to analysis and design.

• Entails less effort and intellectual input than an intuitive approach.

Copyright© CASEwise 1999


2
Implementing Business Process Re-engineering

• Provides a means of codifying experience and ideas in a form which can be evaluated
and tested.

• Facilitates planning and monitoring. In particular, the use of the same methodology
from project to project allows metrics to be developed so that productivity can be
compared and projects monitored.

• Establishes clear definitions for each step and the deliverables. This enables users to
contract out individual tasks with confidence that there will be common
understanding of what the contractor is required to produce and what inputs will be
provided.

• Allows a standard set of skills to be identified and developed. There are obvious
benefits in skills acquired on one project to be identified and developed for future
projects.

• Is a prerequisite for the use of Computer-Aided Software Engineering (CASE) tools.

1.3 Problems with Methodologies

Apart from listing the advantages of the methodological approach, Simison (1994) observes
that the IT profession has been less enthusiastic and successful in its adoption of the
methodologies than might have been expected. This is consistent with the view of Hammer
3
Hammer, M., Champy, J., and Champy (1993)3. Furthermore, he states that the advantages outlined in the preceding
(1993) “Re-engineering the section have been generally well recognised at the management level, but implementation
Corporation: A manifesto for
has been poor. The reasons for this are as follows:
Business Revolution”, Nicholas
Brealey Publishing.
• Most methodologies do not reflect “best practice”. Some of the more advocated
methodologies are based on the view of how systems should be developed rather than
successful practical experience.

• Common methodologies for information systems conflict with practice in the


assumption that developers will work from “first principles”, treating each business
situation as if it were unique in all respects. Developers frequently draw on past
experience and assume a level of business knowledge that allows a specification to be
drafted which is often incomplete.

• There is a danger that we incorporate in a methodology only those tasks that are readily
incorporated. This can leave those that are not amenable to methodological treatment
outside and at risk of being ignored.

• The use of detailed methodologies stifles creativity. The problem is not so much that
methodologies do not support creativity, but that they fail to recognise and support
design, of which creativity is an important aspect. BPR is recognised as a design
process, requiring creativity, innovation and radical thinking. The risks to creativity of
attempting to prescribe and use a methodology for BPR include:

Copyright© CASEwise 1999


3
Implementing Business Process Re-engineering

• Stifling creativity by attempting to break creative tasks down into smaller stages thus
imposing rules that are not essential to meeting the overall objective.

• Focusing on peripheral tasks such as documentation of the current system because they
are more easily dealt with prescriptively than major design tasks.

• Encouraging BPR practitioners to focus on “compliance” with the methodology, which


can be achieved with deliverables of a given quality and form, rather than optimising
deliverables beyond the level required by the methodology.

In this white paper, both approaches are discussed providing an unbiased view as to which
approach should be taken when embarking on re-engineering. Furthermore, there are
difficulties associated with assessing the relative value and efficacy of intuitive and
methodological approaches to BPR as most of the reported case studies were of necessity
intuitive, because no methodologies existed at the time the projects were done. In fact, the
projects were recognised as BPR only after completion. At the time, they were
conceptualised as something else. Michael Hammer who named re-engineering,
recognised that some companies were obtaining extraordinary break-throughs in
performance improvement, and he identified the common elements in the “re-engineered”
solutions.

A second difficulty exists in assessing the effectiveness of different BPR methodologies. This
is because every consulting firm can provide references and examples of successful projects
using their preferred methods. In addition, it is estimated more than half of the firms
engaged in re-engineering projects do so without significant help from re-engineering
consultants. It is often hard to define how successful some BPR efforts are, because the
sought-after improvement goals are usually never quantified. Hence, conclusions are based
on the project manager's understanding and insight into practical BPR and are supported
by a number of arguments.

1.4 A Framework for Implementation

The subsequent sections examine a number of implementation frameworks, focusing


primarily on those proposed by the well-known BPR practitioners, Hammer and Champy
(1993) and Davenport (1993). Table 1. highlights the work of these practitioners.

The reasons for focusing on these approaches are twofold. Firstly, they provide contrasting
work that shows the differences between the intuitive and methodological approaches.
Secondly, these consultants have been highly commended for their work in the area of
business process re-engineering.

The objective of the discussion and subsequent comparison is to provide the reader with a
more complete understanding of practical business re-engineering and ultimately to assess
the role and value of modelling and simulation in a BPR initiative.

Copyright© CASEwise 1999


4
Implementing Business Process Re-engineering

Table 1: Two Re-engineering Frameworks

It is possible to identify a common set of steps that are essential in the re-engineering
process. These points have been identified through a review of literature covering the
implementation of radical redesign. They are as follows:

• Identify Processes for Redesign


• Develop Process Visualisations
• Understand the Existing Processes
• Redesign New Processes

2.0 Identifying Processes for Redesign

The re-engineering effort must begin with a survey of the process landscape to identify
processes that are candidates for redesign. Both the overall listing of processes and the
focus on those requiring immediate redesign initiatives are crucial to the success of the re-
engineering effort. The selection process should aim to establish the boundaries of the
processes that are to be addressed, this enables the enterprise to focus on those most in
need of radical change.

The approach taken by Hammer and Champy suggests that an enterprise uses three criteria
to help them choose the processes that they should focus their attention on. They are:
Importance, Feasibility, and Dysfunction. Importance expresses how crucial a process is to
the enterprise, i.e. those processes that have the greatest impact on the enterprise's
customers. Feasibility looks at whether a process can be re-engineered from technological,
cultural or other concerns. Dysfunction looks at which processes are in the deepest trouble.

Copyright© CASEwise 1999


5
Implementing Business Process Re-engineering

Hammer and Champy primarily focus on dysfunction, listing the common symptoms of
processes in distress and their related diseases. Table 2 below summarises this.

Hammer & Champy (1993) Re-engineering the Corporation


Table 2: Common Symptoms of Process Distress

Having identified a common set of dysfunctions within enterprises, Hammer and Champy
stress that symptoms do not always point organisational physicians to the correct
diagnosis3. Sometimes the symptoms can be seriously misleading because the evidence
that a process is not working exists, but appears somewhere other than the obvious places.
3 So, while data may indicate that something is broken, it may not indicate accurately which
Hammer, M., Champy, J.,
process is not working well.
(1993) “Re-engineering the
Corporation: A manifesto for
Business Revolution”, Nicholas The three criteria outlined above must be used alongside the necessary business judgement
Brealey Publishing. to help make the right choices. They also emphasise the relation of the process to the
strategic direction of the company, i.e. does the process have a high impact on customer
satisfaction? Hammer and Champy do not provide specific walk-through steps that, when
implemented, will identify the necessary processes. However, they do provide a set of ideas
for how to tackle the problem, e.g. where to go, which is a primary characteristic of the
intuitive approach.

For the purpose of identifying those processes for redesign, Davenport (1993)2 provides a
more structured approach, which is slightly different to that of Hammer and Champy’s.
2
Davenport, T., (1993), “Process Instead of just offering ways of assessing processes, he describes ways in which the
Innovation: Re-engineering processes can be scoped and suggests how to actually identify the need in those processes.
Work Through Information
Technology”,
Harvard Business School Press. His key activities used for identifying processes for redesign are shown in Table 3.

Table 3: Davenport’s Method for Selecting Processes for Redesign

Copyright© CASEwise 1999


6
Implementing Business Process Re-engineering

The first step involves enumerating the major processes within the scope of study. This has
been considered a difficult task due to the lack of a widely accepted set of processes, or
even a method for determining the processes. In an enterprise, business planners have
described their enterprise as having anything up to 140 or more processes. Davenport
recommends representing the enterprise as having 10-20 processes, which he says is a
trade off between managing process interdependence and ensuring that process scope is
manageable. The fewer and broader the processes, the greater the possibility of innovation
through process integration, and the greater the problems of understanding and changing
the process. Processes can be enumerated using classification schemes described in the
white paper “The Theory of BPR” where processes, depending on their characteristics, are
divided into core processes, support processes and so on.

Secondly, using Davenport’s framework, one must determine the process boundaries.
Similar to enumerating processes, scoping processes is more like an art than a science.
7
Butler Cox, (1991), “The Role Butler Cox7 suggests the use of a task force, or alternatively, a management workshop.
of Information Technology in
Davenport recommends a set of questions as follows:
Transforming the Business”,
Research Report 79.
• When should the process owner’s concern with the process begin and end?

• When should process customer’s involvement begin and end?

• Where do sub-processes begin and end?

• Is the process fully embedded within another process?

• Are the performance benefits likely to result from combining the process with other
processes or sub-processes?

Answers to these questions should provide the team with enough information to make
valued judgements as to the process boundaries. Davenport further suggests that process
management is best viewed as an iterative activity in which subsequent redesign in one
process gives rise to a need to re-innovate, or at least modify others, e.g. redesigning a
process will effect the boundaries of other processes.

The third step involves assessing the strategic relevance of the processes that have been
identified and their boundaries determined. This allows the team to target the process in
question. Davenport identifies four criteria to aid process selection. These are:

• The processes centrality to the execution of the enterprise’s strategy. For instance, if an
enterprise business strategy focuses on improving relationships with customers, the
order management process would be a probable choice.

• The processes health, i.e. those processes that are consistently problematic.

• The processes qualification, i.e. where the primary goal is to gauge the cultural and
political climate of a target process.

• The processes manageability and scope.

Copyright© CASEwise 1999


7
Implementing Business Process Re-engineering

Davenport writes that enterprises he has studied spent several years travelling the process
re-engineering path, in the course of which most changed the number of processes that
they defined, as well as the boundaries of individual processes and the relative priorities as
candidates for innovation.

The preceding section has principally focused on describing the two high-level
approaches in terms of selecting processes for redesign. Davenport believes more in a
structured approach, while Hammer and Champy take a more “soft” approach, relying
mainly on the team’s insight and wisdom.

3.0 Process Visualisation

Achieving success in a re-engineering project requires a powerful vision of what the future
should be like. An effective vision is powerful because it can guide and motivate the BPR
team and the enterprise at large. A compelling vision must be clearly defined and then
effectively communicated.

The right BPR vision is difficult to create. It must strike a balance between platitude and a
8
Barrett, J.L., (1994), “Process laundry list, between providing too few and too many Goals8. In addition, a vision requires
Visualisation, Getting the
significant time, energy, and creative thought.
Vision Right is Key”,
Information Systems
Management. Process visualisation is implicitly related to the business strategy and the business vision.
This is illustrated in Figure 1. which shows exactly how the three aspects are related. The
business vision and business strategy set the process context for the development of the
process visualisation.

A business vision is a statement of the enterprise’s values and beliefs, its goals, and its
overall business philosophy. It is essential for providing a high level sense of direction and
statement of principle and acts as a useful input to the process visualisation. However, you
cannot use a business vision as a substitute for a process vision because it is too nebulous
and imprecise to guide the re-engineering effort. A business vision does not provide the
tangible direction that is required to focus, motivate, and inspire in the way that process
visualisation does.

Copyright© CASEwise 1999


8
Implementing Business Process Re-engineering

Figure 1: Business Vision, Strategy and Process Visualisation Hierarchy

Business strategy is essentially about understanding an enterprise’s markets, customers and


capabilities; identifying potential market capabilities; identifying potential market
opportunities and then allocating resources to take advantage of these opportunities to
improve the financial performance of the enterprise. The difference between business
strategy and process visualisation is that the former indicates to the enterprise what it must
do, while the latter tells how to do those things right. Business strategy is important when
determining which processes the BPR team should focus upon.

In order for process visualisation to be successful, it must not violate the tenets set forth by
the enterprise’s business vision and it must align with and support the enterprise’s business
9 strategy9. Each element business vision, business strategy and process visualisation are
Edwards, C., Peppard, J.W,
(1993), “Business Process interdependent, yet each must remain separate and distinct.
Re-design: Hype Hope or
Hypocrisy”, Journal of Davenport believes that in order to create an effective process visualisation the following
Information Technology.
steps should be undertaken. They are illustrated below in Table 4.

Table 4: Davenport’s Method for Process Visualisation

Step 1: Access business strategy for process direction


The first step, assessing existing business strategy, is concerned with the implementation of
strategy as a means to guide and inspire process redesign. Davenport lists seven criteria that
he believes an enterprise’s strategy should conform to. It should:

Copyright© CASEwise 1999


9
Implementing Business Process Re-engineering

• Be at least partially non-financial.


• Have components that are measurable.
• Focus an enterprise on specific aspects of the business where re-engineering can be
usefully applied.
• Be distinctive to an industry and company.
• Be inspirational.
• Be for the long-term.
• Employ a method that broadly focuses and addresses key tools for change.

Satisfying these criteria will increase the enterprise's chances of success in the search for
process redesign. However, care must be taken not to overemphasise any of these
requirements - strategy provides only an internal perspective in creating a process
visualisation.

Step 2: Consult process customers for process objectives


Secondly, customer inputs into process visualisation facilitates an understanding of the
customer’s perception of the process. Asking customers what they require of processes
serves multiple purposes. In the context of creating visions, the customer perspective
furnishes both ideas and objectives for process performance. Seeking customer input also
demonstrates a desire for a close relationship, although this input must be actually factored
into process designs to fully achieve this objective. Finally, new processes may require that
customers change their own behaviour for the process to be fully effective. Seeking input
at an early stage starts building customer commitment to the changes and lets customers
begin their own process transition.

Davenport (1993) suggests that a focus group to facilitate customer contact is the best way
to deal with the individual. He concludes that customer feedback should be iterative,
taking place throughout a re-engineering initiative so that customers can react to more
concrete process designs as they are developed.

Step 3: Benchmark for process performance


Davenport believes that the third step, process benchmarking, is an effective tool for
determining process objectives and identifying innovative process attributes. It enables
companies to look outside for alternative ways of designing processes and to break with an
inwardly focused mindset. He claims that experience has revealed that the most
appropriate benchmarks are “best practice” or “innovation” and he selects companies on
the basis of the performance of a particular process without regard to the industry.
Furthermore, he argues that benchmarking can identify realistic performance objectives
and targets for companies to match or surpass, and this information can be used during
innovation brainstorming workshops to fuel the redesign process.

4
Klien, M.M., (1994), However, this is a purely methodological approach. Most people in the intuitive camp
“Re-engineering
maintain that rules of thumb together with general information about what has been done
Methodologies and Tools:
A Prescription for Enhancing in other companies is more useful than formal benchmarking4. The reason why re-
Success”, engineers, armed with benchmarking data, are so dangerous is that as soon as the stimulus
Information Systems of re-engineering becomes discrepancies in benchmarking data, all the firms in the industry
Management Journal.
start converging to a point of no difference and thus no profit.

Copyright© CASEwise 1999


10
Implementing Business Process Re-engineering

The distinction between qualification and differentiation criteria help explain the danger,
i.e. qualification criteria are attributes every firm must have to enter a market, while
differentiation criteria give a firm an edge.

Step 4: Formulate process performance objectives


The fourth step in Davenport's approach involves formulating the process objectives. The
process objective is a statement that details the overall process goal, the specific type of
improvement desired, the numeric target for the innovation, and the time frame in which
the objectives are to be achieved. The process objective is created by questions, posed to
both the vision team and the key stakeholders, such as “what business objective is the
process supposed to accomplish?” The objectives should be derived from strategy and must
be quantifiable.

Examples of process objectives are:

• Double customer service satisfaction levels in two years

• Reduce processing costs for customer orders by 60% over three years

Step 5: Develop specific process attributes


The final step in Davenport’s method entails developing process attributes. Process
attributes simply constitute a vision of a process operation in a future state. They are highly
descriptive and non-quantitative, they address high-level process characteristics and specific
enablers. Process attributes are frequently considered as principles of process operation,
behaving as simple statements describing an enterprise’s philosophy and intent, regarding
process operations and can be an effective means of engaging senior management in
discussions about visions for new processes.

Examples of process attributes are:

• Link order management systems world-wide, but keep them local

• Create automated sales assistant tools for product information and pricing

• Offer direct shipments from manufacturing to customers

The process objectives and attributes described above are usually determined from an array
of activities, e.g. corporate strategy, overviews of IT and people and so on. This is
accomplished during visioning sessions at the beginning of a specific process initiative.

Copyright© CASEwise 1999


11
Implementing Business Process Re-engineering

Figure 2: The Visioning Process

A popular theme within re-engineering projects is to incorporate this visioning process into
a series of workshops. Figure 2. illustrates how these visioning sessions explore increasing
levels of detail about the vision at each step.

The earlier stages of the visioning process are dictated by the creation of objectives and
attributes. Once formulated, the workshops address the critical factors for the successful
implementation of the vision and any barriers that might stand in the way.

Hammer and Champy do not provide a concise definition of their process visualisation
techniques. This stems from their reasoning that re-engineering is contextual and no set
technique can be used all of the time. However, aspects of vision are reflected in their
beliefs that the re-engineering team should focus on customers to determine what the
customer’s real requirements are, i.e. what do they say they want and what do they really
need, and are the two different? Also, what problems do they have and what processes
do they perform with the output? Since the eventual goal of redesigning a process is to
create one that better meets customer needs and it is critical that the team truly
3
Hammer, M., Champy, J., understands these needs 3. In answering these questions and meeting these demands the
(1993) “Re-engineering the team has effectively created their vision; a vision of what the future should be like.
Corporation: A manifesto for
Business Revolution”, Nicholas
Brealey Publishing. Furthermore, they believe that this should be done not by asking the customers what those
needs are, but by understanding the customers' underlying goals and problems. This
understanding cannot be acquired by asking the customers what they want because they
will tend to answer from their own unexpanded mindset.

Hammer and Champy decided that a better way to acquire information about what
customers do is to watch them do it. This will give team members an insight as to what is
important and what is not. From this the team can determine ways in which the process
can better serve the customer. The goal is to understand the "what" and the "why", not
the "how", of the process. Hence, an effective process visualisation will result.

Copyright© CASEwise 1999


12
Implementing Business Process Re-engineering

They also consider the use of process benchmarking as a means for looking at companies
that are doing something well and learning how to do it in order to emulate them.
However, they also point out that benchmarking can restrict the re-engineering team’s
thinking to what is already being done in its own industry sector. If the team is going to
benchmark, it should do so from the best in the world, not just the best in its industry.

8
Barrett, J.L., (1994), “Process Barrett (1994)8 also provides a method for developing a process visualisation. The approach
Visualisation, Getting the embraces the concepts described above and stresses the following:
Vision Right is Key”,
Information Systems
Management. • Maximising the collective creativity of the BPR team.

• Reaching a point where team members enthusiastically embrace their concept of the
future and then actively campaign on its behalf to the rest of the enterprise.

• Establishing a learning laboratory to test and refine the team's proposed process
visualisation in a controlled environment.

He divides the development methodology into a number of stages. Firstly, the incubation
stage is where BPR teams work through a structured set of knowledge-building activities
prior to embarking on process visualisation. This enables the team to achieve an effective
process visualisation. The right people must be selected - i.e. those possessing suitable
qualities - and the team should examine the business process targeted for re-engineering
as it currently operates. The objective here is to identify the key leverage points of the
process and then focus on these for significant performance improvement. In addition to
the points highlighted above, BPR teams should analyse various examples of best practice
for the particular business process.

Secondly, the targeted brainstorming phase is when the BPR team actually construct, over
time, the process visualisation by creating both the narrative description and the graphical
depiction of the future process. This is done through a series of targeted brainstorming
sessions. Note that the narrative simply contains explanations as to why we must change
and what we must do. Barrett outlines a number of techniques to facilitate the kind of
breakthrough thinking that successful process visualisation requires. They include the year
2010 approach, where the BPR team visualises what the targeted process will be like in the
year 2010 and the ideal service approach, where the BPR team describe what would be
different if customers were thought of as partners.

The final phase is when the team has a sense of having accomplished a resounding victory.
This is known, according to Barrett, as the “eureka” phase. Here all the preparation and
work of the previous two phases comes together to form a process visualisation that the
team deeply believes in.

Copyright© CASEwise 1999


13
Implementing Business Process Re-engineering

4.0 Understanding Existing Processes

In the re-engineering effort there is disagreement surrounding the role of the existing
process. For instance, Hammer and Champy claim that the process should be understood,
but not in any great detail. Whereas, Davenport argues that time must be taken to
understand and document the existing process. Before discussing the reasons for the
difference, it is necessary to discuss each of the practitioners' views in detail.

Hammer and Champy believe that before a re-engineering team can proceed to redesign,
it must know something about the existing process, i.e. what it does, how well it performs
and the critical issues that govern its performance. The level of understanding is the crucial
point here. They believe that because the team’s goal is not to improve the existing process,
it does not need to analyse and document the process to expose all of its details. Their
observations suggest that the most frequently committed errors in re-engineering is that
the re-engineering team try to analyse a process in agonising detail rather than attempt to
just understand it. Rather, the team members require a high-level view that is just enough
to generate the intuition and insight necessary to create a totally new and superior design.

Although Hammer and Champy stress that detailed process analysis of a conventional sort
is useful to help persuade others in the enterprise that re-engineering is necessary, the task
is part of change management and re-engineering teams need to look for knowledge and
insight. They say that the best place for the team to start to understand an existing process
is usually at the customer end. This is because the eventual goal of redesigning a process
is to create a new one that better meets customer needs. Once the team establishes what
process the customer might need the next step is to figure out what the current process
provides.

Davenport’s studies contrast with this approach. He argues that not taking the time to
understand an existing process leaves the re-engineering team unable to establish the
benefit of adopting the new process. He lists four reasons why it is important to document
existing processes before proceeding with redesign.

• Understanding existing processes facilitates communication among participants in the


re-engineering initiative. Models and documentation of the current state allow for a
common understanding between the team.

• Documentation provides the means to migrate to a new process. It is an essential input


to migration and implementation planning. It is useful for understanding the
magnitude of anticipated change and the tasks required to move from the current
process to a new process.

• Recognising problems in an existing process can help ensure that they are not repeated
in the new process.

• Understanding of the current process provides a measure of the value of the proposed
redesign.

Copyright© CASEwise 1999


14
Implementing Business Process Re-engineering

Davenport’s analysis on existing processes goes as far as to produce a list of key activities in
understanding and improving existing processes. This is illustrated below in Table 5.

Table 5: Davenport’s Method for Understanding the Existing Process

The first step involves documenting the current process flow. He believes that describing
the process is central to the purpose of process communication and increases the likelihood
of process participants adopting a revolutionary process. The current process is then used
as a baseline comparison with the new process and thus should be assessed in terms of the
same criteria employed for the new design. The scope of the existing process should be the
same as that envisioned for the new process. Furthermore, the current process should be
measured on the specific performance objectives and assessed for the relative levels of
process attributes as identified in the process vision. This narrowing of the assessment task
helps reduce the time and effort required for the current process analysis. For example, if
the visioning activities for a new process yield cycle-time reduction and output quality
improvement as objectives, then these criteria should be the focus of current process
measurement activities. If the process attributes in the new vision involve a single level of
approval for customer transactions, the number of approvals required in the current process
should be known.

9 Edwards and Peppard (1993)9 believe that undertaking BPR demands an understanding not
Edwards, C., Peppard, J.W,
(1993), “Business Process only of the purpose of the process under review but also an understanding of the purposes
Re-design: Hype Hope or and methods of each of the processes at higher levels of granularity. For example, to
Hypocrisy”, Journal of redesign a process within a function demands an understanding of that function, as well
Information Technology.
as of the enterprise as a whole, the industry within which the enterprise competes, and
society in general. They argue that to redesign a process without reference to these higher
levels of granularity can result in suboptimality9.

Davenport further believes that improving the existing processes is a natural follow-on to
documenting them. The documentation usually reveals long-standing problems such as
bottlenecks, redundancies and unnecessary activities that have gone unrecognised. Many
companies engaged in re-engineering are actually coupling short-term improvement and
breakthrough innovation, using the documented information. This has been classified as a
“systematic approach” to re-engineering where performance improvements are
implemented in the short term, while re-engineering work proceeds in the medium and
long term.

Copyright© CASEwise 1999


15
Implementing Business Process Re-engineering

Davenport summarises the traditional approaches to process improvement, Table 6 shows


the difference between traditional approaches and radical redesign and shows why none
of the techniques are capable of achieving radical improvement. Secondly, it identifies tools
and techniques that are applicable and useful in the process improvement stage of the re-
engineering initiative.

Davenport (1993) Process Innovation: Re-engineering Work Through Information Technology


2 Table 6: Process Methods Overview 2
Davenport, T., (1993),
“Process Innovation:
Re-engineering Work Through There are two major differences in the approach offered by Davenport and Hammer and
Information Technology”, Champy. The first difference is the stage at which understanding occurs. Hammer and
Harvard Business School Press.
Champy believe that this understanding of what the process represents should come before
process visualisations are created. Hence, their reasons for believing that exposing all of the
processes details will affect the design of the new process. However, Davenport argues that
the existing process should be examined and documented following process visualisations.

Secondly, Davenport believes that process improvements in the short-term should precede
re-engineering work in the medium and long term. However, Hammer and Champy believe
in making radical changes and that the new process should have no basis in the old.

5.0 Redesigning New Processes

The design phase largely revolves around a group of creative people that review the
information collected in earlier phases of the initiative and synthesise it into a new process.
There are many techniques for facilitating the review process, but the success or failure of
the effort will be determined by the particular people who are gathered together. A
number of these techniques are discussed in this section.

Davenport states that key process stakeholders usually want to feel that their interests are
represented during this stage. This is in addition to the views of the main participants of
process identification and the visioning phases. The stakeholders that should be included
in the discussion are usually heads of key functions intersected by the process, key general
managers with operational responsibility for the process, suppliers and process customers,
both internal and external.

Copyright© CASEwise 1999


16
Implementing Business Process Re-engineering

Davenport’s rendition of the redesign session is much more detailed than that of Hammer
and Champy’s. Davenport’s analysis extends to discussing a migration strategy and
implementing new organisational structures and systems. Hammer and Champy specifically
discuss only re-designing the process. Furthermore, Hammer and Champy provide a set of
detailed examples which includes a great deal of information on how processes are
redesigned and implemented. However, in this section we shall limit the discussion to the
redesign session because other areas such as the new organisational structures are covered
in part one of this series of white papers “The Theory of Business Process Re-engineering".

Davenport (Table 7) lists his key activities in designing and prototyping a new process.

Table 7: Davenport’s Method for Redesigning the New Process

The first stage is to brainstorm the design alternatives. Design innovation is best
accomplished in a series of workshops, and brainstorming is an effective means of surfacing
creative process designs. Brainstorming is any group facilitation technique or practice that
encourages participation from all group members, regardless of their roles and relationships
within the enterprise. Emphasis should be placed on creativity and idea generation and a
non-judgmental atmosphere is essential. Davenport stresses that the objective of this
session is to develop creative but pragmatic new process designs, taking as input the earlier
stages of his re-engineering approach.

Davenport emphasises that it is often useful to define the new process in an iterative
fashion, with greater detail at each successive level. Table 8 below illustrates this.

Table 8: Level of Process Design

Copyright© CASEwise 1999


17
Implementing Business Process Re-engineering

To begin with a high-level flow of the overall process should be created. At the next level
of detail, each sub-process can be described with roughly the same thoroughness as was
used in describing the general process in the first iteration. Finally, each major activity
should be described in terms of such factors as who performs it, the information needed
to carry it out and so forth.

Davenport believes the next stage is to submit all of the design alternatives to feasibility
analysis to evaluate their relative benefits, costs, risks and time frames. The new design
must be compared in terms of structure, technology and organisation to fully understand
the implications of each alternative.

Furthermore, Davenport believes that following the selection of the preferred redesigned
process, a prototype to simulate and test its operation should be set up. This is an iterative
stage in which the fit between new process, structure, information technology and
organisation is refined.

Hammer and Champy's approach to this brainstorming session is slightly different to


Davenport’s. They propose a number of techniques for redesigning a specific process.
Questions such as “imagine only a single person were available to perform all the tasks
involved in building a product” how would they be likely to do it? What help would that
single worker need. How could technology lend a hand? Following through on answers
to these questions can get the redesign session moving.

Another technique that is used by Hammer and Champy is that of identifying and
annihilating assumptions. This technique was found to be useful in stimulating the re-
engineering team's thinking and works on the basis that assumptions are deeply held
beliefs that are built into almost every existing business process. An example of this is that
field salespeople are not allowed to set the terms of a sale. This is because of the
assumption that salespeople may put their own financial interests ahead of the company’s
in order to earn commission. A re-engineering team should attempt to turn these
assumptions on their heads or, alternatively, throw them away and then see where that
leaves the process they are redesigning.

The final technique used by Hammer and Champy for stimulating creativity is to harness
the disruptive power of Information Technology. Conventional business processes
sometimes reflect the limitations inherent in the pre-computer era because they were
designed on that basis. If we try to improve these processes we will still be constrained by
the same limitations. The re-engineering teams can break out of this bind by starting with
the capabilities of modern Information Technology. Assess what it allows to be done and
then determine if it helps you to redesign the process.

10 Cougar et al (1994)10, suggest an approach to enhance the creativity of re-engineering,


Cougar, J.D., Flynn, P. Hellyer,
D., (1994) “ Enhancing The which in turn, observations suggest, will help generate cost effective ideas. They proposed
Creativity of Re-engineering: a two-pronged approach:
Techniques for Making IS More
Creative”, Information
Systems Management. • Improvement of the environment for creativity and innovation
• Training in specific techniques for creativity generation and evaluation

Copyright© CASEwise 1999


18
Implementing Business Process Re-engineering

They extend their analysis specifying that the program should consist of two phases
evolving specific activities. Phase one comprises and teaches a number of creativity,
evaluation and implementation techniques. The workshop should contain both analytical
and intuitive creative generation and evaluation techniques, for example;
analogies/metaphors and problem reversal. Participants should be involved in exercises
using each of the techniques taught, in order for them to become familiar with their use
and how to apply them to Information Systems Design.

In phase two there is reinforcement of the concepts and principles learnt in the workshop.
This is done through monthly meetings for each department where the team can discuss
their experiences in the application of the techniques and test the degree to which the
environment for creativity has been enhanced. Reinforcement can be facilitated by use of
staff meetings where employees are asked to identify specific results of their creative
activity.

The techniques outlined above have proven to enhance the climate for creativity in a
systems development group in creating cost-effective ideas. Furthermore, employees that
have participated in creativity workshops stated that the program:

• Helped them to surface their creativity.

• Helped them to share ideas and be more open.

• Encouraged them to consider other approaches, not just continue to use established
methods.

• Helped them develop intuitive approaches and not rely only on the analytical.

• Improved group interaction, developed rapport.

• Helped integrate creativity as part of the daily job

For re-engineering to succeed it must be creative. The above techniques offer the means.

The discussion above has attempted to review some of the techniques that can be used to
enhance the generation of ideas from members of a re-engineering team. Once the team
has determined process visions and understood existing processes to an appropriate level
of detail they can then create a redesigned process that achieves the defined objectives.

6.0 The Structure of Re-engineering Teams

Business re-engineering is typically tackled with work teams from across the enterprise. The
team usually consists of a leader and representatives from the business units involved,
Information Systems, Quality Assurance, Human Resources and other key departments.
The leader usually is the “owner” of the process being addressed.

Copyright© CASEwise 1999


19
Implementing Business Process Re-engineering

In general, the particular personnel who are chosen and the amount of authority they are
given are critical factors in success of the re-engineering project. Furthermore, the re-
engineering “core” team must start small and remain small. Therefore, a prudent approach
is to find as few people with as many of the requisite cross-functional skills as you can. Five
to seven people should comprise the core team; teams in excess of ten should be avoided
because ten people rarely agree on anything.

Because the re-engineering team must be cross-functional, a balance of outsiders and


insiders must be selected as full-time, dedicated team members. Outsiders are people who
have not been involved with the enterprise, while insiders are people who have had recent
experience as a member of the enterprise. The core team members must be complemented
by two other individuals: a public relations person and a champion.

We should note that in addition to their skills, the way that the team members are
perceived is important. How the affected enterprise will view each member of the team is
a factor in team selection. The goal should be to select team members who have requisite
skills and will be able to gain acceptance from others in the current environment.

Because re-engineering projects are usually high-profile endeavours, the team members will
be judged constantly by the people within the enterprise. Therefore, the selection of team
members must be done so as to avoid negative personal perceptions. The insiders must be
individuals respected by most people at all levels of the enterprise from which they came.

6.1 The Re-engineers

Re-engineers will be management level people, but they must not be responsible for
managing people during the re-engineering project. They need the time and the freedom
to analyse and diagnose problems. Furthermore, an understanding of technology is
paramount. Here the people must be technically competent. The more experience they
have in information system integration, the better.

The skills described above can be classified as “hard”. These must be complemented by a
wide array of “soft” skills. For instance the re-engineer must be able to go to the factory
floor and relate to the workers and then must be able to go to the boardroom and present
the team’s findings in a way that the senior managers can understand. Moreover, these re-
engineers must be “thick skinned” in order to defend their ideas and conclusions and be
highly self-motivated.

Some of the re-engineers can be external consultants. Because the re-engineering discipline
is relatively new to many enterprises, augmenting the team with consultants will help to
speed things along and provide the needed experience.

Copyright© CASEwise 1999


20
Implementing Business Process Re-engineering

6.2 The Insiders

At least thirty per cent of the re-engineering team should comprise of employees who have
recently worked in the current environment. In dealing with the potential problems there
may be no quicker way to gain credibility than to have highly respected members of the
current enterprise involved in the effort.

6.3 The Champion

Within the context of leadership, a “champion” may be the most important “cog” in the
re-engineering team. This person will have the same traits as the re-engineer, i.e. drive,
motivation, good interpersonal skills and so on. The champion is responsible for leading
the re-engineering team, fighting political battles, removing obstacles and gathering
support from all levels of management.

6.4 The Public Relations Person

To complement the core team members it is necessary to have a PR person on the re-
engineering team. This person should be dedicated to spreading a positive message about
re-engineering and the benefits of the program in particular. The PR person must work to
create positive associations with the project in people’s minds.

7.0 Conclusion

The white paper on “The Theory of Business Process Re-engineering” described the
fundamental transformation that BPR produces, in terms of the enterprise's structure,
processes, technology and people. This white paper on “Implementing Business Process
Re-engineering” has focused on the practices that perform change, highlighting two
approaches to business process re-engineering that cur rently exist.

Firstly, arguments surrounding the adoption of methodology in re-engineering were stated.


For example, a methodology introduces a minimum set of disciplines into a task, but stifles
creativity, which is central to radical redesign. However, there is some debate about what
constitutes a methodology. Strictly speaking, both practitioners propose a methodology,
but one is more flexible than the other. In the view of the author, an Implementing method
is required to provide the re-engineering team with guidance in their increasingly difficult
task. Rather than revolve around tightly defined tasks, such as those prescribed by
Davenport, tasks should be loosely defined (the “soft” approach). This facilitates creativity
amongst the team; in other words, it is a more intuitive approach. Still, one must not lose
sight of the fact that both methods have proved extremely successful in their areas of
application.

Copyright© CASEwise 1999


21
Implementing Business Process Re-engineering

The steps taken should fit into those described in this white paper. Firstly, processes for
redesign must be selected. The approaches described to facilitate this stage are
conceptually the same, where processes that are consistently problematic are paid most
attention. Also, these processes are assessed on their strategic relevance, or importance
and then reviewed to determine feasibility in terms of culture etc.

The second and third steps involve developing process visualisations and understanding
existing processes. This is the point at which the two approaches differ the most. The main
distinction between the two approaches is that the intuitives believe the process needs only
to be understood on a high level of detail, from which effective visions can be drawn. They
believe the existing process should not be analysed in any great detail, since the new
process should have no basis on the old. However, the methodologists believe that the
existing system should be well documented following the development of visions.
Moreover, they argue the existing system should be improved in the short-term while re-
engineering work continues in the medium and long-term.

The final step of a re-engineering initiative before the new process is implemented is the
redesign session. As the two approaches indicate, this is usually accomplished through
intensive brainstorming sessions, applying a number of creativity techniques.

Finally, it is worth mentioning that it is extremely difficult to undertake radical redesign. The
approaches that do exist all claim considerable success. However their ability to discuss
their successes is followed by a reluctance to discuss failures. This makes assessment of the
value of these approaches extremely difficult.

In practice, the way re-engineering is conducted varies between the enterprises to which it
is applied. One must view these approaches only as a guide to a re-engineering project.
No two situations are identical.

Copyright© CASEwise 1999


22
NOTE: INSIDE BACK
COVER IS BLANK
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
CASEwise...
Modelling TQM System Integration
Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning
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 modellingModelling TQM System


software available Integration
for the Microsoft Windows market. Workflow Implementation
Strategy Planning Activity BasedModeler™
CASEwise's Corporate Costing provides aBusiness
(ABC)
software Contingency
common platform that Planning SAP
Change Management enables Finance,BPR ISO9000
Information Technology,Business
Human Resources,Process
and Business Improvement
Processes to be modelled, explored and understood in a totally integrated
Workflow Implementation ERP EFQMandFinancial Modelling TQM System Integration
holistic manner.
Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning
Business Process Improvement ISO9000 Change Management BPR
To compliment its modelling technology, CASEwise offers a full range of
professional services to ensure successful implementation. CASEwise
SAP EFQM FinancialProfessional
Modelling Services TQM SystemandIntegration
include education training, methodologyWorkflow Implementation
Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP
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.

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
Strategy Planning Activity Based Costing CASEwise(ABC) Business Contingency Planning SAP
www.casewise.com
Change Management BPR ISO9000 Business Process Improvement
EUROPE USA
Workflow Implementation ERP9–13EFQM
Station House Financial
Swiss Terrace Modelling
Reservoir TQMRoadSystem Integration
Place 1601 Trapelo
London NW6 4RR Waltham, MA 02451
Activity Based CostingTelephone:(ABC) Business
+44 (0)171 722 4000 Contingency
Telephone: Planning ERP Strategy Planning
+1 781.895.9900
Facsimile: +44 (0)171 722 4004 Facsimile: +1 781.895.9914
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

Você também pode gostar