PHS BPR training explores business process reengineering

BPR Training - Business Process Reengineering

Management Training Contact Us

Business Process Reengineering Introduction

'Business process'; is one of those apparently simple yet actually quite difficult management concepts to nail down precisely. However, before launching any form of process improvement activity we must be able to define what we are addressing.

Are businesses run by functions, or departmental activities? Thinking about things in this way builds an inherent failing into our perception of what we do. It encourages a focus on these functions or departments as we strive to obtain optimum performance, when in fact the optimum can only be achieved by addressing the combination of functions. This is what is referred to as a business process.

Even then, it can be hard to differentiate functions and processes. When does a function become a process? Is placing a purchase order a process – we hope everybody would agree that it isn't placing the order and receiving goods or having the service carried out is closer, but might this be a process? In a business buying a sub-contracted manufacturing activity within its own production of finished goods this is most certainly not the case since the sub-contract operation is just one step in the line. In a retail organisation buying stock for the shelves in its stores, buying and receiving may be considered a process, though this may still be too narrow since the selection of suppliers and establishment of supply agreements may be central to the 'procurement process';.

In the definitive work on BPR in 1993, Michael Hammer and James Champy described a process as:

  • 'A collection of activities that takes one or more kinds of input and creates an output that is of value to the customer.'

They qualified this, saying that the customer of the process may not necessarily be a customer of the business. In the example above the retail (selling) side of the organisation is therefore a customer of the procurement process. This still doesn't give an absolute definition, but it provides a guideline to the basis of improvement activities. We can improve efficiency at each of eight stages of a process, but if the optimum performance of the business as a whole requires that these eight stages be carried out in no more than three then the improvements do no more than scratch the surface of our problems.

So, businesses run on processes and we should focus our efforts on ensuring that the processes are as good as they can be – however we define 'good'. Why might our current processes may need improvement? Consider two quotes from Edward de Bono:

  • 'Things evolve to become ever more complex – not more simple.'
  • 'Those who have got used to the complexity no longer notice it and even add more elements, so increasing the complexity even further.'

I think we have all seen examples of this. A process as established may meet the needs today but additions will come as customer requirements expand, or perhaps problems arise in quality or service level. (In such cases the complexity of the solution – the process change – often far outweighs the depth of the problem.) This complexity is often the root of problems; as a result things take too long and are more prone to error or people no longer trust business systems and begin to develop workarounds.

Business Process Reengineering

As with all improvement activity we have a choice; we can seek incremental (step-by-step) change or we can look to start with a clean sheet of paper. Reengineering, a term introduced by Hammer and Champy, is based on complete redefinition with some qualifying factors:

  • '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.'

The key words here are fundamental, radical and dramatic. These bring with them the requirement for process design teams to 'think outside the box';. They need to avoid all constraints imposed upon us by the way business has been conducted in the past, perhaps learning from organisations in quite distinct markets.

Although this article is primarily about BPR, we all have to recognise that a complete single-step transformation of something as wide-ranging as a major business process is not always possible. The thought that our workforce will go home on a Friday night having worked their last day under the old regime and when they come in on Monday everything be fundamentally and radically different may be unrealistic. A risk analysis may send senior management into fundamental panic; perhaps the future process as envisaged within the BPR exercise is agreed as the ultimate goal, but we now have to find a way of achieving it over a series of phases in which this risk can be managed. The incremental approach is generally referred to as Business Process Improvement, BPI, although we would argue that the incremental change should still have at its heart a statement of future vision, the optimum toward which we are working in steps.

Some readers may have spotted here a parallel with the adoption of Lean and we would not argue. Continuous improvement, or kaizen, is 'what it says on the tin';. It actually brings with it the cultural element of everybody in the organisation being committed to continually getting better but it can be considered the Lean version of BPI. The Lean version of BPR is kaikaku, sometimes referred to as kaizen blitz.

kkk

A Good Process

So what is a 'good'; process? We all have objectives in terms of customer service, product (or service) cost, market share, lead time, perhaps level of inventory or utilisation of our resources. In the commercial world all of these, of course, point towards return on investment and profit and if we set our priorities correctly then achieving the specific process goals will roll through to the financial targets. We may, for example, identify that a turnaround time of no more than four days for responding to customer requests for quotations is essential to achieve the level of business needed. This in turn will help meet turnover and thus profit targets. In government departments and non-profit organisations the ultimate goals are defined in different ways but broken down into goals for business processes.

In the example above we sought timeliness within the process; in other cases we may be focused on the cost of an activity, or on minimising errors / faults or any of a number of objectives. Good processes are an essential element of achieving any goal and a number of common features are always worth considering:

  • Eliminating unnecessary activities – a common definition of waste, in 'Lean-speak';, is an activity that adds no value.
  • The minimum number of handovers. Every time two steps in a sequence are carried out by different people or in different areas we introduce potential delay and the danger of information being corrupted.
  • Activities undertaken in parallel. If different steps are carried out sequentially the process will inevitably take longer and process speed is nearly always a key objective.
  • Simplicity. The easier it is for people to understand their role, the more likely it is that the steps will be executed correctly. The reverse is also true – this also applies to mechanised processes (consider service intervals on a Ferrari or Maserati, for example).
  • Repeatability – getting things right on a regular basis contributes to all the goals that are common to good performance.
  • 'Managing by Exception'; – we have all seen examples of management and staff spending inordinate amounts of time checking and chasing every activity. Surely life should be easier than this? We should design processes around the principle that everything happens as planned and if something needs action then this will be prompted by a trigger.

How to Achieve Best Practice in a Process

A key stage in achieving best practice has to be the design activity. We can usually look at what is currently happening and see some failings. There is always the temptation to launch a change exercise, but this should be resisted. We may find that we are looking to 'fix'; a process step that should actually be completely eliminated, or perhaps combined with another and executed elsewhere.

So the project team must approach the re-design of the process in an innovative way and understand all the possible tools at their disposal. This may mean that before any other steps are carried out the team need education in the area in question – a parallel may be drawn with teams charged with the adoption of business systems. Defining the way that a company will use an Enterprise Resource Planning (ERP) system requires a group who understand all aspects of ERP; the adoption of the production management elements of ERP requires equal understanding of the tools of Lean. These two approaches are often, incorrectly in our view, projected as somehow alternative. Best practice requires understanding of both and the use of appropriate techniques throughout.

Other requirements here are people who can challenge established limitations. All organisations can find examples of 'we do that because we've always done it' when in fact there was a reason for the activity in question being adopted and the reason is no longer valid – resulting from manual tasks being replaced by computer systems, for example. The team must question everything and look everywhere for opportunities to introduce the optimum.

Implementation / Methodology

We define a BPR project as embracing four phases (though every consultancy and author seems to promote their own vision). We would suggest that these phases are:

  1. Launch

A good kick-off is important to getting a BPR project 'off on the right foot'. It includes setting expectations, selecting and releasing team members, communicating to the organisation, briefing the team and providing the structure to support and manage the project. The structure of any major exercise should normally comprise a steering group and project team. Senior management cannot undertake all the detailed tasks in bringing about change but must provide direction, or 'steering';. They must be committed to this activity, ready to provide input throughout the project. The first steering group meeting sets goals and provides an outline of the future business for the project manager and their team.

A key element in any change programme is identifying a modest number of performance measures (usually of cost, quality, service and speed) which will enable the process-oriented business to be successfully managed and benchmarked. As with all such activities the initial measurements must be taken at the outset – the meaning of 'benchmark'; occasionally appears to pass people by! Another point to remember is, as always with the use of Key Performance Indicators (KPIs), these indicators should provide an indication of things starting to go wrong. On-time delivery, for example, is a very important measurement for businesses supplying goods to their customers, but it is an assessment of past performance. By the time this month';s on-time, in full (OTIF) figure of 95% is flagged as unacceptable we have already let down customers on 5% of the month';s orders. We need indicators that warn us of a slippage in performance before this happens. (As an example, if a potential problem area is in front-office processing of customer orders, by measuring throughput in this area we highlight delays when we still have the chance to catch up.)

  1. Document the Current Processes

Having established what the processes are, and which are to be addressed by the project, it is necessary to establish a common view of the 'as is' situation. This involves 'walking' the current process and documenting it – commonly referred to as 'mapping';. The most common technique for this remains flowcharting, but other approaches such as cross-functional ('swim lane';) maps and responsibility assignment matrices (RACI charts) can be valuable.

This always brings a question – to what degree of detail should the current process be documented? Our view is that we should be pragmatic; if it is apparent from early in the exercise that the process is fundamentally flawed and is to be replaced en masse, then we do not need to go too deep (although it is important to understand what has caused some of the 'tweaks'; and have those cases covered). Some consultancies promote the idea of always seeing this through to a detailed conclusion, but perhaps that is driven by a desire to maximise their own billing hours!

  1. Develop and Test Future Processes

Developing and testing the future process starts with the crucial step of developing the 'vision' for the future and in particular seeking breakthroughs to give competitive edge. This is followed by testing out the proposed future process on selected customers (of the process rather than the business) and then further developing the details. An inevitably iterative process, this may take longer than initially planned, but this must not be allowed to influence decisions on the time to be allocated – after all, how was the plan set? If a timescale had been allocated to particular aspects of the exercise, it was done purely on the basis of assumptions and estimates. Problems and opportunities that nobody could have envisaged may arise throughout such an exercise and plans must be amended to reflect these. We promote this as synonymous with laying foundations – if the temperature, humidity or air pressure means that concrete were taking longer to set would construction engineers ignore this and start building a skyscraper to the original plan? In any process change programme we are defining the future of the business for some years to come; getting it right is more important than doing it quickly.

Having worked through to a future vision, the feasibility of some of the proposed changes (both process and non-process related) are then investigated and prioritised. Management must commit to the processes and their implications.

  1. Implementation

Step 1 of the implementation has to be the development of a plan for the introduction. Managing change within BPR requires consideration of all the steps of any change programme – the plan must take account of resource requirements and the implications of the sequence of the various activities. The outline plan, with milestones and responsibilities, must be debated and committed to by the project team and management.

The final step is the only one which achieves benefits, i.e. the implementation. This starts with communicating to the organisation the scope of the implementation, the team and the timescales, establishing the project performance measures and subsequently conducting regular project reviews.

kkk

Why Do BPR Some Projects Fail?

Failure in BPR arises for the reasons behind failure in all forms of change project. We could list them all here and debate them in depth but people see these on a regular basis when exploring the adoption of business systems, Lean, Total Quality Management (TQM) and all forms of business re-location, mergers and acquisitions and so on. Key points worthy of consideration with regard to BPR are:

  • It is very easy to get lost in the depths of future vision design and for this delay to lead to people skipping quickly into attacking the internal efficiency aspects of the exercise.
  • Processes are based around people. We need people to understand the future process, but more than that, we need their buy-in. This requires clear communication and time dedicated to explaining, debating and persuading – remember that we are always likely encounter resistance to any form of change.
  • Management attention can easily drift. As noted earlier, all forms of change project require ongoing commitment and direction, ideally by means of a formal steering group-type approach.

Why Might BPI Differ From BPR?

It is often suggested that BPR – considered to mean stopping the world from spinning around its axis while a complete change to everything is carried out – is unrealistic. In many cases this may be true and therefore progressive, incremental change is the answer. In which case there are options:

  • Identify individual changes and implement them.
  • Design the future and make a number of individual changes with the ultimate goal in mind.

Our view is that all forms of BPI should follow the latter model. If we don';t have a vision of the future the project cannot achieve the optimum. An individual change may appear attractive, but may actually build in obstacles preventing the attainment of best practice.

Contrast BPI/BPR with Other Forms of Change

Key elements of best practice in process design, such as seeking simplicity and minimising process steps (seeking the 'one-stop shop';) are often cited as being tools within the Lean framework. If we make changes of this nature, then, are we implementing BPI/BPR or Lean? The answer, in our view, is a very resounding 'who cares?', because all that matters is achieving a goal. We have undertaken change programmes under both banners, often using one name because the other had been used already in the organisation and it was felt that this was as far as it could go. The new name was used simply to provide the fresh initiative. In another client, one of our conference case studies, all of the changes were managed at the site level under the TQM flag, while being reported to Corporate as part of the worldwide rollout of BPR. As before, who cares?

Six Sigma is traditionally different. It was established very much as an approach to problem-solving based around statistical analysis. It could be argued that this measurement can always be of value and therefore the original elements of Six Sigma may be a valid contributor to BPR. As Six Sigma has 'grown'; so to speak, with the development of the DMAIC methodology, it can perhaps stand alongside BPR as an approach to change and if it does, so many elements of these approaches simply have to be common.

We mentioned the implementation of ERP earlier. Introducing business systems may be considered (should be considered, in our opinion) as exercise in business process improvement, or even reengineering. The goal of any new system must be to work differently for performance and benefit. Stage one of the implementation must therefore be to define the future processes; these then drive the system selection and configuration – at least, they do in projects where the exercise is defined correctly. There are businesses out there that have gone down the ERP journey with the system as the driver, the tail wagging the dog. But that';s another story.

~ Ian Henderson & David Morgan ~

PHS Management Training - Copyright © 2017

For training or a consultant call
01565 653330

Enquiry form