Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP Change Management BPR ISO9000 Business

Process Improvement I M ERP EFQM Financial Modelling TQM System Integration Workflow Implementation P L E M E N T I N G Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning Business Process Improvement ISO9000 Change Management BPR SAP EFQM Financial Modelling TQM System Integration Workflow Implementation Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP Change Management BPR ISO9000 Business Process Improvement Workflow Implementation ERP EFQM Financial Modelling TQM System Integration Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning Business Process Improvement ISO9000 Change Management BPR SAP EFQM Financial Modelling TQM System Integration Workflow Implementation Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP Change Management BPR ISO9000 Business Process Improvement Workflow Implementation ERP EFQM Financial Modelling TQM System Integration A balanced Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning approach Business Process Improvement ISO9000 Change Management BPR SAP EFQM Financial Modelling TQM System Integration Workflow Implementation Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP Change Management BPR ISO9000 Business Process Improvement Workflow Implementation ERP EFQM Financial Modelling TQM System Integration Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning Business Process Improvement ISO9000 Change Management BPR Advanced SAP EFQM Financial Modelling TQM System Integration Workflow Implementation performance Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP Change Management BPR ISO9000 Business Process Improvement Flexibility Workflow Implementation ERP EFQM Financial Modelling TQM System Integration Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning Business Process Improvement ISO9000 Change Management BPR SAP EFQM Financial Modelling TQM System Integration Workflow Implementation Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP Change Management BPR ISO9000 Business Process Improvement Workflow Implementation ERP EFQM Financial Modelling TQM System Integration Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning Business Process Improvement ISO9000 Change Management BPR SAP EFQM Financial Modelling TQM System Integration Workflow Implementation Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP Change Management BPR ISO9000 Business Process Improvement

Business Process Re-engineering

Implementing Business Process Re-engineering

Contents
1.0 Introduction
1.1 1.2 1.3 1.4

1 1 2 3 4 5 8 14 16 19 20 21 21 21 21

Methodology versus Intuition What Does a Methodology Offer ? Problems with Methodologies A Framework for Implementation

2.0 3.0 4.0 5.0 6.0

Identifying Processes for Redesign Process Visualisation Understanding Existing Processes Redesigning New Processes The Structure of Re-engineering Teams
6.1 6.2 6.3 6.4

The Re-engineers The Insiders The Champion The Public Relations Person

7.0

Conclusion

Tables
Table 1: Table 2: Table 3: Table 4: Table 5: Table 6: Table 7: Table 8: Two Re-engineering Frameworks Common Symptoms of Process Distress Davenport’s Method for Selecting Processes for Redesign Davenport’s Method for Process Visualisation Davenport’s Method for Understanding the Existing Process Process Methods Overview Davenport’s Method for Redesigning the New Process Level of Process Design 5 6 6 9 15 16 17 17

Figures
Figure 1: Figure 2: Business Vision, Strategy and Process Visualisation Hierarchy The Visioning Process 9 12

Copyright© CASEwise 1999

NOTE: REVERSE OF CONTENTS IS BLANK

Implementing Business Process Re-engineering

Implementing Business Process Re-engineering
R.F. Pearman

1.0 Introduction
Creating the new enterprise involves considerable change in virtually everything to do with people’s working lives. Rather than fixing the old, we set out to create the new. There is a fundamental transformation occuring in business - in terms of its structure, processes, people, and technology - as described in the first part of this series of white papers; "The Theory of Business Process Re-engineering". The primary objective of this white paper (part 2) is to examine how to go about reengineering business processes. Research in this area reveals that papers that actually deal with radical redesign are more difficult to find than papers that merely encourage the use of BPR. It is far easier to be converted to a new religion than to practise it1. This white paper begins with a discussion of the two opposing views that currently exist, i.e. whether re-engineering should be conducted from a methodical or an intuitive view point. We highlight the fact that it is difficult to assess the value of either approach because there are numerous examples relating to the success of both techniques. Therefore, we discuss only two approaches, one proposed by Davenport (1993)2 and the other from Hammer and Champy (1993)3, which contrast the differences between methodology and intuition. From these two approaches, we identify four steps that are of paramount importance in the re-engineering effort. We describe each step and compare the two practitioners' approaches. A brief discussion on the structure of re-engineering teams follows. This supports the analysis conducted in the third in this series of white papers, “Tools for Business Process Reengineering”, which identifies how the project team can use the CASEwise Corporate Modeler software to support a re-engineering project.

Lorenz, C., (1993), “Management: Uphill Struggle to Become ‘Horizontal’”, Financial Times.

1

2

Davenport, T., (1993), “Process Innovation: Re-engineering Work Through Information Technology”, Harvard Business School Press.
3

Hammer, M., Champy, J., (1993) “Re-engineering the Corporation: A manifesto for Business Revolution”, Nicholas Brealey Publishing.

1.1 Methodology versus Intuition
A number of approaches have been developed for business re-engineering. The most hyped by far is that proposed by Michael Hammer and James Champy in their book, Reengineering the Corporation. They focus on defining the “hard” aspects of re-engineering (i.e. process and enabling technology). The virtue of their book is its brevity, readability, and clarity. The book explains the "nuts and bolts" of the re-engineering process and illustrates them with case studies.

Copyright© CASEwise 1999

1

Implementing Business Process Re-engineering

Another book that provides a useful insight into the re-engineering effort is Process Innovation (Davenport, 1993). This book does a better but less readable job of relating all the soft and hard elements of re-engineering to each other. The primary difference between the two is "methodology" versus "intuition". Some BPR practitioners rely on a more intuitive approach, rejecting analysis in favour of what they see as a "higher level understanding". People in this camp believe that over-attention to current practices is an obstacle to breakthrough thinking4. They believe in starting with a clean slate and rely on their imagination and experience. For instance, James Champy states that re-engineering is "contextual" - i.e. it is a function of how an enterprise behaves, of its belief systems, of its position in the marketplace, and of the character of its people. Therefore, it is absolutely impossible to have a structured approach. However, the methodologists, such as Davenport, argue that sitting down with a blank piece of paper with no guidance on how to begin is dismaying. They observe that people who use intuitive approaches, although frequently becoming enthusiastic proponents of BPR, still end up not knowing how to do it. Roy Thompson, Principal consultant with CASEwise with many years experience of practical BPR projects in major corporations, states

Klien, M.M., (1994), “Re-engineering Methodologies and Tools: A Prescription for Enhancing Success”, Information Systems Management Journal.

4

BPR is itself a process, its steps can be easily described. However, the techniques employed at each step of a project are highly context sensitive which makes a BPR initiative appear intuitive.

The main distinction between the two approaches is that intuitive tells you “where to go” while methodological approaches tells you “what to do to get there”. The latter can be further decomposed into prescriptive and descriptive. Descriptive simply tells you what to do while prescriptive tells you how to do it.

1.2 What Does a Methodology Offer ?
Olle, T.W., Hagelstein, J., McDonald, I.G., Rolland, C., Sol, H.G., Van Assche, F.J.M., Verrijn-Stuart, A.A, (1991), “Information Systems Methodologies - A Framework for Understanding”, 2nd edition, Addision Wesley. Simison, G. C., (1994), “ A Methodology for Business Process Re-engineering?”, IFIP Transactions.
6 5

Olle et al (1991)5 define an information systems methodology as “a methodical approach to information systems planning, analysis, design, construction and evolution”, and characterise different methodologies primarily by their “steps” and “components” (or deliverables). The key idea of a methodology is that it has some level of universality; it can be applied or adapted to a variety of business domains4. Simison (1994)6 observes that using a methodology is appealing for a number of reasons. Specifically, it: • Introduces a minimum level of discipline into the task - the alternative to this is summarised in the classic example where a project team starts coding from the outset giving insufficient attention to analysis and design. Entails less effort and intellectual input than an intuitive approach.

2

Copyright© CASEwise 1999

Implementing Business Process Re-engineering

• •

Provides a means of codifying experience and ideas in a form which can be evaluated and tested. Facilitates planning and monitoring. In particular, the use of the same methodology from project to project allows metrics to be developed so that productivity can be compared and projects monitored. Establishes clear definitions for each step and the deliverables. This enables users to contract out individual tasks with confidence that there will be common understanding of what the contractor is required to produce and what inputs will be provided. Allows a standard set of skills to be identified and developed. There are obvious benefits in skills acquired on one project to be identified and developed for future projects. Is a prerequisite for the use of Computer-Aided Software Engineering (CASE) tools.

1.3 Problems with Methodologies
Apart from listing the advantages of the methodological approach, Simison (1994) observes that the IT profession has been less enthusiastic and successful in its adoption of the methodologies than might have been expected. This is consistent with the view of Hammer and Champy (1993)3. Furthermore, he states that the advantages outlined in the preceding section have been generally well recognised at the management level, but implementation has been poor. The reasons for this are as follows: • Most methodologies do not reflect “best practice”. Some of the more advocated methodologies are based on the view of how systems should be developed rather than successful practical experience. Common methodologies for information systems conflict with practice in the assumption that developers will work from “first principles”, treating each business situation as if it were unique in all respects. Developers frequently draw on past experience and assume a level of business knowledge that allows a specification to be drafted which is often incomplete. There is a danger that we incorporate in a methodology only those tasks that are readily incorporated. This can leave those that are not amenable to methodological treatment outside and at risk of being ignored. The use of detailed methodologies stifles creativity. The problem is not so much that methodologies do not support creativity, but that they fail to recognise and support design, of which creativity is an important aspect. BPR is recognised as a design process, requiring creativity, innovation and radical thinking. The risks to creativity of attempting to prescribe and use a methodology for BPR include:

Hammer, M., Champy, J., (1993) “Re-engineering the Corporation: A manifesto for Business Revolution”, Nicholas Brealey Publishing.

3

Copyright© CASEwise 1999

3

Implementing Business Process Re-engineering

Stifling creativity by attempting to break creative tasks down into smaller stages thus imposing rules that are not essential to meeting the overall objective. Focusing on peripheral tasks such as documentation of the current system because they are more easily dealt with prescriptively than major design tasks. Encouraging BPR practitioners to focus on “compliance” with the methodology, which can be achieved with deliverables of a given quality and form, rather than optimising deliverables beyond the level required by the methodology.

In this white paper, both approaches are discussed providing an unbiased view as to which approach should be taken when embarking on re-engineering. Furthermore, there are difficulties associated with assessing the relative value and efficacy of intuitive and methodological approaches to BPR as most of the reported case studies were of necessity intuitive, because no methodologies existed at the time the projects were done. In fact, the projects were recognised as BPR only after completion. At the time, they were conceptualised as something else. Michael Hammer who named re-engineering, recognised that some companies were obtaining extraordinary break-throughs in performance improvement, and he identified the common elements in the “re-engineered” solutions. A second difficulty exists in assessing the effectiveness of different BPR methodologies. This is because every consulting firm can provide references and examples of successful projects using their preferred methods. In addition, it is estimated more than half of the firms engaged in re-engineering projects do so without significant help from re-engineering consultants. It is often hard to define how successful some BPR efforts are, because the sought-after improvement goals are usually never quantified. Hence, conclusions are based on the project manager's understanding and insight into practical BPR and are supported by a number of arguments.

1.4 A Framework for Implementation
The subsequent sections examine a number of implementation frameworks, focusing primarily on those proposed by the well-known BPR practitioners, Hammer and Champy (1993) and Davenport (1993). Table 1. highlights the work of these practitioners. The reasons for focusing on these approaches are twofold. Firstly, they provide contrasting work that shows the differences between the intuitive and methodological approaches. Secondly, these consultants have been highly commended for their work in the area of business process re-engineering. The objective of the discussion and subsequent comparison is to provide the reader with a more complete understanding of practical business re-engineering and ultimately to assess the role and value of modelling and simulation in a BPR initiative.

4

Copyright© CASEwise 1999

Implementing Business Process Re-engineering

Table 1: Two Re-engineering Frameworks

It is possible to identify a common set of steps that are essential in the re-engineering process. These points have been identified through a review of literature covering the implementation of radical redesign. They are as follows: • • • • Identify Processes for Redesign Develop Process Visualisations Understand the Existing Processes Redesign New Processes

2.0 Identifying Processes for Redesign
The re-engineering effort must begin with a survey of the process landscape to identify processes that are candidates for redesign. Both the overall listing of processes and the focus on those requiring immediate redesign initiatives are crucial to the success of the reengineering effort. The selection process should aim to establish the boundaries of the processes that are to be addressed, this enables the enterprise to focus on those most in need of radical change. The approach taken by Hammer and Champy suggests that an enterprise uses three criteria to help them choose the processes that they should focus their attention on. They are: Importance, Feasibility, and Dysfunction. Importance expresses how crucial a process is to the enterprise, i.e. those processes that have the greatest impact on the enterprise's customers. Feasibility looks at whether a process can be re-engineered from technological, cultural or other concerns. Dysfunction looks at which processes are in the deepest trouble.

Copyright© CASEwise 1999

5

Implementing Business Process Re-engineering

Hammer and Champy primarily focus on dysfunction, listing the common symptoms of processes in distress and their related diseases. Table 2 below summarises this.

Hammer & Champy (1993) Re-engineering the Corporation Table 2: Common Symptoms of Process Distress

Hammer, M., Champy, J., (1993) “Re-engineering the Corporation: A manifesto for Business Revolution”, Nicholas Brealey Publishing.

3

Having identified a common set of dysfunctions within enterprises, Hammer and Champy stress that symptoms do not always point organisational physicians to the correct diagnosis3. Sometimes the symptoms can be seriously misleading because the evidence that a process is not working exists, but appears somewhere other than the obvious places. So, while data may indicate that something is broken, it may not indicate accurately which process is not working well. The three criteria outlined above must be used alongside the necessary business judgement to help make the right choices. They also emphasise the relation of the process to the strategic direction of the company, i.e. does the process have a high impact on customer satisfaction? Hammer and Champy do not provide specific walk-through steps that, when implemented, will identify the necessary processes. However, they do provide a set of ideas for how to tackle the problem, e.g. where to go, which is a primary characteristic of the intuitive approach. For the purpose of identifying those processes for redesign, Davenport (1993)2 provides a more structured approach, which is slightly different to that of Hammer and Champy’s. Instead of just offering ways of assessing processes, he describes ways in which the processes can be scoped and suggests how to actually identify the need in those processes. His key activities used for identifying processes for redesign are shown in Table 3.

2

Davenport, T., (1993), “Process Innovation: Re-engineering Work Through Information Technology”, Harvard Business School Press.

Table 3: Davenport’s Method for Selecting Processes for Redesign

6

Copyright© CASEwise 1999

Implementing Business Process Re-engineering

The first step involves enumerating the major processes within the scope of study. This has been considered a difficult task due to the lack of a widely accepted set of processes, or even a method for determining the processes. In an enterprise, business planners have described their enterprise as having anything up to 140 or more processes. Davenport recommends representing the enterprise as having 10-20 processes, which he says is a trade off between managing process interdependence and ensuring that process scope is manageable. The fewer and broader the processes, the greater the possibility of innovation through process integration, and the greater the problems of understanding and changing the process. Processes can be enumerated using classification schemes described in the white paper “The Theory of BPR” where processes, depending on their characteristics, are divided into core processes, support processes and so on. Secondly, using Davenport’s framework, one must determine the process boundaries. Similar to enumerating processes, scoping processes is more like an art than a science. Butler Cox7 suggests the use of a task force, or alternatively, a management workshop. Davenport recommends a set of questions as follows: • • • • • When should the process owner’s concern with the process begin and end? When should process customer’s involvement begin and end? Where do sub-processes begin and end? Is the process fully embedded within another process? Are the performance benefits likely to result from combining the process with other processes or sub-processes?

Butler Cox, (1991), “The Role of Information Technology in Transforming the Business”, Research Report 79.

7

Answers to these questions should provide the team with enough information to make valued judgements as to the process boundaries. Davenport further suggests that process management is best viewed as an iterative activity in which subsequent redesign in one process gives rise to a need to re-innovate, or at least modify others, e.g. redesigning a process will effect the boundaries of other processes. The third step involves assessing the strategic relevance of the processes that have been identified and their boundaries determined. This allows the team to target the process in question. Davenport identifies four criteria to aid process selection. These are: • The processes centrality to the execution of the enterprise’s strategy. For instance, if an enterprise business strategy focuses on improving relationships with customers, the order management process would be a probable choice. The processes health, i.e. those processes that are consistently problematic. The processes qualification, i.e. where the primary goal is to gauge the cultural and political climate of a target process. The processes manageability and scope.

• •

Copyright© CASEwise 1999

7

Implementing Business Process Re-engineering

Davenport writes that enterprises he has studied spent several years travelling the process re-engineering path, in the course of which most changed the number of processes that they defined, as well as the boundaries of individual processes and the relative priorities as candidates for innovation. The preceding section has principally focused on describing the two high-level approaches in terms of selecting processes for redesign. Davenport believes more in a structured approach, while Hammer and Champy take a more “soft” approach, relying mainly on the team’s insight and wisdom.

3.0 Process Visualisation
Achieving success in a re-engineering project requires a powerful vision of what the future should be like. An effective vision is powerful because it can guide and motivate the BPR team and the enterprise at large. A compelling vision must be clearly defined and then effectively communicated. The right BPR vision is difficult to create. It must strike a balance between platitude and a laundry list, between providing too few and too many Goals8. In addition, a vision requires significant time, energy, and creative thought. Process visualisation is implicitly related to the business strategy and the business vision. This is illustrated in Figure 1. which shows exactly how the three aspects are related. The business vision and business strategy set the process context for the development of the process visualisation. A business vision is a statement of the enterprise’s values and beliefs, its goals, and its overall business philosophy. It is essential for providing a high level sense of direction and statement of principle and acts as a useful input to the process visualisation. However, you cannot use a business vision as a substitute for a process vision because it is too nebulous and imprecise to guide the re-engineering effort. A business vision does not provide the tangible direction that is required to focus, motivate, and inspire in the way that process visualisation does.

Barrett, J.L., (1994), “Process Visualisation, Getting the Vision Right is Key”, Information Systems Management.

8

Copyright© CASEwise 1999

8

Implementing Business Process Re-engineering

Figure 1: Business Vision, Strategy and Process Visualisation Hierarchy

Business strategy is essentially about understanding an enterprise’s markets, customers and capabilities; identifying potential market capabilities; identifying potential market opportunities and then allocating resources to take advantage of these opportunities to improve the financial performance of the enterprise. The difference between business strategy and process visualisation is that the former indicates to the enterprise what it must do, while the latter tells how to do those things right. Business strategy is important when determining which processes the BPR team should focus upon. In order for process visualisation to be successful, it must not violate the tenets set forth by the enterprise’s business vision and it must align with and support the enterprise’s business strategy9. Each element business vision, business strategy and process visualisation are interdependent, yet each must remain separate and distinct. Davenport believes that in order to create an effective process visualisation the following steps should be undertaken. They are illustrated below in Table 4.

Edwards, C., Peppard, J.W, (1993), “Business Process Re-design: Hype Hope or Hypocrisy”, Journal of Information Technology.

9

Table 4: Davenport’s Method for Process Visualisation

Step 1: Access business strategy for process direction
The first step, assessing existing business strategy, is concerned with the implementation of strategy as a means to guide and inspire process redesign. Davenport lists seven criteria that he believes an enterprise’s strategy should conform to. It should:

Copyright© CASEwise 1999

9

Implementing Business Process Re-engineering

• • • • • • •

Be at least partially non-financial. Have components that are measurable. Focus an enterprise on specific aspects of the business where re-engineering can be usefully applied. Be distinctive to an industry and company. Be inspirational. Be for the long-term. Employ a method that broadly focuses and addresses key tools for change.

Satisfying these criteria will increase the enterprise's chances of success in the search for process redesign. However, care must be taken not to overemphasise any of these requirements - strategy provides only an internal perspective in creating a process visualisation.

Step 2: Consult process customers for process objectives
Secondly, customer inputs into process visualisation facilitates an understanding of the customer’s perception of the process. Asking customers what they require of processes serves multiple purposes. In the context of creating visions, the customer perspective furnishes both ideas and objectives for process performance. Seeking customer input also demonstrates a desire for a close relationship, although this input must be actually factored into process designs to fully achieve this objective. Finally, new processes may require that customers change their own behaviour for the process to be fully effective. Seeking input at an early stage starts building customer commitment to the changes and lets customers begin their own process transition. Davenport (1993) suggests that a focus group to facilitate customer contact is the best way to deal with the individual. He concludes that customer feedback should be iterative, taking place throughout a re-engineering initiative so that customers can react to more concrete process designs as they are developed.

Step 3: Benchmark for process performance
Davenport believes that the third step, process benchmarking, is an effective tool for determining process objectives and identifying innovative process attributes. It enables companies to look outside for alternative ways of designing processes and to break with an inwardly focused mindset. He claims that experience has revealed that the most appropriate benchmarks are “best practice” or “innovation” and he selects companies on the basis of the performance of a particular process without regard to the industry. Furthermore, he argues that benchmarking can identify realistic performance objectives and targets for companies to match or surpass, and this information can be used during innovation brainstorming workshops to fuel the redesign process.
Klien, M.M., (1994), “Re-engineering Methodologies and Tools: A Prescription for Enhancing Success”, Information Systems Management Journal.
4

However, this is a purely methodological approach. Most people in the intuitive camp maintain that rules of thumb together with general information about what has been done in other companies is more useful than formal benchmarking4. The reason why reengineers, armed with benchmarking data, are so dangerous is that as soon as the stimulus of re-engineering becomes discrepancies in benchmarking data, all the firms in the industry start converging to a point of no difference and thus no profit.

10

Copyright© CASEwise 1999

Implementing Business Process Re-engineering

The distinction between qualification and differentiation criteria help explain the danger, i.e. qualification criteria are attributes every firm must have to enter a market, while differentiation criteria give a firm an edge.

Step 4: Formulate process performance objectives
The fourth step in Davenport's approach involves formulating the process objectives. The process objective is a statement that details the overall process goal, the specific type of improvement desired, the numeric target for the innovation, and the time frame in which the objectives are to be achieved. The process objective is created by questions, posed to both the vision team and the key stakeholders, such as “what business objective is the process supposed to accomplish?” The objectives should be derived from strategy and must be quantifiable. Examples of process objectives are: • • Double customer service satisfaction levels in two years Reduce processing costs for customer orders by 60% over three years

Step 5: Develop specific process attributes
The final step in Davenport’s method entails developing process attributes. Process attributes simply constitute a vision of a process operation in a future state. They are highly descriptive and non-quantitative, they address high-level process characteristics and specific enablers. Process attributes are frequently considered as principles of process operation, behaving as simple statements describing an enterprise’s philosophy and intent, regarding process operations and can be an effective means of engaging senior management in discussions about visions for new processes. Examples of process attributes are: • • • Link order management systems world-wide, but keep them local Create automated sales assistant tools for product information and pricing Offer direct shipments from manufacturing to customers

The process objectives and attributes described above are usually determined from an array of activities, e.g. corporate strategy, overviews of IT and people and so on. This is accomplished during visioning sessions at the beginning of a specific process initiative.

Copyright© CASEwise 1999

11

Implementing Business Process Re-engineering

Figure 2: The Visioning Process

A popular theme within re-engineering projects is to incorporate this visioning process into a series of workshops. Figure 2. illustrates how these visioning sessions explore increasing levels of detail about the vision at each step. The earlier stages of the visioning process are dictated by the creation of objectives and attributes. Once formulated, the workshops address the critical factors for the successful implementation of the vision and any barriers that might stand in the way. Hammer and Champy do not provide a concise definition of their process visualisation techniques. This stems from their reasoning that re-engineering is contextual and no set technique can be used all of the time. However, aspects of vision are reflected in their beliefs that the re-engineering team should focus on customers to determine what the customer’s real requirements are, i.e. what do they say they want and what do they really need, and are the two different? Also, what problems do they have and what processes do they perform with the output? Since the eventual goal of redesigning a process is to create one that better meets customer needs and it is critical that the team truly understands these needs 3. In answering these questions and meeting these demands the team has effectively created their vision; a vision of what the future should be like. Furthermore, they believe that this should be done not by asking the customers what those needs are, but by understanding the customers' underlying goals and problems. This understanding cannot be acquired by asking the customers what they want because they will tend to answer from their own unexpanded mindset. Hammer and Champy decided that a better way to acquire information about what customers do is to watch them do it. This will give team members an insight as to what is important and what is not. From this the team can determine ways in which the process can better serve the customer. The goal is to understand the "what" and the "why", not the "how", of the process. Hence, an effective process visualisation will result.

Hammer, M., Champy, J., (1993) “Re-engineering the Corporation: A manifesto for Business Revolution”, Nicholas Brealey Publishing.

3

12

Copyright© CASEwise 1999

Implementing Business Process Re-engineering

They also consider the use of process benchmarking as a means for looking at companies that are doing something well and learning how to do it in order to emulate them. However, they also point out that benchmarking can restrict the re-engineering team’s thinking to what is already being done in its own industry sector. If the team is going to benchmark, it should do so from the best in the world, not just the best in its industry.
Barrett, J.L., (1994), “Process Visualisation, Getting the Vision Right is Key”, Information Systems Management.
8

Barrett (1994)8 also provides a method for developing a process visualisation. The approach embraces the concepts described above and stresses the following: • • Maximising the collective creativity of the BPR team. Reaching a point where team members enthusiastically embrace their concept of the future and then actively campaign on its behalf to the rest of the enterprise. Establishing a learning laboratory to test and refine the team's proposed process visualisation in a controlled environment.

He divides the development methodology into a number of stages. Firstly, the incubation stage is where BPR teams work through a structured set of knowledge-building activities prior to embarking on process visualisation. This enables the team to achieve an effective process visualisation. The right people must be selected - i.e. those possessing suitable qualities - and the team should examine the business process targeted for re-engineering as it currently operates. The objective here is to identify the key leverage points of the process and then focus on these for significant performance improvement. In addition to the points highlighted above, BPR teams should analyse various examples of best practice for the particular business process. Secondly, the targeted brainstorming phase is when the BPR team actually construct, over time, the process visualisation by creating both the narrative description and the graphical depiction of the future process. This is done through a series of targeted brainstorming sessions. Note that the narrative simply contains explanations as to why we must change and what we must do. Barrett outlines a number of techniques to facilitate the kind of breakthrough thinking that successful process visualisation requires. They include the year 2010 approach, where the BPR team visualises what the targeted process will be like in the year 2010 and the ideal service approach, where the BPR team describe what would be different if customers were thought of as partners. The final phase is when the team has a sense of having accomplished a resounding victory. This is known, according to Barrett, as the “eureka” phase. Here all the preparation and work of the previous two phases comes together to form a process visualisation that the team deeply believes in.

Copyright© CASEwise 1999

13

Implementing Business Process Re-engineering

4.0 Understanding Existing Processes
In the re-engineering effort there is disagreement surrounding the role of the existing process. For instance, Hammer and Champy claim that the process should be understood, but not in any great detail. Whereas, Davenport argues that time must be taken to understand and document the existing process. Before discussing the reasons for the difference, it is necessary to discuss each of the practitioners' views in detail. Hammer and Champy believe that before a re-engineering team can proceed to redesign, it must know something about the existing process, i.e. what it does, how well it performs and the critical issues that govern its performance. The level of understanding is the crucial point here. They believe that because the team’s goal is not to improve the existing process, it does not need to analyse and document the process to expose all of its details. Their observations suggest that the most frequently committed errors in re-engineering is that the re-engineering team try to analyse a process in agonising detail rather than attempt to just understand it. Rather, the team members require a high-level view that is just enough to generate the intuition and insight necessary to create a totally new and superior design. Although Hammer and Champy stress that detailed process analysis of a conventional sort is useful to help persuade others in the enterprise that re-engineering is necessary, the task is part of change management and re-engineering teams need to look for knowledge and insight. They say that the best place for the team to start to understand an existing process is usually at the customer end. This is because the eventual goal of redesigning a process is to create a new one that better meets customer needs. Once the team establishes what process the customer might need the next step is to figure out what the current process provides. Davenport’s studies contrast with this approach. He argues that not taking the time to understand an existing process leaves the re-engineering team unable to establish the benefit of adopting the new process. He lists four reasons why it is important to document existing processes before proceeding with redesign. • Understanding existing processes facilitates communication among participants in the re-engineering initiative. Models and documentation of the current state allow for a common understanding between the team. Documentation provides the means to migrate to a new process. It is an essential input to migration and implementation planning. It is useful for understanding the magnitude of anticipated change and the tasks required to move from the current process to a new process. Recognising problems in an existing process can help ensure that they are not repeated in the new process. Understanding of the current process provides a measure of the value of the proposed redesign.

14

Copyright© CASEwise 1999

Implementing Business Process Re-engineering

Davenport’s analysis on existing processes goes as far as to produce a list of key activities in understanding and improving existing processes. This is illustrated below in Table 5.

Table 5: Davenport’s Method for Understanding the Existing Process

The first step involves documenting the current process flow. He believes that describing the process is central to the purpose of process communication and increases the likelihood of process participants adopting a revolutionary process. The current process is then used as a baseline comparison with the new process and thus should be assessed in terms of the same criteria employed for the new design. The scope of the existing process should be the same as that envisioned for the new process. Furthermore, the current process should be measured on the specific performance objectives and assessed for the relative levels of process attributes as identified in the process vision. This narrowing of the assessment task helps reduce the time and effort required for the current process analysis. For example, if the visioning activities for a new process yield cycle-time reduction and output quality improvement as objectives, then these criteria should be the focus of current process measurement activities. If the process attributes in the new vision involve a single level of approval for customer transactions, the number of approvals required in the current process should be known.
Edwards, C., Peppard, J.W, (1993), “Business Process Re-design: Hype Hope or Hypocrisy”, Journal of Information Technology.
9

Edwards and Peppard (1993)9 believe that undertaking BPR demands an understanding not only of the purpose of the process under review but also an understanding of the purposes and methods of each of the processes at higher levels of granularity. For example, to redesign a process within a function demands an understanding of that function, as well as of the enterprise as a whole, the industry within which the enterprise competes, and society in general. They argue that to redesign a process without reference to these higher levels of granularity can result in suboptimality9. Davenport further believes that improving the existing processes is a natural follow-on to documenting them. The documentation usually reveals long-standing problems such as bottlenecks, redundancies and unnecessary activities that have gone unrecognised. Many companies engaged in re-engineering are actually coupling short-term improvement and breakthrough innovation, using the documented information. This has been classified as a “systematic approach” to re-engineering where performance improvements are implemented in the short term, while re-engineering work proceeds in the medium and long term.

Copyright© CASEwise 1999

15

Implementing Business Process Re-engineering

Davenport summarises the traditional approaches to process improvement, Table 6 shows the difference between traditional approaches and radical redesign and shows why none of the techniques are capable of achieving radical improvement. Secondly, it identifies tools and techniques that are applicable and useful in the process improvement stage of the reengineering initiative.

Davenport (1993) Process Innovation: Re-engineering Work Through Information Technology Davenport, T., (1993), “Process Innovation: Re-engineering Work Through Information Technology”, Harvard Business School Press.
2

Table 6: Process Methods Overview

2

There are two major differences in the approach offered by Davenport and Hammer and Champy. The first difference is the stage at which understanding occurs. Hammer and Champy believe that this understanding of what the process represents should come before process visualisations are created. Hence, their reasons for believing that exposing all of the processes details will affect the design of the new process. However, Davenport argues that the existing process should be examined and documented following process visualisations. Secondly, Davenport believes that process improvements in the short-term should precede re-engineering work in the medium and long term. However, Hammer and Champy believe in making radical changes and that the new process should have no basis in the old.

5.0 Redesigning New Processes
The design phase largely revolves around a group of creative people that review the information collected in earlier phases of the initiative and synthesise it into a new process. There are many techniques for facilitating the review process, but the success or failure of the effort will be determined by the particular people who are gathered together. A number of these techniques are discussed in this section. Davenport states that key process stakeholders usually want to feel that their interests are represented during this stage. This is in addition to the views of the main participants of process identification and the visioning phases. The stakeholders that should be included in the discussion are usually heads of key functions intersected by the process, key general managers with operational responsibility for the process, suppliers and process customers, both internal and external.

16

Copyright© CASEwise 1999

Implementing Business Process Re-engineering

Davenport’s rendition of the redesign session is much more detailed than that of Hammer and Champy’s. Davenport’s analysis extends to discussing a migration strategy and implementing new organisational structures and systems. Hammer and Champy specifically discuss only re-designing the process. Furthermore, Hammer and Champy provide a set of detailed examples which includes a great deal of information on how processes are redesigned and implemented. However, in this section we shall limit the discussion to the redesign session because other areas such as the new organisational structures are covered in part one of this series of white papers “The Theory of Business Process Re-engineering". Davenport (Table 7) lists his key activities in designing and prototyping a new process.

Table 7: Davenport’s Method for Redesigning the New Process

The first stage is to brainstorm the design alternatives. Design innovation is best accomplished in a series of workshops, and brainstorming is an effective means of surfacing creative process designs. Brainstorming is any group facilitation technique or practice that encourages participation from all group members, regardless of their roles and relationships within the enterprise. Emphasis should be placed on creativity and idea generation and a non-judgmental atmosphere is essential. Davenport stresses that the objective of this session is to develop creative but pragmatic new process designs, taking as input the earlier stages of his re-engineering approach. Davenport emphasises that it is often useful to define the new process in an iterative fashion, with greater detail at each successive level. Table 8 below illustrates this.

Table 8: Level of Process Design

Copyright© CASEwise 1999

17

Implementing Business Process Re-engineering

To begin with a high-level flow of the overall process should be created. At the next level of detail, each sub-process can be described with roughly the same thoroughness as was used in describing the general process in the first iteration. Finally, each major activity should be described in terms of such factors as who performs it, the information needed to carry it out and so forth. Davenport believes the next stage is to submit all of the design alternatives to feasibility analysis to evaluate their relative benefits, costs, risks and time frames. The new design must be compared in terms of structure, technology and organisation to fully understand the implications of each alternative. Furthermore, Davenport believes that following the selection of the preferred redesigned process, a prototype to simulate and test its operation should be set up. This is an iterative stage in which the fit between new process, structure, information technology and organisation is refined. Hammer and Champy's approach to this brainstorming session is slightly different to Davenport’s. They propose a number of techniques for redesigning a specific process. Questions such as “imagine only a single person were available to perform all the tasks involved in building a product” how would they be likely to do it? What help would that single worker need. How could technology lend a hand? Following through on answers to these questions can get the redesign session moving. Another technique that is used by Hammer and Champy is that of identifying and annihilating assumptions. This technique was found to be useful in stimulating the reengineering team's thinking and works on the basis that assumptions are deeply held beliefs that are built into almost every existing business process. An example of this is that field salespeople are not allowed to set the terms of a sale. This is because of the assumption that salespeople may put their own financial interests ahead of the company’s in order to earn commission. A re-engineering team should attempt to turn these assumptions on their heads or, alternatively, throw them away and then see where that leaves the process they are redesigning. The final technique used by Hammer and Champy for stimulating creativity is to harness the disruptive power of Information Technology. Conventional business processes sometimes reflect the limitations inherent in the pre-computer era because they were designed on that basis. If we try to improve these processes we will still be constrained by the same limitations. The re-engineering teams can break out of this bind by starting with the capabilities of modern Information Technology. Assess what it allows to be done and then determine if it helps you to redesign the process.
Cougar, J.D., Flynn, P. Hellyer , D., (1994) “ Enhancing The Creativity of Re-engineering: Techniques for Making IS More Creative”, Information Systems Management.
10

Cougar et al (1994)10, suggest an approach to enhance the creativity of re-engineering, which in turn, observations suggest, will help generate cost effective ideas. They proposed a two-pronged approach: • • Improvement of the environment for creativity and innovation Training in specific techniques for creativity generation and evaluation

18

Copyright© CASEwise 1999

Implementing Business Process Re-engineering

They extend their analysis specifying that the program should consist of two phases evolving specific activities. Phase one comprises and teaches a number of creativity, evaluation and implementation techniques. The workshop should contain both analytical and intuitive creative generation and evaluation techniques, for example; analogies/metaphors and problem reversal. Participants should be involved in exercises using each of the techniques taught, in order for them to become familiar with their use and how to apply them to Information Systems Design. In phase two there is reinforcement of the concepts and principles learnt in the workshop. This is done through monthly meetings for each department where the team can discuss their experiences in the application of the techniques and test the degree to which the environment for creativity has been enhanced. Reinforcement can be facilitated by use of staff meetings where employees are asked to identify specific results of their creative activity. The techniques outlined above have proven to enhance the climate for creativity in a systems development group in creating cost-effective ideas. Furthermore, employees that have participated in creativity workshops stated that the program: • • • Helped them to surface their creativity. Helped them to share ideas and be more open. Encouraged them to consider other approaches, not just continue to use established methods. Helped them develop intuitive approaches and not rely only on the analytical. Improved group interaction, developed rapport. Helped integrate creativity as part of the daily job

• • •

For re-engineering to succeed it must be creative. The above techniques offer the means. The discussion above has attempted to review some of the techniques that can be used to enhance the generation of ideas from members of a re-engineering team. Once the team has determined process visions and understood existing processes to an appropriate level of detail they can then create a redesigned process that achieves the defined objectives.

6.0 The Structure of Re-engineering Teams
Business re-engineering is typically tackled with work teams from across the enterprise. The team usually consists of a leader and representatives from the business units involved, Information Systems, Quality Assurance, Human Resources and other key departments. The leader usually is the “owner” of the process being addressed.

Copyright© CASEwise 1999

19

Implementing Business Process Re-engineering

In general, the particular personnel who are chosen and the amount of authority they are given are critical factors in success of the re-engineering project. Furthermore, the reengineering “core” team must start small and remain small. Therefore, a prudent approach is to find as few people with as many of the requisite cross-functional skills as you can. Five to seven people should comprise the core team; teams in excess of ten should be avoided because ten people rarely agree on anything. Because the re-engineering team must be cross-functional, a balance of outsiders and insiders must be selected as full-time, dedicated team members. Outsiders are people who have not been involved with the enterprise, while insiders are people who have had recent experience as a member of the enterprise. The core team members must be complemented by two other individuals: a public relations person and a champion. We should note that in addition to their skills, the way that the team members are perceived is important. How the affected enterprise will view each member of the team is a factor in team selection. The goal should be to select team members who have requisite skills and will be able to gain acceptance from others in the current environment. Because re-engineering projects are usually high-profile endeavours, the team members will be judged constantly by the people within the enterprise. Therefore, the selection of team members must be done so as to avoid negative personal perceptions. The insiders must be individuals respected by most people at all levels of the enterprise from which they came.

6.1 The Re-engineers
Re-engineers will be management level people, but they must not be responsible for managing people during the re-engineering project. They need the time and the freedom to analyse and diagnose problems. Furthermore, an understanding of technology is paramount. Here the people must be technically competent. The more experience they have in information system integration, the better. The skills described above can be classified as “hard”. These must be complemented by a wide array of “soft” skills. For instance the re-engineer must be able to go to the factory floor and relate to the workers and then must be able to go to the boardroom and present the team’s findings in a way that the senior managers can understand. Moreover, these reengineers must be “thick skinned” in order to defend their ideas and conclusions and be highly self-motivated. Some of the re-engineers can be external consultants. Because the re-engineering discipline is relatively new to many enterprises, augmenting the team with consultants will help to speed things along and provide the needed experience.

20

Copyright© CASEwise 1999

Implementing Business Process Re-engineering

6.2 The Insiders
At least thirty per cent of the re-engineering team should comprise of employees who have recently worked in the current environment. In dealing with the potential problems there may be no quicker way to gain credibility than to have highly respected members of the current enterprise involved in the effort.

6.3 The Champion
Within the context of leadership, a “champion” may be the most important “cog” in the re-engineering team. This person will have the same traits as the re-engineer, i.e. drive, motivation, good interpersonal skills and so on. The champion is responsible for leading the re-engineering team, fighting political battles, removing obstacles and gathering support from all levels of management.

6.4 The Public Relations Person
To complement the core team members it is necessary to have a PR person on the reengineering team. This person should be dedicated to spreading a positive message about re-engineering and the benefits of the program in particular. The PR person must work to create positive associations with the project in people’s minds.

7.0 Conclusion
The white paper on “The Theory of Business Process Re-engineering” described the fundamental transformation that BPR produces, in terms of the enterprise's structure, processes, technology and people. This white paper on “Implementing Business Process Re-engineering” has focused on the practices that perform change, highlighting two approaches to business process re-engineering that cur rently exist. Firstly, arguments surrounding the adoption of methodology in re-engineering were stated. For example, a methodology introduces a minimum set of disciplines into a task, but stifles creativity, which is central to radical redesign. However, there is some debate about what constitutes a methodology. Strictly speaking, both practitioners propose a methodology, but one is more flexible than the other. In the view of the author, an Implementing method is required to provide the re-engineering team with guidance in their increasingly difficult task. Rather than revolve around tightly defined tasks, such as those prescribed by Davenport, tasks should be loosely defined (the “soft” approach). This facilitates creativity amongst the team; in other words, it is a more intuitive approach. Still, one must not lose sight of the fact that both methods have proved extremely successful in their areas of application.

Copyright© CASEwise 1999

21

Implementing Business Process Re-engineering

The steps taken should fit into those described in this white paper. Firstly, processes for redesign must be selected. The approaches described to facilitate this stage are conceptually the same, where processes that are consistently problematic are paid most attention. Also, these processes are assessed on their strategic relevance, or importance and then reviewed to determine feasibility in terms of culture etc. The second and third steps involve developing process visualisations and understanding existing processes. This is the point at which the two approaches differ the most. The main distinction between the two approaches is that the intuitives believe the process needs only to be understood on a high level of detail, from which effective visions can be drawn. They believe the existing process should not be analysed in any great detail, since the new process should have no basis on the old. However, the methodologists believe that the existing system should be well documented following the development of visions. Moreover, they argue the existing system should be improved in the short-term while reengineering work continues in the medium and long-term. The final step of a re-engineering initiative before the new process is implemented is the redesign session. As the two approaches indicate, this is usually accomplished through intensive brainstorming sessions, applying a number of creativity techniques. Finally, it is worth mentioning that it is extremely difficult to undertake radical redesign. The approaches that do exist all claim considerable success. However their ability to discuss their successes is followed by a reluctance to discuss failures. This makes assessment of the value of these approaches extremely difficult. In practice, the way re-engineering is conducted varies between the enterprises to which it is applied. One must view these approaches only as a guide to a re-engineering project. No two situations are identical.

22

Copyright© CASEwise 1999

NOTE: INSIDE BACK COVER IS BLANK

Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP Change Management BPR ISO9000 Business Process Improvement Workflow Implementation ERP EFQM Financial Modelling TQM System Integration Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning Business Process Improvement ISO9000 Change Management BPR SAP EFQM Financial Modelling TQM System Integration Workflow Implementation Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP Change Management BPR ISO9000 Business Process Improvement Workflow Implementation ERP EFQM Financial Modelling TQM System Integration About CASEwise... Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning CASEwise has, since the company's formation in 1989, concentrated on Business Process Improvement ISO9000range of packaged business Change Management BPR providing the most functional and comprehensive SAP EFQM Financial modelling software availableSystem Integration Workflow Implementation Modelling TQM for the Microsoft Windows market. Strategy Planning Activity Corporate Modeler™ software provides a common platform that Planning SAP CASEwise's Based Costing (ABC) Business Contingency enables Finance, Information Technology, Human Resources, and Business Change Management BPR ISO9000 Business Process Improvement Processes to be modelled, explored and understood in a totally integrated Workflow Implementation ERP EFQMandFinancial Modelling TQM System Integration holistic manner. Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning To its modelling technology, CASEwise offers a Business Processcomplimentservices to ensure successful implementation.full range of Improvement ISO9000 Change Management BPR professional CASEwise Professional Services TQM education andIntegration Workflow Implementation include System training, methodology SAP EFQM Financial Modelling development, on-site seminars, all of Strategy Planning Activity Based consultancyaservices and a series of of theContingency Planning SAP Costing (ABC) Business capabilities which provide potential users with greater understanding Change Management BPR ISO9000Modelling within the enterprise. and benefits of Business Process Business Process Improvement Workflow Implementation ERP EFQM Financialcontact: Modelling TQM System Integration For more information, Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning Business Process Improvement ISO9000 Change Management BPR SAP EFQM Financial Modelling TQM System Integration Workflow Implementation CASEwise Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP www.casewise.com Change Management BPR ISO9000 Business Process Improvement USA EUROPE Workflow Implementation House 9–13EFQM Financial ModellingTrapelo Road TQM System Integration Reservoir Place 1601 Station ERP Swiss Terrace Waltham, MA 02451 London NW6 4RR Telephone: +1 781.895.9900 Telephone: +44 (0)171 Business Activity Based Costing (ABC) 722 4000 Contingency Planning ERP Strategy Planning Facsimile: +1 781.895.9914 Facsimile: +44 (0)171 722 4004 Business Process Improvement ISO9000 Change Management BPR SAP EFQM Financial Modelling TQM System Integration Workflow Implementation Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP Change Management BPR ISO9000 Business Process Improvement Workflow Implementation ERP EFQM Financial Modelling TQM System Integration Activity Based Costing (ABC) Business Contingency Planning ERP Strategy Planning Business Process Improvement ISO9000 Change Management BPR SAP EFQM Financial Modelling TQM System Integration Workflow Implementation Strategy Planning Activity Based Costing (ABC) Business Contingency Planning SAP Change Management BPR ISO9000 Business Process Improvement