Organisational Redesign (Business Process Re-engineering) (BPR)

This article provides an overview of Business Process Re-engineering (Organisational Design), including types of organisations, the reasons for a strategic review of organization & processes, the method of doing so, and some of the problems.

Links to other Best Practice and Training at bottom of page

The Problem

In a small business the owner does everything. As the business grows the owner has to employ functional specialists to which he or she delegates certain aspects of running the business. Over time these functions expand to a point where they become departments, and often barriers are erected (often physical) between departments. As documents, materials and information flow between departments, delays start to occur as they pass from in-tray, to out-tray, to in-tray again. Often defensive systems such as date stamping and countersigning start to emerge as one department blames another for a mistake or delay. Office politics emerge. Complicated procedures emerge. As they expand, departmental hierarchies are created and departments relocate creating communications difficulties. The business products or services change. Paper work, meetings, computer systems and conference calls, grow in an attempt to counteract these difficulties to an extent where it is actually almost impossible to co-ordinate activities and get things done. It is at this point that the objectives of the organisation can actually be in conflict with the current organisation and procedures, and costs go through the roof.

This is the time to sit back and think there must be a better way!

Organisations

There are basically three types of organisation:

• Functional
• Project
• Process

Matrix organisations are a mixture of these, where you will have for example a functional manager and a project manager. These are often called "dotted line" relationships, particularly where an executive at HQ has a functional role. The difficulty in these relationships is that the compromises, that are often necessary to satisfy two bosses, are not defined properly with rules of engagement (or terms of reference), which often results in pleasing neither.

Processes

• A function is a collection of activities relating to a skill-set, person or institution, frequently referred to as a department.
• A project is a series of related and loosely related one-off tasks designed to produce a one-off or small volume output. Implied in project work is the co-ordination of different specialists, in large-scale longer-term undertakings.
• A procedure is a series of actions carried out in a certain order or manner.
• A process is a sequence of logically related activities, tasks, or procedures with a goal and leading to an outcome. A process can cover a number of people in different functions. In fact it is independent of function. An example might be that the accounts function do credit checking on a new customer, as a part of the sales process according to a procedure.

BPR

This is where "Business Process Re-engineering" ("BPR", "Business Process Re-design", or as it is sometimes called "Organizational Redesign") is useful. BPR generally approaches the problem from the point of view of the (internal or external) "customer" and of the whole process. Customer views are required to ensure that the eventual design actually satisfies them. Process views are required to try to remove the in-tray / out tray problem, and to focus activity within the process on its goal, not individual functions, so that unneeded or irrelevant activity is removed. However the functional organisation has strengths too, in greater critical mass and therefore (in theory) flexibility and resilience. There are therefore a set of arguments as to whether functions should be centralised or decentralised. These need to be considered.

There are five stages to a BPR development project:

Stage 1: Define the need (“To Be”), approach & priority (the design criteria for the new process & the scope & priority of the proposed development)

Outputs of Stage 1:

• Current symptoms of  the 21 barriers to lean & agile processes (wastes)
• Clear view of prioritised actions derived from business plan:
  • The competitive position / required performance characteristics
  • Critical Success Factors (CSF's) for the business (what you must be good at)
  • Subjective view of process quality (the extent to which it is contributing to the CSF's
  • What options are possible (from Benchmarking)
  • A SWOT analysis of the situation Required (“To Be”)
  • Scope of proposed development (BPR / other projects)
  • Justification / Budget for the project(s)
• How the project will be managed

Stage 2: Agree the current “As-Is” process

Outputs of Stage 2:

• A clear, unambiguous, agreed, documented, understanding of the current (“As-Is”) six drivers of performance and the whole process ready to critically analyse verses the requirements established in stage 1

Stage 3: Analysis & Concept Design of “To-Be” (Ideally, in outline, how we want the new process to work)

Outputs of Stage 3:

• An innovative, lean & agile proposed process, which is realigned to and meets the requirements established in stage 1
  • A simplified, reorganised, responsive, proposed process with waste removed
• Control systems established to manage the proposed process
• Quick wins identified
• Risks identified

Stage 4: Detailed Design (How “To Be” will work in detail)

Outputs of Stage 4:

• A proven, detailed design of the proposed process & control systems to make work flow & manage dynamic states
• Floor plan
• Resource requirements
  • Proposed computer systems, Equipment, Materials handling, Skills required
• A costed implementation plan of the new process
  • Justification (cash flows) of the new process (implementation & running costs)

Stage 3 & 4 have to consider not simply average conditions, but also anticipated dynamic conditions, so perhaps a little more explanation of design is needed:

Steady State Design

This takes a snapshot of the situation and defines the processes, simplifies them, removes waste and redesigns them using average requirements. The main considerations for steady state design are::

• Purpose of changes (objectives of new process)
• Takt Time (The underlying average demand for the product or service) (See Previous Technique of the Week 021: "Takt Time")
• Average resources needed for the new process and constraints within it

Dynamic Design

This takes a view that all the variables have not been eliminated and that the systems need to function in adverse, cyclic / seasonal, or dynamic circumstances, and that processes rarely operate in "average" circumstances. The main considerations of dynamic design are:

• Variables defined (input, process, output)
• Flexibility defined
• Control systems selected
• Buffers required to accommodate variability defined (stocks, resources)
• Mechanisms for responding to variability defined
• Mechanisms tested
• Measurement & control systems defined

Stage 5: Implementation, Institutionalisation & Improvement

Outputs of Stage 5:

• Handover of the new process to operations
• Institutionalisation of the process (Standard working / auditable)
• Realigned culture & behaviour
• Measures of performance to drive Focused Improvement Systems (FIS)
• Post implementation review to ensure the benefits have been achieved & the lessons learned

Scale

 There are two schools of thought on the scale of BPR:

1. It has to start from a strategic view or you will simply be making a low level activity or function more efficient (sub-optimising).
2. It has to be done on a small scale to deliver anything within a satisfactory time-scale and budget and also minimise risk.

Frequently BPR are IT are either separated or piggybacked in a software implementation or in a process redesign, for similar reasons.

All of these views are correct:

• Large scale BPR is a great revenue earner for large consultancies, but can cause chaos in implementation (High risk but without the opportunities presented by IT can be sub-optimal).
• Small scale BPR at a department level can be making a function efficient doing unnecessary things when viewed from a higher level (Small effect).
• BPR without appropriate technology / IT makes for effective but often inefficient operation. It can also lead to not exploiting technology to do something that is otherwise impossible (Solving the wrong problem).
• BPR in conjunction with major technology / IT change has resulted in catastrophic short-term effects, with large projects often in major over-run, but usually with the best long-term outcome. (Very high risk, very high benefit).
• In software implementation or computerization, organisational and procedural matters are often forgotten resulting in automating an ineffective process, or applying an inappropriate technique, or layering the new software processes on top of the old ones, duplicating the work and eventually failing. (Low risk, little or no benefit). (See Implementing ERP Computer Systems).

Resources

There are a further four considerations on resources for BPR projects.

1. The best people should be assigned to the project on a full time basis for the duration of the project, (and usually given the plum jobs in the redesigned business). This may give short-term difficulties since these people are the main people running your business today, but delivers the best results and simple project management.
2. Part time and sub-contract resources are sometimes used to undertake the project. This keeps your business running but usually the project management is difficult. In smaller businesses this may be the only way it can be done, but the results are generally not so satisfactory.
3. The process should be participative to overcome resistance to change, (not invented here), which is often encountered on imposed solutions.
4. It will be difficult to overcome inter-function disputes, and remove the politics from the process unless the project is managed by a senior person, and is representative of all the stakeholders, with local knowledge.

Impartial outside help can alleviate these problems but does not solve them.

Project Management

Regular project management reviews by senior executives should prevent terms of reference drift, as well as control project quality, cost and time-scales. We cover this topic in our training courses S08: Programme Management. & S09 Project Management.

Tools and Techniques

The tools & techniques of BPR include:

• Purpose analysis (To identify the objectives.) (See "Focused Improvement Systems")
• Competitive comparison (Competitive criteria plus SWOT analyses)
• Process Quality Management (PQM)
• Strategic Capacity Analysis:
  • Resource capability (CARAT analysis)
  • Core competence
    • Make vs. Buy Analysis
• Critical Success Factors (CSF's) vs. Performance Drivers Analysis
• Change management (Force field Analysis & Relationship Mapping) (To identify cultural constraints)
• Brown paper flowcharting
• Process Activity Analysis is our own (superior in terms of comprehensiveness and identifying waste, in our view) brand of what is sometimes called "Value Stream Mapping" or "Flowcharting" (To identify current or future information, material, or document flows.)
• Waste analysis (To identify waste in the current process.) We use our three proprietary techniques to establish waste:
  • Complexity / Variability Analysis
  • Agility Analysis (Our 92 point self diagnosis) (See Agile Manufacturing) (Yes it is applicable to non manufacturing businesses.)
  • 21 wastes (which does include the original 7 wastes of Ohno) (see Previous Best Practice of the Week 41: "21 Barriers to Lean & Agile")
• Ownership Analysis (To identify changes of ownership of material, information or documents, during their life cycle.)
• Benchmarking (To identify alternative strategies, organisation, processes, procedures and methods.)
• Resource Domination Analysis, which aims to identify what products or services consume what resources as an aid to reorganising resources within a process, has been developed by us from what was originally called "Runner Repeater Stranger" analysis to produce more self contained processes.
• Product life cycle analysis (To identify whether investment in particular products and processes are worthwhile.)
• Pareto Analysis (To sort the wheat from the chaff, in products, processes, value, space utilisation etc.)
• Segmentation (A method of virtually, or actually segmenting the business or processes.)
• Input / Process / Output diagrams (A method of defining a process)
• Control Systems Design (A method of identifying appropriate control systems techniques for the new situation.)
• Measures of Performance Design (A method of identifying how the new process will be measured.) (See Focused Improvement Systems)
• Culture Development (A method of identifying cultural development needs.)
• Postponement and Mass Customisation Commonality Trees Analysis (A method of improving flexibility, and reducing lead times.)
• Impact / Ease Analysis (A method of identifying the appropriate things to develop and how to control their development.)
• Risk analysis, SWOT, and FMEA (Methods of identifying which aspects of the process or development are risky and which need close monitoring or preventative measures to avoid problems.)
• Simulation (One of the methods of testing the new design prior to implementation.)

We teach most of these techniques in detail in our S02 Business Process Reengineering training & others in detail in a number of our other courses (See below). However a significant innovative input is required to avoid into this process simply making the present process more efficient instead of more effective. This is provided by Blue Skies (breakthrough) thinking.

Some final words of warning!

When designing you are designing for the future. Neither you, nor I have a crystal ball, however you need to be aware of technology trends and innovations, and guard against adverse eventualities using sensitivity analysis, and contingency planning. I am aware of one large, multinational, organisation that disbanded a department designed to support integrated business processes & software, at a time when ERP software was just emerging. They had to reengineer the process shortly afterwards. (See "World Class Change Management" training.)

In the early days of BPR, we used to think that the outcome was a design that would last for ever. However we were surprised by several clients who said that they were experiencing difficulties less than two years after the BPR project was successfully (in everyone's view) completed! Of course some requirement had changed, which had not been foreseen and the design itself was too inflexible to easily assimilate the change. This has caused us to reengineer our dynamic design methodology considerably, away from conventional steady state, Value Stream Mapping approaches. Value Stream Mapping can & does provide quick wins on waste reduction, & is incorporated into our BPR training, but cannot by itself produce robust, long lasting, processes.

_____________________________________________

The following further best practice articles were also mentioned in this paper:

The following public training course and in-house workshop provides solutions to Organisational Redesign:

You may also wish to consider the following related training courses:

_____________________________________________________________________

To discuss your consulting or training needs with one of our independent consultants or trainers please Contact Us.

 Home Page

© SM Thacker & Associates (Consultancy and Training Specialists) April 2000 Version 4 February 2008