RETURN TO TOOLS:
BUSINESS PROCESS RE-ENGINEERING (BPR)
The concept of BPR has been around since about 1990 (with its 'bible' being
the 1993 book Re-engineering the Corporation: A Manifesto for Business Revolution,
by Michael Hammer and James Champy). However, it is often mis-represented -
as a short cut to downsizing, as a new quality methodology or as a lever to
new computing systems.
If we take a business process to be a set of logically related tasks undertaken
in pursuit of a defined and agreed business objective then BPR starts to look
fundamentally quite simple. It is about the improvement of productivity by looking
at entire processes, rather than at specific activities or functions.
The advantage of this wider approach is that a business process incorporate
all the work and the non-work (delays, storage, wastage, error-correction, etc)
associated with the sequence of tasks involved. It also involves the communication
processes between the various departments or functions involved in a process,
and the rules, regulations and bureaucracies that surround it. Now, BPR starts
to look like a holistic approach to improvement.
Finally, in these terms, a business process should result in an output/outcome
that is 'close to' the customer. (Thus, 'new product design' is a business process
- involving, perhaps, marketing R&D staff, designers, and production engineers.)
BPR is therefore customer-focused.
The original concept was one of revolutionary redesign (or re-engineering)
involving 'breakthrough' improvement. There were a few early successes - but
many subsequent failures - of this revolutionary approach. The consensus is
now that BPR MAY be revolutionary, but that evolutionary change is often more
realistic - and lower risk.
At this evolutionary level, BPR can be seen as part of the continuum of productivity
improvement techniques - its 'USP' being the concentration on complete processes.
Too often, BPR is used to 'sell' new (improved?) technologies. All good productivity
professionals know that you improve systems before you automate them - the same
is true with business processes. It is true that improving access to SHARED
information can have a significant effect on an organisation. Technology can
thus be a part of (indeed, even an important part of) an improvement solution,
but it should not drive it.
BPR tends to be (relatively) 'big bang'. Examining entire business processes
is often disturbing (to the organisation) and is therefore carried out infrequently.
However, any success from a BPR project can be short-lived unless there is some
form of 'maintenance' programme. BPR plus continuous improvement is necessary
for ongoing success.
See http://www.reengineering.com/
RETURN TO TOOLS: |