The Hunt for

Reengineering
Opportunities
Intro
Processes, not organizations, are the object
of reengineering. Companies do not
reengineer their sales or manufacturing
departments; they reengineer the work
that the people in those departments do.
The confusion between organizational units
and processes as objects of reengineering
arises because departments, divisions, and
groups are familiar to people in business,
while processes are not

2
Intro
This topic illustrates how companies
identify their business processes, suggests
techniques for selecting the processes that
should be reengineered and the order of
their reengineering, and stresses the
importance of understanding specific
processes before attempting to redesign
them.

3
Intro
Processes in a company correspond to natural
business activities, but they are often
fragmented and obscured by the organizational
structures. Processes are invisible and
unnamed because people think about the
individual departments, not about the process
with which all of them are involved. Processes
also tend to be unmanaged such that people
are put in charge of the departments or work
units, but no one is given the responsibility for
getting the whole job - the process - done.

4
Intro
Processes can be given names that express their
beginning and end states. These names should
imply all the work that gets done between their
start and finish. Manufacturing, which sounds like
a department name, is better called the
procurement-to-shipment process.
Some other recurring processes and their state-
change names:
Product development: concept to prototype
Sales: prospect to order
Order fulfillment: order to payment
Service: inquiry to resolution

5
Intro
Just as companies have organization
charts, they can have business process
maps that give a picture of how work flows
through the company. A process map also
creates a vocabulary to help people
discuss reengineering.
Example see other notes

6
Choosing Processes to
Reengineer
Once processes are identified and mapped,
deciding which ones to reengineer and their
order is not trivial. No company may reengineer
all its high-level processes simultaneously.
Typically, companies use three criteria to make
their choices:
Dysfunction: Which processes are in deepest trouble?
Importance: Which processes have greatest impact
on customers?
Feasibility: Which of the company's processes are at
the moment most susceptible to successful redesign?

7
Broken Processes
In looking for dysfunction, the most obvious
processes to consider are those that a company's
executives already know are in trouble. The
evidence is everywhere and generally hard to miss.
A product development process that has not hatched a
new product in five years can safely be said to be broken.
If employees spend time typing data from a computer
printout into a computer whatever process they are
working on is probably broken.
If people's work cubicle walls and computer screen are
papered with Post-it notes reminding them to fix this or
look into that, the processes involved are probably broken.
Etc.

8
Broken Processes
The symptoms to look for in order to
identify dysfunctional process include the
following:
Extensive information exchange, data
redundancy and re-keying
Problem: Arbitrary fragmentation of a

natural process
Inventory, buffers, and other assets
Problem: System slack to cope with

uncertainty

9
Broken Processes
High ratio of checking and control to
value-adding
Problem: Fragmentation
Rework and iteration
Problem: Inadequate feedback along chains
Complexity, exceptions, and special cases
Problem: accumulation onto a simple base

10
Important Processes
Importance, or impact on outside customers, is the
second criterion to consider when deciding which of
the company's processes to reengineer and in what
order. Even processes that deliver their outputs to
customers inside the company may be of major
importance and value to outside customers.
However, companies can't simply ask their
customers directly which processes are most
important to them, because customers, even if they
are familiar with the process terminology, have no
reason to know in much detail the processes their
suppliers use

11
Important Processes
Customers are a good source of information
in comparing the relative importance of
various processes, however. Companies
can determine what issues their customers
care strongly about e.g. product cost, on-
time delivery, product features, and so on.
These issues then can be correlated with
the processes that most influence them as
an aid to creating a priority list of those
processes that need reconstruction.

12
Feasible Processes
Feasibility, entails considering a set of factors that
determine the likelihood that a particular
reengineering effort will succeed. One of these
factors is scope. Generally, the larger a process -
the more organizational units it involves - the
broader its scope. A greater payoff is possible
when a process larger in scope is reengineered, but
the likelihood of its success will be lower. Broad
scope means orchestrating more constituencies,
affecting more organizations, and involving more
managers who have their own agendas.

13
Feasible Processes
Similarly, high cost reduces feasibility. A
reengineering effort that requires major
investment in an information processing
system, for example, will encounter more
hurdles than one that does not.
The strength of the reengineering team and
the commitment of the process owner are
also factors to be considered in assessing
the feasibility of reengineering a particular
process.
14
Understanding
Processes
Once a process has been selected for
reengineering, a process owner
designated, and a team convened, the
next step is not redesignnot yet.
The reengineering team must understand
the current process. For example:
what it does
how well (or poorly) it performs
critical issues that govern its performance etc.

15
Understanding
Processes..
Since the team's goal is not to improve the
existing process, it does not need to analyze and
document the process to expose all of its details.
Rather, the team members require a high-level
view, just enough so that they have the intuition
and insight necessary to create a totally new
and superior design.
A common error in reengineering is that at this
stage reengineering teams try to analyze a
process in detail rather than attempt to
understand it.

16
Understanding
Processes..
The best place for reengineering team to
begin to understand a process is the
customer end.
What are the customers real requirements?
What do customers want and what do they
get?
What problem do they have?
What processes do they perform with the
output?

17
Understanding
Processes..
To understand customer requirements, the team
might move in and observe and/or actually work
with customers in their own environments.
Doing this is another way in which gaining
understanding differs from analysis. Interviews
can be used. What people tell analysts,
however, is what they think they should be
doing, what they happen to remember, or what
they've been told to say; they do not tell what
they actually do. What people do and what they
say they do are almost never the same.

18
Understanding
Processes..
Observation is better. Even better is
participation

19
Understanding
Processes..
Another tool that is available to reengineering
teams is benchmarking. Benchmarking
means looking for the companies that are
doing something best and learning how they
do it in order to emulate them. The problem
with benchmarking is it can restrict
reengineering team's thinking to framework of
what is being done in its own industry.
Benchmarking can, however, spark ideas in
the team.

20
Understanding
Processes..
Once the team understands what the
process customer might need, the next
step is to figure out what the process
currently provides - to understand the
current process itself.

21
Understanding
Processes..
Diagnosing the company's current processes,
the reengineering team is learning a great
deal about them, but not so that it can fix
them. Fixing the old processes is not enough.

Instead, the team is trying to study the

existing processes so it can learn and
understand what is critical in their
performance. The more team members know
about the real objectives of a process, the
better they will be at its redesign.

22