BPR or Business Process Reengineering was one of the big management ideas of the 1990s. Although less fashionable today, its underlying principles still make sense especially for older, larger companies which have become somewhat stuck in their ways.
The foundations for Business Process Reengineering, or BPR for short, were laid in 1990 when Michael Hammer published a paper called ‘Reengineering Work: Don’t Automate, Obliterate’ in which he proposed that in place of automating work which did not add value, companies should get rid of it. In 1993, with James Champy, he expanded on the proposal in the book ‘Reengineering The Corporation.’
Where previously management had started and finished at each departmental door, BPR took a bird’s eye view of a business as a whole, prizing open the ‘silos’ which had, over time, developed. The basic premise was that customer needs involved processes which cut across these old, established silos and that activities should be reassessed to reflect the full process.
Hammer and Champy defined BPR as ‘the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service and speed.’ BPR’s recurring question is; “how do we add value for the customer?”
The four highlighted words used in the definition were chosen carefully. BPR is fundamental in that it asks often overlooked but basic questions such as “why do we do this?” or “why are we doing it this way?” It is radical because it starts with a clean sheet, making no assumptions and ignoring existing structures and procedures.
In seeking to make substantial improvements rather than marginal tweaks BPR is dramatic; processes because they are pivotal to BPR’s success. Where historically (and in many cases still) companies were split into departments with processes split into tasks further split between those departments, BPR reviews the tasks against their ultimate purpose focusing sharply on customer needs.
Hammer and Champy provide an example in IBM’s credit approval process which, at the time, took an average of six days and could take up to two weeks. This slow pace often meant that a customer was lost to the competition before approval was granted. The process involved five steps:
1. The salesperson called in with a finance request which was written down on paper by an operator in the central office.
2. The paper was sent to the credit department where the customer’s credit was checked. The result was noted on the paper which was then forwarded to the business practices department.
3. The business practices department would modify IBM’s standard loan contract to reflect the customer’s special requests, attach special terms to the paper and forward it to the price department.
4. The price department would determine the interest rate the customer should be charged and add it to the paper before forwarding it to administration.
5. Administration produced a quotation which went to the salesperson who would deliver it to the customer.
IBM realised this was not efficient and tried a range of unsuccessful tweaks before an executive decided to apply BPR. He took a request for finance and then personally walked it through the entire process. Beginning to end it took him only one and a half hours! The problem had not lain in how long people took to do the job but in the structure of the process and in all the handovers.
Having established this, IBM analysed the process and uncovered a hidden assumption that every request was unique and required specialist assessment from four separate specialists. In reality most requests were fairly standard and could be dealt with by a generalist provided they were supported by an easy to use IT system.
The use of IT as an enabler is integral to BPR; not in using it to automate old tasks but in facilitating improved methods.
Hammer and Champy suggested the following BPR principles:
- · Organise around outcomes not tasks
- · Integrate information processing work into the real work that produces the information
- · Treat geographically dispersed resources as though they were centralised
- · Link parallel workflow activities instead of just integrating their results
- · Put the decision making point where the work is performed and build control into the process
- · Capture information once – at the source
It has been reported that up to 70% of BPR projects fail which has contributed to it being used less than in the 90s. However there are numerous reasons for BPR failure which should be blamed on the implementing organisation not on BPR itself. These include:
- · Trying to fix a process instead of changing it
- · Settling for minor results
- · Giving up too early
- · Skimping on resources
- · Concentrating exclusively on design
- · Placing prior constraints on problem definition or scope of the effort
- · Trying not to make anyone unhappy
Another frequent criticism of BPR is that it lacks attention to the human dimension. This was not Hammer and Champy’s intention and Michael Hammer later advised that people’s values and beliefs should not be ignored.
Classic BPR is somewhat less popular nowadays with refined evolutions such as business process redesign, business process improvement and business process management being preferred. However, there remain many organisations which could benefit from applying BPR’s principles.
© Jim Cowan, Cowan Global Limited, June 2012