Business Process Transformation - Spring 1996 Business Process Transformation - Spring 1996
In this page I attempt to give an outline of a "method" for Business Process Reengineering. This is difficult for two reasons. Firstly, most BPR books are written by consultamts who are promoting a proprietary methodology, so each book uses different terminology. Secondly, it is not feasible to produce radical change by simply following a standard method; for this reason many books concentrate on giving examples of past successes and hope that these will provide inspiration for other circumstances.
Most of this page follows Thomas Davenport's Process Innovation. The last section briefly refers to Manganelli's Reengineering Handbook. This book presents a methodology in format similar to the usual systems development methodologies.
A major part of BPR is process modelling. Other pages discuss both high level process modelling and detailed process modelling.
Like many other approaches, BPR claims to align organisation change (and IT development) with business strategy. This is important because BPR concentrates of improving processes which are of primary strategic importance. The assumption is that strategy is already determined, and that it is externally focussed, dealing with customers, products, suppliers and markets. BPR is quite distinct from strategic planning.
Some authors, however, (eg Peters ) minimise the distinction between stategy and tactics, pointing out that possibilities uncovered through examining processes may open the way to major changes in strategy.
Here we choose those processes on which we will concentrate our reengineering effort. This choice involves a number of steps.
Davenport defines a process as "a structured,measured set of activities designed to produce a specified output for a particular customer or market" [p5]. For Manganelli [p8] a process is "an interrelated series of activities that convert business inputs into business outputs (by changing the state of relevant business entities)". Both definitions are carrying an excess of methodologial baggage (ie aspects of the method the author is going to propose are built into the definition - a procedure more acceptable in marketing than in science). But if we equate "structured" with "interrelated series" and assume "business" refers to customer orientation, then the two authors agree on "an iterrelated series of activities which produce business outputs". Presumably a good process could have just one activity, but in general processes are "bigger" than activities (authors suggest a company which is only in one business could have 10 to 20 major processes) and they must do something that makes sense to an outside observer (not something such as "update Form B27").
Manganelli classifies processes by both strategic impact and the extent to which they are value-adding. Strategic impact is discussed below. Value-adding is probably included in the phrase "produce business (not management) outputs"; this means that what we produce is worth more than what we started with and is discussed further under value chains. In any case, Manganelli suggests that we should choose processes for reengineering which have both high strategic impact and high value-adding.
This is easy to say and hard to do. Some processes, such as product manufacture, are fairly obvious, though there may be doubt whether to include activities such as materials procurement within this process. Sometimes the boundaries between processes which follow one another (eg marketing and sales, delivery and installation) are hard to agree. Processes which involve more than one company can also cause boundary problems. The worst case is when processes intertwine, sharing some "multi-purpose" activities. While there may be good motivational reasons for this (eg having people do something that is of no interest to them as a by product of something which they wish to do) it usually indicates an awkward organisation design which will be difficult to deal with. In this case it may be best to decide which is the more important process and redesign that first. In general redesign work should start on "obvious" processes.
Usually reengineering will concentrate on a small number of processes. This may seem suboptimal, but provided the processes chosen are complete (not parts of processes) and the reengineering is thorough, a flow-on effect will probably mean that unsatisfactory neighbouring processes will soon become candidates for redesign. So we should begin with those processes which are most critical to the organisation's strategy. At UTS, for instance, the major strategy might be to obtain more money from industry. Processes directly contributing to this strategy would be good candidates for reengineering.
The complete health of processes can only be assessed by detailed modelling, but processes with obvious problems are cndidates for reengineering. Obvious problems include customer complaints, multiple buffers and long delays between steps in the process. A process which is both sick and strategically important can have a serious effect on any organisation.
This step (which is even less quantifiable than the others) assesses the culture and politics of the organisational units performing activities within the process, and how these units are viewed in wider organisational politics and culture. Processes in a medical school, for instance, may be harder to reengineer than those in a business school, both because the medical school places a high value on its independence and because it is highly regarded by the rest of the university (or even society). Since successful reengineering ultimately depends on the cooperation of those performing the process, it is better to deal with processes where the culture and politics are favourable.
"Creating a strong and sustained linkage between strategy and the way work is done is an enduring challenge in complex organizations. Because business processes define how work is done, we are dealing with the relationship between strategy and processes." [Davenport,p117]
In BPR, as in all design work, creating the vision is the crucial stage; and it is also the least structured. In assessing strategy and selecting processes we were trying to understand things which (in theory) already exist. Similarly when we come to assess existing processes and resources. For design amd implementation we may be helped by guidelines, methodologies and examples of similar systems. But in creating a vision we are more or less on our own.
There are a number of techniques, such as brainstorming, which are known to help in the creative process. Some of these can be found in Adams' Conceptual Blockbusting and Gause & Weinberg's Exploring Requirements . When working on process visions it is also helpful to consider in which areas of the business we wish to redesign processes.
Davenport deals with two aspects of vision creation: the search for a vision and vision characteristics.
Process visons must be related to strategy, so we may look to the organisation's strategy for inspiration. This assumes that the strategy is sufficiently specific to give a sense of direction (eg "improve quality of service to regular customers" rather than "improve quality"). Thinking about strategy also keeps the vision search at the right level - broad but specific.
Beause much BPR work supports a customer focused strategy, it is important to have customer input to the vision. More generally, the "customer" is the one receiving the business output, and this includes internal customers; it is important that we know the output is "right" before we start working out how to produce it.
Benchmarking, in the context of creating a project, means seeing how other people do it. This is related to the idea of adopting "best practice", though if we want competitive advantage we may have to do better than "best"; nevertheless, it is good to find out what is best so far. We are looking for ideas, not imitating, so we may look for benchmarks in quite different types of organisation; in fact this may be easier, since our direct competitors may not wish to reveal their "best" practice to us.
"Process visions, like strategies, should be easy to communicate to the organization, nonthreatening to those who must implement (or who are affected by) them, and as inspirational as measurable targets can be." [Davenport,p119]
The process vision shows what we want our new process to do and (to a very limited extent) how it will do it. These are respectively the process objectives and attributes.
The objectives should have a customer (or business) focus - they must truly be concerned with outcome. They must (according to all the experts) be measurable - we must be able to tell how we have done. And they should be simple and non-contradicty - we don't want a long list of competing objectives, nor objectives whose measures are only comprehensible to a mathematician, economist or accountant. Typical objectives would be "reduce delivery time by 50%" or "double the number of potential customers contacted per month".
The attributes indicate how we intend to achieve the objectives, perhaps in terms of technology or general principles. It is somewhat unusual to develop objectives and means simultaneously but since BPR is aiming for radical objectives it is necessary to have some indication of how they will be achieved before management will be prepared to commit to the design phase. Notice that it is important at this stage to consider a variety of means before the vision is finalised. Adding attributes to our objectives might give "reduce delivery time by 50% by outsourcing delivery services" or "use to internet to double the number of potential customers contacted per month without increasing staff".
Davenport points out that radical change will only be achieved by setting ambitious objectives - "creativity must be encouraged by setting impossible goals".
Some proponents of BPR advocate starting with a "clean slate" but
most (including Davenport) recommend that we spend time studying existing
processes. There are a number of reasons for this:
Studying the existing processes includes the following activities:
In this step we judge whether we have the resources available to proceed with the project. "Social resources" refer to the organisation and the people in it. Is the organisation used to change? Are there key supporters of BPR? Does the organisation have a tradition of team work and open discussion? Is there an atmosphere of trust? What skills are available? Are people willing to learn? If social resources appear to be inadequate, they will need to be developed before or during the reengineering project.
The same applies to technical resources, though these are easier to judge. Is appropriate technology available to support the new processes? This means hardware, software and skilled people. Limitations particularly occur with network infrastructure. Again, missing capabilities will have to be developed, although in this case (unlike social resources) outsourcing is a possibility.
Design and implementation of the new processes can use any suitable
methodology, but a number of points need to be remembered.
In his Reengineering Handbook
Manganelli presents a detailed reengineering methodology which
is similar to the usual system development methodologies. His methodology
(Rapid Re) has 5 stages:
These stages are very similar to Davenport's, although they go into more detail about process modelling. Manganelli pays more attention to improving existing processes and his methodology has more emphasis on entities rather than processes - ie it has more of a data base flavour.
Part of Lecture 4, 23/8/96.
Any questions or comments, just e-mail me.
This page is maintained by
Jim Underwood
who can be reached at
jim@socs.uts.edu.au.
This page was last updated on November 3rd, 1996.
http://linus.socs.uts.edu.au/~jim/bpt/bpr.html
