CHOOSING THE PROCESSES TO
REENGINEER:
Once processes are identified and mapped, deciding which ones require reengineering
and the order in which they should be tackled is not a trivial part of
the reengineering effort. No company can reengineer all its high level
processes simultaneously.
Typically, organizations use three criteria to help them make
their choices.
-
The first is dysfunction: Which processes are in the deepest
trouble?
-
The second is importance: Which processes have the greatest
impact on the company's customers?
-
The third is feasibility: Which of the company's processes
are at the moment most susceptible to successful redesign?
Broken Processes. In looking for dysfunction, the most obvious
processes to consider are those that a company's executives already know
are in trouble. As a rule, people are clear about which processes in their
companies need reengineering. The evidence is everywhere and generally
hard to miss.
A product development process that hasn't 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 terminal or from one terminal
into another, whatever process they're working on is probably broken. If
people's work cubicle walls and their computer screens are papered with
Post-it notes reminding them to fix this or look into that, the processes
in which they're involved are probably broken too.
Let's look behind some of these symptoms of process distress or
dysfunction to the diseases that usually cause them.
Symptom: Extensive information exchange, data redundancy, and rekeying.
Disease: Arbitrary fragmentation of a natural process.
When employees are keying data taken from one computer into another, it
is a symptom of what we call "terminal disease." The efficiency minded
manager's typical response to a case of terminal disease is to look for
a way to rekey the material more quickly or, if the manager is more technologically
oriented, to find a way to link the terminals, so the material can travel
electronically from one system to another. Both solutions treat the symptom,
not the disease.
When the same information travels back and forth among different organizational
groups--whether it's rekeyed each time or transmitted electronically--it
suggests that a natural activity has been fragmented. Well-designed natural
organizational units should send finished products to one another. Extensive
communications is a way of coping with unnatural boundaries. The way to
fix the problem is to put the pieces of that activity or process back together.
Another name for doing that is cross-functional integration, which allows
organizations to capture data just one time and then share it, instead
of finding faster ways to ship it back and forth.
Terminal disease doesn't involve only computerized data. If people
in different parts of the organization have to telephone one another frequently
or send a lot of memos or E-mail messages, that probably means a natural
process has been inappropriately broken apart. The typical response to
this form of terminal disease is to give the people affected by it more
communications links--another phone line, a fancier fax, and so forth.
But that treats the symptom not the disease. Indeed, the new devices often
fail to treat even the symptom. Our version of Parkinson's Law says that
"work expands to fill the amount of equipment available for its completion."
Give people more communications capacity and they will communicate more
and still feel it's not enough.
The fact is--although collaboration may be necessary for some processes--people
should not be calling one another more; they should be calling one another
less. To treat the disease, we have to find out why two people need to
call one another so often. If what they do is so closely linked, maybe
it should be done by one person, a case worker, or by a case team.
From REENGINEERING THE CORPORATION,
by Michael Hammer & James Champy, 1993
Return to MiniMBA Technology Page
last modified February 28, 1998 ~~ comments and suggestions to rbanis@jinx.umsl.edu