Business Process Reengineering - Introduction

From RiskWiki

Jump to: navigation, search

Contents

About The Author & The Article

Jonathan Bishop, Group Chairman, Bishop Phillips Consulting. [1]

Copyright 1995-2012 - Moral Rights Retained.

This article may be copied and reprinted in whole or in part, provided that the original author and Bishop Phillips Consulting is credited and this copyright notice is included and visible, and that a reference to this web site (http://RiskWiki.bishopphillips.com/) is included.

This article is provided to the community as a service by Bishop Phillips Consulting www.bishopphillips.com.

Special Note: We have received a number of enquiries as to whether there is more detail available on this article. The answer is yes - a lot more. We are endeavouring to convert the balance of the Process Reengineering Method into wiki format as quickly as possible and we promise to have the rest of the manual loaded to the wiki soon. The conversion effort requires changes to the text format, the style and the detail provided, as the original was written as a manual for staff and clients, and makes some assumptions about pre-existing knowledge. We are also updating the content at the same time. As the charting method is a fairly involved, we will also be providing examples of systems charted using the method. This chapter is the introduction chapter, which provides a reasonably good overview of the approach.


Definition, Purposes & Outcomes

Definition

Image:BusinessComponentObjectives.png

Business Process Reengineering (BPR) is the method by which the infrastructure, policies, procedures and practices of an organisation are reviewed and redesigned to achieve some predefined purpose and objective. Purpose and Objective differ in that the purpose describes the reason for the process while the objective is the reason for the reengineering of the process. The objective is generally the optimisation of the quality - cost relationship, but may be any other objective(s) defined by the stakeholders of the processes revised.

Hammer, a popular author of reengineering texts defines reengineering as : The fundamental rethinking and radical redesign of business processes to bring about dramatic improvements in performance. Essentially, he argues that BPR is about major change in an organisation, yet perhaps this reflects a rather naive preoccupation with “big-is-better”. BPR can be about constrained well focussed small scale redesign as much as about monolithic reconstruction.

BPR is not new, although many consultants in the field try to claim otherwise. It is simply one more evolutionary step in a long stream of management change processes that includes Statistical Quality Control, TQM, Internal Audit, Work & Job Redesign, Goal Focussed Management, Workflow Management, Systems Analysis, etc. The theoretical foundation in BPR is quite old and can be seen particularly in the work in Systems Analysis undertaken at the University of Lancaster since 1969. What is new about BPR is its holistic view of the organisation and its attempt to capture the management philosophies that preceded it into a single integrated method.

Perhaps due in part to its conglomerate nature there is little standardisation among BPR approaches nor agreement on what is, or is not, BPR. With a few notable exceptions, the literature tends to be long on promises and case studies claiming stratospheric success but short on detail. This manual attempts to provide both a definition of BPR and an integrated strategy of analytic methods for performing it.

Although significantly different in approach from the work in systems analysis of the University of Lancaster, the development of our method owes a fundamental debt to the conceptual insight of that team. We have borrowed concepts, however, from a wide domain of disciplines ranging from accounting to computer science, and from psychology to marketing. It is not intended that the analytic tools of the method be cast in stone by this manual. No approach is perfect, and if this method is not seen to embrace its own continuous improvement then it will be as flawed as the business systems it purports to improve.


Purpose of BPR

In a BPR exercise we consider all aspects of managerial responsibility - from the organisation design through to the procedures and practices adopted. The BPR project does not attempt to define the purpose or the objectives of its systems of the organisation, rather once defined, it provides the machine to deliver that purpose and objective(s).

The method used in the reengineering process must deliver a complete description of that machine. This include the organisational structure, the behavioural paradigm, duties, controls, performance indicators, policies, procedures, data management, continuous improvement procedures, computer systems, etc, etc.

It is easy to confuse the activity of BPR with that of computer systems implementation, since many of the forces driving a BPR exercise beg computerisation as the easiest way to achieve apparently dramatic improvement. This is a mistake. Implementing computerised solutions is not the purpose of BPR, although a computerised solution is one of the tools a reengineer may use to implement some part of the processes and a BPR component .

Nor should we rely on computer solutions to all cases. While it is often true that the computerisation of a process will deliver significant improvement in the ratio of output volume and quality to human effort (input), when viewed from a holistic perspective (which includes infrastructure, investment, opportunity cost, and solution responsiveness to change) the computerised solution may not always be as attractive as first thought. Not withstanding these comments, a planned change in information systems provides a common and sensible catalyst for the BPR programme.

Essentially, the purpose of BPR is to build business systems able to deliver the organisation’s mission while optimising some given combination of objectives. In building the system, we must apply appropriate analytic techniques and appropriate implementation strategies. The weaker the constraints on the process applied by management - ie the wider the range of options left on the table for consideration - the more successful (in terms of optimising the objectives) the outcome is likely to be. The purpose of the system either will or will not be satisfied by the system design options made available - the quality of that delivery is measured by the objectives.


Outcomes

Image:BPR Components.png

The result of the BPR project is a working system tuned to optimise some combination of objectives in delivering the stakeholder’s purpose. It is defined by a set of system descriptions, or views of the system, which consider, categorise and structure the matter from a number of angles.

Illustrated in Figure are the key components of a system description produced by the BPR method detailed in this manual. There are many differences between the approach presented here and the convention literature on BPR both in method and outcome. Henceforth we shall refer to this approach as the Bishop BPR (or BBPR) method.

The method produces a process and organisational rework that is naturally integrated with risk and compliance governance systems and (in its detailed delivery) uses a unique charting system which blends computational and human processes together in a common stuctured and testable form.

We have used and progressively improved the method detailed in this text since the late 1980's and it has been applied in the delivery of consultancies to well over several hundred organisations covering non-profit, government and corporate sectors. It has been applied in its pure form as a process reengineering system, in reduced forms as an internal audit systems audit process, a business systems design model (for design and development of business computing systems), and with various strategy enhancements as a business strategy planning tool. While this author has brought it to each consulting organisation with he has worked or lead over the years, it has benefitted from the ideas and contributions of many collegues.

We shall explore the BBPR method throughout this text and provide the tools and techniques necessary to deliver the BBPR system description. Here we provide a brief introduction to the ten key descriptive outputs in the figure:

Descriptive Output Meaning & Purpose

Key Performance Indicators & Benchmarks / Targets

Performance management - how we directly manage and monitor the achievement of the system’s purposes

Active Control Management System

Internal System Integrity - how we directly monitor and manage the achievement of the system’s objectives.

Organisation Design

The objects/entities and their roles with their managerial, behavioural and reporting relationships identified.

Decision Tree

The tree (or Information Map) charts the decisions required by entities in the system, the relationships between the decisions and their information needs

Process & Workflow Charts

The sequence of activities making up the functional components of a system.

Event Calendar

The timing of events and their cycles and the processes they trigger

Client Provider Service Agreements

The objects/entities comprising the system seen as pairs of clients and providers (of services, data, goods, etc) emphasising their respective duties. The approach establishes notional contracts or service agreements which outline each entity’s responsibilities in the client provider relationship.

Data Management

The data stores in the system, what the data represents and how this data is managed

Continuous Improvement System

The strategy for delivering system improvement on a continuous basis.

Implementation and Change Strategy

The approach to managing the implementation of the reengineered system in the organisation and particularly managing people through the change process.


The system description is only the ‘record’ of the real outcome of the BBPR approach - that of business performance improvement through better business processes. The ABPR method produces a system designed to optimise certain predefined objectives (such as cost of inputs to quality) while the system description attempts to formalise that system and provide the mechanisms for monitoring performance, and maintaining and tuning that system.

In the model organisation, the approach starts with the strategic plan of the organisation (or unit) being reviewed and uses that plan’s components (vision, mission, key result areas, critical success factors, strategies, key performance indicators, targets and timeframe) to focus the design effort with purpose and objectives. In the real organisation, planning is generally something less than perfect, so we must employ a wider net in defining the focus of the BPR exercise. Once armed with a focus, a wide variety of sources and analytic tools are employed to build a business system which will best achieve management’s plans.


The Analytic Method & Its Tools

The Structure

At the heart of the ABPR method is a set of ‘analytic tools’ (methods) that help define views of a system that highlight the particular properties in which we are interested. The key components are illustrated in Figure 1

Image:BPRAnalyticStructure.png

The analytic method is based on a simple premise:

A System is comprised of Recursive Objects only. Any system can be described by four types of Objects: Entities, Data Stores, Maps (Processes), and Quality Managers (Control/Performance Criteria).

The simple dataflow diagram of Figure 3 shows a basic system. Entity A provides data to Entity B via a single process (under the control of Entity C) which maps the data from one data store to another. The performance of the mapping process is managed by the quality control process under the control of Entity D. The quality control process is approximately equivalent to an engineering feedback loop.

Image:BPC4KeyChartObj.png

Mapping is a computational and mathematical term which describes the mechanism by which data is transformed from one state or form to another. In a business process that transformation might be a simple as the act of transcribing an invoice from its physical (eg. paper based) state to an electronic record in an accounts parable system through the process of data entry. The data in its input state may be said to have been mapped to another state through some process of transformation.

The computer engineering reader will recognise the similarity of the diagram to a dataflow model.

The logical starting point of a BPR exercise may seem to be the Performance Criteria definition (assuming that the overall purpose if the system being improved is already known), but it is important to note that each of the four definition activities should continue concurrently throughout the project. It is not unusual for the Performance Assumptions to change as a result of the other BPR activities, and virtually certain where the project is a Strategic Planning exercise.

This mixing of strategy planning and BPR may at first seem a little unusual, but in the impact of the BPR analysis can be to cause a fundamental rethink of the business strategy itself. Where the focus is merely to re-design a specific, targetted transactional process such a strategic impact is, perhaps less likely, but where the targeted business process is the core of the business, such an impact is surprisingly common.

In particular the KPI definition both commences and completes a project. The table lists these key analytic tools and provides an overview of the activity. These tool classes are typical of those employed, but not necessarily the only ones appropriate to any given project.


The Modelling Tools

Analytic Tool Class Meaning & Purpose

KPI Assessment

In an ideal organisation the planning documents establish the focus for all activity. Our search for the focus of the BPR must therefore begin with the planning and policy role of management. Where available, sources to be reviewed include:

  • Statement of System Objectives
  • Corporate Plan
  • Budgets
  • Benchmarks


Organisations are rarely ideal and other techniques will need to be applied, depending on the culture of the organisation being reviewed. Such techniques may include SWOTC (Strengths, Weaknesses, Opportunities, Threats, and Constraints) analysis, benchmarking, corporate goal setting, interview, etc and may need to be undertaken to establish the purpose and key objectives of the system being reviewed.

Armed with this information the first view of Key Performance Indicators (KPI) appropriate to the system should be definable. In a sense, the KPI’s are like the gauges and alarms of an airplane, car or any other mechanical device. They alert the system’s ‘pilot’ to the status of the machinery, and allow rapid identification and adjustment of the system if anything ‘goes wrong’. In this sense the selection of the correct KPI’s is critical: if there is no gauge for a problem occurring it may not be detected until the problem is obvious without the help of a gauge - and possibly too late to be repaired.

In this first, top level assessment the KPIs will generally be whole-of-system measures. As other components of the ABPR are resolved (such as the Process Mapping and the Client Provider Analysis) the process detail level will emerge which becomes organisation’s operational ‘alarm system’. The ABPR has a specific design paradigm called Active Control Management to implement this KPI based control system in a cost efficient manner.

Client-Provider Analysis

A technique adopted from TQM which classifies the entities creating, managing and consuming data in the system as clients (data recipients) or providers (data suppliers) of one another. In performing the analysis we turn to information sources such as:

  • External Clients & Providers
  • Internal Clients & Providers
  • Organisation Structure
  • Roles & Duty Statements
  • Implied Contracts

While it is important to understand the organisational structure as it stands - because, among other things, it dictates the client-provider relationships, it should not necessarilly bind the designer. An organisational model reflects legislative, cultural and historic traditions that may be critical to retain, as well as (possibly) many years of legitimate experience among the management team in the industry and market in which you are working. It must not simply be disregarded in the BPR process in favour of radical change.

Indeed, the author generally advises against too ambitious an organisational change, unless change is part of the culture or intended management strategy. In some organisations, frequent re-organisation is part of the management ethos, and such an approach is as legitimate and successful a management model as any other. One must, nevertheless, be careful in taking the existing structure (or management ethos!) as a given - particularly where the organisation is seeking a competitive edge beyond mere marginal improvement in efficiency or quality.

The BBPR method uses its own method of analysing organisational structures called The Organisational Community Network Model (which is one of the reasons that the BPR method frequently impacts organisational design). This approach is appropriate, even where the organisation will aubstantially retain it's orginal shape after the BPR project as it leads to a highly efficient and focussed "desk top" test process architecture, and where the option for organisational redesign is on the table, can lead to a very radical outcome.

Stakeholder Analysis

The direct stakeholders are addressed in the Client Provider analysis, while the indirect stakeholders are addressed here - in the Stakeholder Analysis.

Essentially the indirect stakeholders provide the organisation with drivers & constraints. Typical sources include:

  • Legislative Obligations
  • Cultural Expectations
  • Reporting Obligations

Data Store Catalogue

The catalogue is the BPR equivalent to a data base administrator’s data dictionary. It describes all the data stored by the system, and the data stores themselves. It specifies the access rights, custodianship rules, data integrity standards and the static relationships between data stores.

Data stores include all the data managed by the system and methods of temporary or permanent storage. Data stores include electronic (abstract) and physical storage such as documents, files, filing cabinets, in trays, bins, etc.

Data Integrity Standards must be established system wide to which data stores adhere. The standards should be consistent with those applied by quality managers.

Process Mapping

Perhaps the most involved of all the activities of the BPR exercise. Process mapping is a general name for a variety of procedural analysis and design activities. The information sources include:

  • Functional Description
  • Cradle to Grave Tracing - System Walkthrough
  • Manuals
  • List of Data Sources & Destinations
  • Client / Provider Mapping
  • Data Load Analysis (transaction volumes, processing rates, etc)


The key activity during process mapping is the production of the Data flow diagrams and supporting documentation. This is done in two streams simultaneously:

  1. Existing systems
  2. Redesigned Systems

The data flow charts form the basis to the reengineering. They combine all aspects of the other analytic tools and describe the algorithm of the system.

In process mapping we treat all processes of a system as operating concurrently and control their timing and behaviour through messages, which take the form of either data or events.

The process map is not complete until the system data loading has been assessed for each process. The data load analysis involves examining data volumes and processing times, throughput assessment, reliability rates, etc.

Decision Tree / Information Mapping

The system handles not just data but information. Data becomes information when it exhibits certain quality characteristics. Information data must be appropriate to its purpose and reliable (where reliability implies standards of timeliness, accuracy, completeness, etc). Information mapping involves matching the data managed by a system to the decisions that must be made in operating that system. It requires, in part, the construction of a detailed decision tree spanning the entities in the system over time.

Necessarily, it also implies the existence of an events calendar which should link into the data flow diagrams. The information map includes a the information needs of the quality managers, and may be expressed in whole or in part through the Active Control Management design paradigm detailed later in this text.

The information map will require consideration of issue including:

  • Information Requirements
  • Event Calendar
  • Reporting Obligations
  • Performance Control Management System (eg ACM)




Organisational Representation (Introduction)

When we think of organisational representation, we traditionally think of the heirarchical organisational chart. Resenbling an inverted tree, the organisational chart provided by almost all charting packages represents a cross between a reproesentation of physical or geographic position and reporting lines - and tells us very little about how a business organisation is really organised. At best it leads to a bureaucratic semi-accurate organisational view, and at worst, it is wildely incorrect such as in Matrix organisations.


As with many traditional diagramming systems it is horrendously inadequate for all but the grossest simplification of an organisation.


In the BBPR, we us a Community Network model which provides far richer analysis and directly represents the positioning of an organisation with its market and community.


Image:BishopsStakeholderCommunityModel.png

Community domains can be defined as required for the purpose of the analysis, but in the standard BPC model (SCNM03) - also known as Bishop's Model Stakeholder Network - all organisational functions and services are seen as belonging to one or more of 8 top level stakeholder communities:

  • clients,
  • customers,
  • suppliers,
  • partners,
  • custodians,
  • workforce,
  • governance, and
  • the public.


Each community is comprised of a mixture of the community service providers, enablers and consumers of community services sharing a common focus. Community members share common functional interests and therefore may be serviced with shared services (whether human, networked, or electronic).


The meanings of the communities are explained in detail below. Here we will draw out some specific features:

  1. The model conceptually splits "the customer" (she who pays) from "the client" (she who receives) - often they are the same, but when they are not (such as in many government agencies) is is a crucial difference.
  2. The model splits partners from suppliers, and moves contractors to the workforce.
  3. It simultaneously recognises several communities of governors in the governance community including finance, executive, internal audit, board, cabinet, regulators, parliament, external audit, shareholders, etc.
  4. Custodians community includes those communities entrusted with a multi year wealth preservation/accumulation and service mandate such as IT, Treasury, Asset Management, etc.
  5. The model embraces the public as a specific community to be managed as they are the ultimate source of all the other communities' members and specifically the group that can influence the governance community to legislate your organisation out of existence. This community is both the source of greatest opportunity while also being the least organisable community and the most potentially threatening. A stakeholder network organisation notionally endeavours to move all members of the public community to one or more of the other communities with more manageable risk profiles.


You can read more about the Stakeholder Community Network Model and the Community Network Theory of organisational design and analysis Stakeholder Community Network Model and the Community Network Theory of organisational design and analysis here.



The Process Representation (Introduction)

The full process charting model forms a language that can be represented either diagrammatically or descriptively. There are a number of different symbols and descriptive encoding rules, but in essence many of thesee enhancements are for diagramtic efficiency. The core of the charting system revolves around only a few symbols and the full model merely expands on these to provide a richer descriptive set, and more analytic detail with fewer diagramatic elements. The full model is described in advanced charting.


Image:DataFlow.png

In the figure, data flows along, and in the direction of, the arrows between the entities, data stores and maps while control data flows principally into, and out, of the quality manager. The crossed-rectangular shapes are entities while the open ended rectangular shapes are (file) data stores. The maps and quality managers are shown by circles.

Image:Entity.png

Entities are equivalent to people, machines, or processes external to the system being examined. In a sense they are givens in the system analysis, in that their functioning is assumed of a fixed standard and excluded from redesign. Those aspects of behaviour that can be redesigned are represented by the other three objects types.

Image:DataStore.png

Data Stores are objects in which data resides from time to time. The stores are not the actual data itself, merely a representation of it. In the ‘object oriented analysis world’, data exists in the form of messages between objects. For example, Two people (entities) talking to each other (exchanging messages). Messages are essentially transient and so, for data available to be available for any length of time, it must be stored. Data Stores include documents, files, database records, and desk in-trays, etc.

Image:Map.png

Maps are objects which perform an operation on data other than storing it. They transport data, change data, analyse data, update a database record, produce a report, authorise a transaction, etc. The term ‘map’ means ‘mapping data from one state to another’. Maps perform the transformations of a system, but they are concerned with data. For data to become information it must have the added dimension of quality.


Quality Managers are objects which administer the performance of the system. The quality manager does not transform the data handled by the system, but rather manages the system itself. Quality managers rely on the KPIs of the system and its component parts measuring variance from plan and performing the appropriate remedial action such as tuning Map parameters or escalating the problem.


In one sense the Quality Manager is a kind of process, but its responsibility is to modify the behaviour of the system in accordance with the purpose and objectives of the system and is therefore fundamentally different from a Map which represents the embodiment of that purpose. In another sense the Quality Manager is a kind of reactive data store - it both stores data and responds to it. The quality manager deals principally with control data, although this is by no means exclusive or necessary.


Image:RecursiveShapes.png

Objects are recursive, and therefore may contain more objects of the same or different type. For example, a file contain documents (both data stores), a document contains fields (more data stores), an organisation may contain people (both entities), an organisation (entity) may contain functions (maps) while a business cycle such as Purchasing (a map) may contain an entire system of roles (entities), procedures (maps), KPI’s measures (quality managers) and documents (data stores).


Processes (maps & quality managers) are concurrent. This means that, unless restrained by a lack of input (data to process) or awaiting an event, each process is trying to operate at the same time as every other process. This reflects reality - people do not follow a neat sequential order when interacting with one another unless explicitly constrained to do so. Instead, they operate simultaneously, at different speeds to one another, and in self chosen patterns. To model the world correctly we must also model this behaviour


You can read more about the process charting method in Business Process Reengineering - Process Charting



The Analysis Tools

The designed system will be documented with data flow charts, client-provider “performance agreements”, ACM control checklists, a decision to data source matrix, task schedule sheets cross-referenced to the data-flow diagrams. These facilities can be provided both electronically or on paper as desire by the client. The degree to which the processes and documentation can be automated is restricted only by the client’s computer system capabilities and software.


Process Representation Using Software

There are a number of practical charting tools that can be used. For 2D representation, we recommend either ABC Flowcharter or Visio, while for 3D client walkthrough of a designed system we recommend a MMORG such as SecondLife (http://SecondLife.com), or TrueSpace (http://www.caligari.com/).


With respest to to the 2D tools, both suggested tools have their strengths and weaknesses. Visio has excellent microsoft integration desktop application, and is directly supported by a number finance and business applications as a business process modelling environment. ABC Flowcharter, has (in our view) a shorter learning curve) and and excellent interface, and good integration into MS documentation tools.


In choosing a 2D tool you should consider:

The tool should support diagrammes:

  • consisting of many linked pages
  • with recursive (self referential) structures
  • graphic object drill through (ie. you can select an object such as a process which summarises many sub-processes and link to one or more pages that represent the steps in the process
  • containing graphic objects with unique id's, text descriptions, and other user defined data attributes that can be stored with them (eg transaction volumes, costs, probabilities, risk assessment, etc)
  • editable splines for connecting shapes (bendable curved lines)
  • with point and click editing
  • with user defined shapes and image import
  • that represent the Bishop Phillips Process Modelling shapes.
  • containing URL links at at least the graphical object (including lines) level (ie. linking an object to a internet/intranet page)
  • that can be imported into text documentation and presentation tools (MS Word / MS PowerPoint, etc) compatible with your business environment (standard desktop)
  • that ideally can be scripted with a scripting language that allows active simulation or calculations of events and transactions occurring (optional - but a good idea)
  • that can be generated driectly from an electronic drafting whiteboard (optional, but saves you a lot of time).


3D tools are a much newer approach. The biggest advantage of a 3D modelling tool is that you can 'walk' the client through the business process. Possibly the only practical & right-priced ones available at the moment are SecondLife and Caligari TrueSpace. Over the years we have tried a number of approaches to this idea, until the advent of SecondLife, we built our 3D models in TrueSpace. TrueSpace is a serious 3D modelling environment, and while simple to learn, as 3D graphical modelling environments go, it is not a tool for novices, although it does produce spectacular 3D models, it is not so suited to walking the client through the model as presenting a canned 3D visualisation of the business model. Recently it has gained a MORG add-on/representation and linked with one of a number of games engines it can be used quite successfully as a walk-through environment.


With the advent of second life (and the growing number of similar MORG systems that are either appearing now or soon to appear on the market), and more practical and faster solution is available (all be it, less visually stunning in production quality). A SecondLife based model allows you and your client to literally enter the model as people and walk or fly arround the components of your system, watching transactions visual flow through the process, event occur, control systems filter errors, and output being produced at varying transaction rates. The building interface is fast and simple to learn, and the scripting environment allows you to rapidly simulate many different scenarios.


With such an approach you can literally have your client see the transactions flow through a virtual representation of a system (a bit like the movie 'Tron'), or build a representation of their physical environment (such as a building, or office floor) and simulate the behaviour of the people and the control system operating. The world-wide scale of MORG users means you can contract the development work to inexpensive professional builders, instead of building it yourself.


The great weakness of these environments is that they are not yet real time in terms of construction (where as a 2D chart can (almost) be built in real-time as your client describes their processes, and documentation in conventional 2D media is not a natural consequence of a 3D simulation (whereas 2D charts can be included in text based documentation with ease).


In choosing a 3D tool you should consider:

  • speed of construction of 3D elements (ideally you will need a 'primitive' rather than 'mesh' or 'nurbs' based building solution for speed.
  • scripting language and partical system support (essential)
  • ability to script primitives (objects) concurrently on a massive scale
  • message passing support
  • ability to create avatars (or primitars) that can interact with the model (ie. walk around inside it)
  • availability of low cost developers/builders
  • ease of installation of appropriate client software
  • ownership and permanence of the 3D models built
  • support for importation of textures (graphic images), sounds, animations, 3D objects, movies, etc.
  • real time in-world multi participant speech support
  • simplicity of visitor navigation (i.e. how hard is it for a first-time user to just walk around in the 3D environment)
  • URL (web page) linking
  • URL (web server data sending and receiving - eg Can you request and receive data from an off system database).
  • web page display on objects (not commonly available)


Analysis Support

A number of analytic tools or design paradigms are incorporated into the ABPR. A few of these are introduced in the table:

Analytic Tool Or Design Paradigm Meaning & Purpose

Data Flow analysis

A method of charting systems enhanced by BPC with concepts drawn from process mapping, predicate calculus, TQM, CPM (Operations Research), Entity-Relationship modelling, and a number of other analytic methods. This method excels at depicting simply, complex data flows and process interactions. It traps control issues, timing constraints, events and information flows.

Active Control Management System

Although not critical to the process, ACM provides significant advantages in process efficiency. An BPC specific control design philosophy based on experiences in the areas of Corporate Governance and organisations adopting control devolution and/or multi-skilling. ACM represents a significant shift from the control paradigm of periodic audit review with heavy transaction based testing conventionally adopted by Internal Audit and traditional views of control system design relying on segregation of duties.

To build an ACM control system, we begin by expanding the definition of controls beyond accuracy, authorisation, completeness (,etc) to include process timeliness, achievement of business plan targets and other business objectives. Next we identify the controls appropriate for monitoring and we collect all the associated control data into a common recording format (and ideally automated storage system - such as MS-Access). Lastly we build a reporting framework for system performance monitoring built on the quality managers.

ACM produces control compliance information in a steady stream for the senior executive and board rather than intermittent or cyclic audit reviews often used. The compliance component of any Internal Audit unit is re-focussed to ensuring the ongoing reliability of the control compliance reports. The control system is integrated into the business processes using the Client-Provider model developed at the start of the project. ACM reporting can be automated, if desired.

Network Organisation Reduction

The process of defining the organisation into the community network structure forces the reduction of many diverse strategies and procedures into a clearly identifiable set of activities required for one of 11 broad service communities. The networks implie the stakeholders in an enumeratable set of collective Client Provider Service Agreements.

Process Dictionary

Used to assist in the identification of opportunities for streamlining cross and intra organisation systems, the a Process Dictionary catalogues and describes each process within any business function in accordance with an agreed selection of descriptive terms.

In this way, assists in highlighting common processes and assess whether it is possible and appropriate for these to be combined or shared in some suitable form.

Summary: Characteristics of the BBPR Method

Business Process Reengineering (BPR) is the method by which the infrastructure, policies, procedures and practices of an organisation are reviewed and redesigned to achieve some predefined purpose and objective. This chapter has provided an introduction to the concept of BPR and an over view of the ABPR method. Both of these will be developed throughout the text.

Essentially BPR represents the focussing of an enormous body of theory and expertise underpinning management science into a single - all powerful redesign strategy. Such a panacea does not exist, and we must be careful to use BPR where the fundamental organisational characteristics are present. These might include:

  • A discernible consistent set of purpose(s) and objective(s) exist
  • Design options are not restricted out of the solution set (ie. an acceptable solution is achievable despite imposed constraints)
  • Senior management authorise and staff support the project and the process
  • The analytic tools match the problem set
  • BPR Consultant has credibility with the staff


The BPR process is best seen as a framework encompassing a wide array of analytic tools and organisation/management design paradigms. Many of these tools and paradigms can be expected to change over time as management theory is revised, while some are central to the BBPR framework. The central tools and paradigms include:

  • KPI’s & Quality Management
  • Data Flow Analysis
  • Object Oriented Process Engineering
  • Client Provider Analysis
  • Information Mapping
  • Data Cataloguing

As an extremely simplified explanation, the BBPR method uses KPI’s to focus the system, and classifies the proponents in the system as clients and/or providers of data (etc) to one another. The client/provider relationships, are revised using a separate information (decision) map reflecting the information needs of the direct and indirect stakeholders. With the revised client/provider relationships defined and the data and information needs catalogued, process maps can be defined which reflect only what is needed to implement the system.

For the sake of clarity, in this introductory chapter, we have excluded many of the more complex issues facing BPR. One of these is the positioning of organisation design in a BPR exercise. It is a significant issue as it is inextricably linked to the culture of the organisation being reengineered. I t usually included to some extent in the design options, but rarely is the organisation design entirely at the discretion of the reengineer. Accordingly we must treat it as both a given structural component of the client provider analysis and an output of the process mapping (design phase).

Clearly the process mapping will impact the organisation structure which will in turn affect the client provider relationships while the client provider relationships affect the process mapping, etc. It is for this reason and a number of similar circular relationships among analytic components that necessitates the simultaneous analysis & design activity of the ABPR method.



BackLinks




CopyRight Bishop Phillips Consulting Pty Ltd 1997-2012 ( Business Process Reengineering - Introduction )
Personal tools