Business Process Transformation - Spring 1996 Business Process Transformation - Spring 1996
In his Reengineering Handbook Manganelli describes his Rapid Re methodology which combines business process reengineering with a fairly conventional life cycle approach to systems development. This methodology has five stages: preparation, identification, vision, design (technical and social) and transformation. Here I discuss the identification and vision stages.
This is where we decide what the major processes are and which processes to reengineer. Manganelli divides this stage into nine tasks.
As with all reengineering, it is important to focus on the customers. Perhaps surprisingly, most reengineering methods approach the customer through first identifying customer serving processes. Manganelli starts with the customers, modelling who they are, how they behave and what they expect. This gives us a wider scope to change processes (since no process is taken as given) and ensures that the customer needs are well documented. We must remember, however, to keep checking our proposals with real customers rather than coming to believe that the model is the customer.
This task in common to all methods. For Manganelli it is important that the measures be directly related to customer needs. Performance measures also need a reference point or baseline. This could be previous years' performance, competitor performance or "best practice".
The fact that this task appears early indicates that Manganelli is a "data base person"; that is he believes data base design is more fundamental than process design. Entities may be people, organisations, machines or more abstract things such as "product concept". Entity definitions should include measures of entity state and their interaction with other entities.
We can now model processes in the context of customer needs and entity state change. Process models include objectives, critical success measures, input, output, triggers and rules.
Activities are the steps needed to accomplish a process. Manganelli suggests that we should assess the extent to which each activity contributes to customer needs and adds value. I think that these questions are more appropriate at the process level. For activities, the questions should be "are they necessary for the process" and are individual activities and sequences of activities performed efficiently.
Here the process model is included to include interfaces with customer (or supplier) processes. This is important. If each organisation reengineers only out to its own boundary, processes can become lost in the neutral territory between organisations.
This task takes the processes (and entities) we have defined so far and attempts to map them to the conveventional organisation structure. Who is responsible for the success of each process? Who performs the activities?
We now estimate the resources used in performing each process. Resources include person time, money, machines, computer time, data storage and communications capacity. These estimates can be used as a baseline for judging improvements in reengineered processes.
Which processes should be tackled first? Three major factors are process impact (how important is it), process size and process scope (how expensive - and risky - will it be to change).
Developing a (new) process vision is the critical stage in BPR. It is also the stage where a formal methodology is least likely to be helpful. This is where all the creative tricks such as brainstorming are used (see Adams). Manganelli has little to say about this core of vision development, but he does suggest a number of tasks whcih will make us better prepared for the creative activity. One key to envisioning new processes is to look at the current processes and ask "why?".
This expands on the process modelling done in the previous stage. We need to understand how the various activities are related by both logic and timing (and culture for that matter) and get a feel for the process as a dynamic whole.
Our understanding of the process is expanded to include decision points, subprocesses and exceptions. It may be useful to group inputs and outputs into "transactions".
This tasks seeks to determine exactly how the process contributes to customer needs or adds value. This is much easier if we hhave carefully defined performance measures in the previous stage (identification).
Here we compare the process (both the way it is done and the measures of performance) with similar tasks in our own or other organisations. This is best done by observation, since cases quoted in the literature are sometimes unrealistic. The benchmarking should not be too detailed, as it is only meant to generate ideas.
What makes it work, or not work? Are there critical "expediting" activities? Are there bottlenecks or accumulations of work? Is there waste or idle time? Is important information missing?
(I don't quite see why this task appears here. I take it to be evaluating alternate visions, which appear to be created in the next two tasks. I can only assume that the next two tasks describe a vision which has already been decided upon, and that the vital step of generating alternate visions has been skipped over beteen this step and the previous one.)
Anyway, the idea is, for each alternate vision of the new process (or for the vision already decided), to estimate the degree of change, the difficulty, risk and benefits. There may also be some "opportunistic" opportunities which can be taken immediately.
This task describes the new process from the point of view of the customers, using the previously defined performance measures.
And this describes the internal workings of the process and evalutes internal measures (eg efficiency).
The internal and external visions are compared, checked for conflicts, and adjusted to each other. We also check that there are no conflicts with other existing processes (or immutable organisation policies).
The new process vision may be achieved through subvisions which are stages on the way to the final system.
In Automating Business Process Reengineering Hansen develops a simulation based approach to reengineering. His motto is "try before you buy"; he suggests (correctly) that many reengineering projects merely map new processes on paper (or Powerpoint) without any evidence that they will really work. Before committing ourselves to major change Hansen advises us to do a fairly detailed simulation of the new processes. A simulation package called CAPRE (computer aided process reengineering) is provided for this purpose.
Hansen's method is based on two existing organisation models: the Software Engineering Institute's (SEI) Capability Maturity Model and Senge's use of positive and negative feedback loops.
The Capability Maturity Model (CMM) is usually with IT development organisations to assess the degree of sophistication of their IT development procedures. CMM levels range from 1(very little control) to 5 (well established mechanisms for modelling and controlling success). CMM levels are believed (by their advocates) to be useful in predicting the quality of products produced by the organisation.
Hansen uses the CMM model in a slightly odd way. Instead of tracing levels of maturity as an organisation develops, he uses the model to map levels of understanding of business processes, and sees these levels as stages which any BPR project should follow. (Thus a description of an evolutionary development is turned into a methodology - a transformation which usually proves disastrous in the social sphere.) Nevertheless, although the claimed connection with CMM is suspect, Hansen gives us a useful sequence of steps to consider when reengineering. He calls these the "Rules of Process Reengineering".
We are meant to deal with these rules in order. For each rule we study the current system, then implement desirable changes. The new system becomes the current system for the next rule (I think). Hansen seems to believe (probably correctly) that with rule 1 (say) we may uncover some gross problems which have solutions which will remain valid. Later rules provide fine tuning. (The alternative would be that changes which appeared obvious at the beginning would be shown to be silly on deeper study.) If my interpretation of Hansen is correct, he has an incremental approach to BPR.
How does the existing system work? What are the problems? Are there any obvious chnages to make?
Unlike some BPR advocates, Hansen insists on involving a variety of stakeholders, including customers and workers, in the discussion. It is in the discussion that Senge's models are useful. The ideas of reinforcing processes and balancing processes (either of which can be good or bad) are very useful when trying to understand how the organisation as a whole works.
This may seem obvious, but writing down conclusions or agreements reached during discussion encourages us to clarify our findings. Documentation (if easily accessible) also reduces the change of going over the same gound next time.
Hansen believes (as do many engineers) that we can't really take a process view until we can express organisation activities as diagrams. Diagrams emphasise stages and direction, and are an economical way of representing complex processes.
The fourth rule (as with most BPR) is to measure. Everything. This includes output quality, costs, process time, waiting time, staff productivity and customer satisfaction. Hansen also reminds us to measure the behaviour of the people as well as the products.
This is where Hansen's approach differs from the average. The processes which we have discussed, documented, diagrammed and measured are now modelled with a simulation package. For the existing system this gives a much clearer idea of overall performance and where faults are occuring. For any proposed system, simulation can justify our predictions of improvement or uncover nasty surprises before new processes are put into production.
Hansen uses a Capre, a special purpose toolset which has been built from a simulation package called Extend.
There is no need here to understand the details of the Capre toolset; details can be found in Hansen's book. The toolset comes with a numbe r of basic activities including:
import and export - moving objects in and out of the process
operation - does something, may combine inputs, takes a certain time
decision - redirects the process depending on some value
stack, repository - where objects wait or are stored
these activities have duration, input parameters, interrupt triggers
There are also functions to assist in decision making and driving activities (eg random generation of arrivals), and reporting functions so we can monitor the simulation.
The models can be hierarchical - eg an operation box can be expanded into another process model.
Below is a simple Capre model of a credit application review process (unfortunately hard to read at present).
The top row of boxes are: import, repositiry, operation, decision, export. Notice the random number generators driving three of the boxes.
In his article "A new approach to business processes" Scherr proposes that process models be based on the speech act theory of Austin. This theory is widely used in linguistics and artificial intelligence theory. Speech act theory is one way of attempting to assign meaning to business processes.
Instead of looking at the structure (syntax) or the "content" (what is referred to - semantics) of statements, speech act theory looks at statements in terms of what they are trying to do. Statements which are meant to do something, rather than tell us about the world, are called performatives. Examples are requests, promises, challenges and declarations . The point about performative statements is not whether they are true, but whether they are effective and/or appropriate. Conversations often follow fairly standard sequences of performatives - eg request-promise-clarification-confirmation-agreement or complaint-apology-acceptance.
Scherr starts with the (usual) idea that BPR is about relationships with customers. He then analyses this relationship in terms of speech acts. A typical customer-supplier relationship might go through the following stages (protocol): open discussion, negotiate, agree conditions, perform service, assess performance, pay. Scherr claims that this is the type of business process which we should aim to reengineer.
Scherr also makes a point of including accountability in his model: we must consider who (from our organisation) is responsible for each step in the process. One thing which reengineering often does is change the accountabilities.
Scherr claims a number of advantages for his approach. Using speech acts gives greater consistency in process definition both because the process definitions are more closely connected to organisational reality and because conversational protocols are fairly standardised (at least within one culture). He also proposes standard measures for each stage in the process: time taken, outcome, history of moves and participant satisfaction.
He has several criticisms of conventional approaches to process modelling. The customer, who is said to be the focus of the process, is often missing from the models. Early and late stages of the process (negotiation and assessment) are often neglected. The process is modelled as working to an anonymous specification which is supposed to stand in for the customer - another result of measuring the wrong things for the sake of having something to measure.
Scherr raises questions about how reengineering can deal with accountability. Problems usually occur at functional boundaries where the process moves between stages. Delays often occur with processes waiting to be picked up for the next stage. In a conventional hierarchy this is dealt with by placing overall responsibility for the process at the next level up; in a complex functionally divided organisation this results in the responsibility for a complete process rising to a level where people are not able to worry about the detailed process of a single order. Measures are devised to control the performance at each stage of the process but this leads to suboptimisation and shifting of responsibility. An alternative is a type of matrix structure where a process manager has the responsibility for steering an order through the organisation on behalf of the customer. This only works if the process manager has sufficient influence to overcome the interests of functional managers; customers can receive eratic service depending on the social standing of a particular process manager.
Scherr suggests that these problems can be alleviated by the use role partnerships, assigning joint responsibility for the transition of processes across functional boundaries. Instead of managers for adjacent stages of the process being given (or agreeing) individual performance measures (a contractual arrangement), they take joint responsibility and enter into a partnership based on trust. Trust implies promises, deals and possible sanctions (eg you were late last time, so I'll expect you to start earlier next time). Partnerships are best analysed (according to Scherr) by speech act theory, and any IT system supporting the process must take this into account. The partnership model seems to be the way things are often done anyway, so it is only realistic to include it in our process model.
BPT Lecture 7, 20/9/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 5th, 1996.
http://linus.socs.uts.edu.au/~jim/bpt/proclittle.html
