I have addressed many of the principles around business process reengineering (BPR) in the previous articles. What will make this article different is that it will describe how to prepare for, and run, a BPR workshop and program of improvement. It will repeat a few of the points covered in previous articles, as the concepts are inherently intertwined.
To run a successful BPR project requires context. The easiest way to build context is to establish a table that disaggregates the business from the macro to the micro. Industry language describes this as going from level 1 to level 4. Level 4 is the generic term for the detailed process map, but in practice the disaggregation may drill down to level 5, 6, or 7.
There is no right or wrong, but it is worth considering that if you need to drill down to levels 6 or 7, then you may be narrowing the definition of process too much. This will make it very difficult to keep the process in context.
The disaggregation is represented as follows:
To operationalise this picture prepare a table with the following or similar headers.
The description fields are important as they force the author to think critically about the separation between the processes they are intending to map. It may not be possible to complete all the fields in the first instance. It is recommended that you do not start mapping processes until the data for that process is agreed. Ideally the table will be included in the statement of work.
For the process mapping workshop, you will need a decent size white board, a data projector, and a laptop. The workshop participants should be staff who are very familiar with the process. This may mean that you need more than one “subject matter expert” in the room to adequately cover all aspects of the process.
The following guidelines will add rigour to your process mapping.
1. Model the process using roles not positions.
2. Only one role can be responsible for an activity. Another role can contribute to the activity, but they are not responsible.
3. The input from all trigger processes should be sufficiently consistent with the unit of measure being used in the process. A trigger process is a process that precedes the process you are working on. The output from that process is the input to the next process.
At the very least, the following data should be collected in the workshop, or as a result of the workshop:
• Unit of measure—what is “processed.” It provides a means for calculating the annual volume.
• Annual volume—can be broken down to weekly or monthly.
• Process owner.
• Process deliverables/product.
• Distribution list for reports.
• Trigger processes.
• Hand-off processes.
• Roles.
• Indicative role costs.
• Process activities.
• Process sequence.
• Decision points.
• Percentage splits on each decision.
• Work time for each process activity.
• Cycle time for the process.
• Technology used for each activity. Extended data requirements can include:
• Information gathered at each step.
• Status changes in the item being processed.
• Descriptions of each activity. This may include work instructions.
It is important to establish early on whether you want to draw or model the process. It is almost impossible to adequately collect and evaluate the level of information described above if you do not use process-modelling software. If you use software that only captures the process as a flow sequence, such as Ms Visio, and different software applications such as Ms Word and Excel to capture the additional detail, then you are drawing. In this case you will not be able to complete the analysis described below.
Modelling software allows you to capture the details of the process in the third dimension. That is, you can capture all supporting information in the application at the time of mapping the process. The concept is: write once, use many. There are a range of applications on the market that support this type of process modelling.
To start the workshop, ask the participants to confirm the data collected in the process definition worksheet. Then ask one of the participants to talk you through the process. It is best to have a high-level schema of the process in your head before you start.
Using standard interview techniques, capture the flow sequence on screen in front of everyone. Pay special attention to the words the participants use. Take time to explore inconsistencies or the subtle differences between branches in the flow.
Once you have documented the process, go back through it and capture the required details for each activity. The most important data are the work time for each step, the percentage splits for each decision, and the role costs. With these three data points you can complete the primary process analysis. An additional data point to collect for each activity is the underlying technology and whether it is manual, batch manual or integrated processing.
Please note the following techniques are only possible if you are using modelling software.
For the first round of analysis, use the traditional R.A.C.I. (RACI) (Responsible, Accountable, Contributor, Informed) table.
• The process owner is Accountable.
• The roles are Responsible.
• The distribution list for reports and process outputs helps define who are the Informed stakeholders.
• You may or may not have a Contributor.
The following is an example of a RACI table.
The RACI table allows you to confirm you have gathered all the required information and applied it in the correct manner.
The next level of analysis is to confirm how the process fits into the wider business. That is, do the trigger and hand-off processes make sense? In the graphic below the downward arrows represent trigger processes and the upward arrows are hand-offs. Obviously a hand-off process is also a trigger for the next process. In this way process 1 is the trigger process for process 2 and process 2 is the trigger process for process 3 etc. Each process is measured with KPIs and the relationship between them is measured by SLAs.
The third level of due diligence is to understand the process data itself. This is done through understanding the sequencing paths within the process.
Consider the following process:
It is an amalgamation of four paths or processing sequences. The paths are shown as follows:
Path 1
Path 2
Path 3
Path 4
This analysis will produce two key tables:
1. The cost to serve.
2. Full-time equivalents (FTE).
The cost to serve table is shown and provides the weighted average cost for one iteration of the process. This number can be multiplied by the annual volume to get the annual cost.
Column 1 references each way the process can be transacted. In this example there are four paths.
Column 2 is a result of the percentages applied to each decision in the process. (These are not shown in the diagram.)
Column 3 is the activity-based cost of the sum of the activities within each path. The figure is based on the costs associated with each role multiplied by the time associated with each process step in the path.
Column 4 is the product of columns 2 and 3 and represents the cost to serve of one iteration of the process.
The second table is a staffing analysis. It is a similar analysis as is the cost to serve, but is completed on staffing needs-based FTE requirements. The following is an example. It shows FTEs by path and total FTEs for the process for one iteration.
The analysis is completed by applying the annual volume to the FTE table. In this case, the annualised staff requirement becomes 1.8 FTEs.
Due diligence is to ask: “Does the annualised FTE number make sense? Can the annual volume be completed with 1.8 FTEs?” If you add a productivity factor of 10% or 20% the FTE figure rises to 2 (rounded). If the answer is yes, then you know you have captured the process correctly. If not, then the process data needs to be revisited. The answer does not need to be precise; rather a “substantially correct” answer is accurate enough for decision-making.
Once the individual processes are agreed, they can be aggregated to provide a holistic view. It is the same table as shown in previous blogs.
With this table, process improvement can be prioritised. Assuming the intent is to reduce costs, you read the right-hand column. It shows the relative contribution of the individual process costs to the sum of costs for all processes. It can be seen that the “purchasing” and “new user setup” are the two processes that contribute most to total costs.
To reduce the costs associated with a business process refer to the cost to serve table.
Path 1 is the most cost-effective processing sequence. The best outcome is to reengineer the process to maximise the volume flowing through this path. This will deliver a savings of $49 per process iteration. If the process is transacted 10000 times a year, then this is a savings of $490,000. If you cannot improve the process to get 100% through path 1, then the next best option is to maximise volume through path 1 and use path 2 for the overflow.
Moving 100% of the volume to path 1 can be achieved through controlling the decision.
Typically this can be achieved through a change to the:
1. Staff profile through skills improvement or behavioural change.
2. Processing sequence through policy or procedural changes.
3. Underlying technology through workflows and configuring the existing system.
A change in skills will require further analysis to be able to answer the questions illustrated below.
The approach is to complete this analysis for each step in the process and then aggregate them into a consolidated table. This table can be cross-referenced to the RACI table to check for completeness. Once this data is collected, it can be cross-referenced to the skill profile of the staff working in the process and improvement strategies developed.
Option 3 is the best option as the application of technology or a workflow removes the option for the process performer to make a decision in the process. This concept is explored further in the chapter on Judgement Support and Decision-Making.
Recognising that this type of process change is frequently quite substantial in its nature, it is better to complete the analysis for all processes as shown in the following table and then develop a business improvement program to meet the change requirements of all processes at once.
Before implementation commences it is important that the business case for change is validated. The above table identifies the entire program of required improvements and these improvements are then used to recalculate all tables described throughout this chapter. The expected benefits are then compared to the existing process metrics.
In this example, a total benefit of more than one million has been identified with an associated saving of 21 FTEs. The nature of these 21 FTEs can be identified through a comparison of the staff profile tables.
I close with the following comments. Business process reengineering is reasonably straightforward to do at the “surface” level, and somewhat more difficult to do at the detailed level. A schematic of a process is just that—a schematic. It is a representation of the routines staff follow on a daily basis and to reengineer the process requires a change in these routines. To gain the trust of the affected staff requires a rigorous analysis of the processes combined with a focused program of change management. It is equally important to remember that processes do not exist in isolation and to change a process without understanding how the process interfaces with the rest of the business is likely to reduce the overall benefits received.
Garth Holloway 