Critical Literature Review of Business Process

Reengineering

By Patrick Bongo

2

TABLE OF CONTENTS

1. Introduction ___________________________________________________________ 3

2. Examples of BPR Projects _______________________________________________ 4 2.1 Introduction ________________________________________________________________ 4 2.2 IBM Credit ________________________________________________________________ 4 2.3 Accounts Payable – Ford ______________________________________________________ 5 2.4 Conclusion _________________________________________________________________ 5

3. Reasons for BPR Projects Failures ________________________________________ 6

4. Methodologies _________________________________________________________ 7 4.1 Introduction ________________________________________________________________ 7 4.2 Davenport’s five-step approach _________________________________________________ 8 4.3 Accountability Centered Approach ______________________________________________ 9 4.4 Muthu et al (1999) Summary of Five BPR Methodologies ___________________________ 10 4.5 Conclusion ________________________________________________________________ 11

5. BPR Tools ___________________________________________________________ 12 5.1 Introduction _______________________________________________________________ 12 5.2 Tools ____________________________________________________________________ 12 5.3 Evaluating BPR Tools _______________________________________________________ 13 5.4 Conclusion ________________________________________________________________ 14

6. Information Systems Development Techniques that could be applied in BPR ____ 15 6.1 Introduction _______________________________________________________________ 15 6.2 Business Process Analysis ____________________________________________________ 15 6.3 Business Process Redesign ___________________________________________________ 18 6.4 Conclusion ________________________________________________________________ 20

7. Similarities between System Development and BPR _________________________ 20

8. Differences between System Development and BPR _________________________ 20

9. Assessing Success of BPR Projects _______________________________________ 21

10. Research and Development ____________________________________________ 21 10.1 Introduction ______________________________________________________________ 21 10.2 Previous Research Issues ____________________________________________________ 21 10.3 Future Work______________________________________________________________ 23

11. Discussions __________________________________________________________ 23

12. Conclusions _________________________________________________________ 25

13. References __________________________________________________________ 25

3

1. Introduction In the early 1990s, a new term started to appear amongst numerous IS publications –

business process re-engineering (Beynon-Davies, 1998:244). Historically, as Beynon-

Davies claims, the early 1990s was the birth period of BPR (Business Process

Reengineering). Now almost over 15 years old, there is still a need to review this

concept. A review which would entail an investigation of its past, present and

possibly future state.

Earl (1994) cited by Beynon-Davies (1998:244) has argued that there are generally

two viewpoints on BPR: protagonists are convinced that it is a new approach to

improving business performance – ‘the new wonder drug’; cynics feel that they have

seen it all before in different guises – ‘new wine in old bottles’.

In this perspective, there is a tendency to visualize BPR as a new approach, but still

under the umbrella of systems analysis and design, with the inherited characteristics

of some of the already existing methodologies.

Thus, this Critical Literature Review section would also attempt to study BPR in

details in order to measure its relevance to the field of information systems

development and highlight areas of improvement within their partnership.

Before embarking on any sort of discussion in relation to BPR, let us try to find out

what it actually means. Grint et al (1995) describe BPR as a means of facilitating

significant, even fundamental, change in a way an organisation operates. Though it

could be argued that BPR does not always facilitate the change in business processes,

as the success of the latter could very much depend on how the organisation

workforce embrace the change.

Hammer and Champy (1993) describe BPR as the radical redesign of business

processes, usually enabled by information technology, in order to achieve dramatic

improvements in their performance.

Some other alternative terms that are used to describe BPR, are process innovation

(Davenport, 1993 cited by Grint et al, 1995), business process redesign (Short and

Venkatraman, 1992 cited by Grint et al, 1995) and business reengineering (Spur et al,

1993 cited by Grint et al, 1995). It is possible to say that perhaps the term that seems

more convincing in my view, is business process redesign, as it implies the change of

existing processes.

Davenport (1995) describes reengineering as the radical redesign of broad, cross-

functional business processes with the objective of order-of-magnitude performance

gains, often with the aid of information technology. Hammer, Champy and

Davenport’s view highlights an important association between IT and the

reengineering process, which I think is quite prevalent in the 21st century, but it seems

as if they place more emphasis on increased productivity as a result of improved

performance, rather than the ease of use that is also supposed to arise from the

change.

Process reengineering could also be seen as an activity for implementing changes to a

process that result from the application of Continuous Improvement and Total Quality

Management (Hansen, 1994: 1). The idea of redesigning a process without a total

quality management is almost imperceptible, thus I could not agree more with

Hansen.

4

The combination of total quality management advocated by Hansen and the use of

technology indicated by Davenport, seems to be an inextricable relationship in

business process redesign, as after reengineering, organisations always try to maintain

the good quality of products and services. But that still does not take away the need

for optimization through continuous improvements due to changing market trends and

customer requirements.

2. Examples of BPR Projects

2.1 Introduction

It seems pointless discussing BPR, without actually knowing what is a BPR project,

as any slight change in the way one individual operates within an organisation is BPR.

We looked at examples of what other authors classified as BPR projects, in order to

differentiate what is a BPR project and what is not.

Hammer and Champy (1993) cited by Beynon-Davies (1998:246) present a BPR case

study for IBM Credit, an organisation devoted to the financing of customer’s

purchases of IBM equipment. Another case study by Hammer (1990) cited by

Beynon-Davies (1998:247) present the re-engineering of an accounts payable process

at the Ford Motor Company. Both case studies would give an indication of the old and

new process, to profound our understanding of what BPR is all about.

2.2 IBM Credit

2.2.1 Old Process

The process was initiated by a salesperson calling in with a request for financing. One

of fourteen telephone personnel logged the request on a paper form. The form was

then taken to a department, which entered details of the request into a computer

system and determined the credit worthiness of the customer. Credit check details

were written on the form and the form was passed to the business practices

department that modified the standard form of a loan to suit the customer. Any special

terms were attached to the form and it was passed to a pricer who determined, with

the help of a spreadsheet, the appropriate interest rate to charge the customer. The

interest rate was then added to the form and delivered to a clerical department, which

turned the information on the form into a quote.

The main problem with this process was that it consumed six days on average. This

led to customers being lost in the intervening period.

2.2.2 New Process

In the new process, specialist staff were replaced with generalists. One person called a

deal structurer now deals with one straightforward order. A computer system was

developed to support the work of the deal structurer. These changes slashed

turnaround time from six days to 4 hours.

5

2.3 Accounts Payable – Ford

2.3.1 Old Process

The process began with the purchasing department writing an order. A copy of this

order was then sent to the accounts payable department. Later, when the materials

control department received goods, it sent a copy of the receiving document to

accounts payable. Meanwhile, the vendor also sent an invoice to accounts payable.

The en-result of this meant that the accounts payable department were involved in

matching fourteen data items between the receipt order, the purchase order and the

invoice before it could issue payment to the vendor. In fact, the department spent most

of its time trying to sort out mismatches between these three documents.

2.3.2 New Process

The new process involved ‘invoiceless processing’. The purchasing department now

entered order information into a database. No copy of this order is sent to anyone.

When goods arrive at the receiving dock, the receiving clerk checks the material

against the outstanding purchase reorder in the database. If they match, he accepts the

goods and payment is automatically sent to the vendor. If they do not match, the order

is returned. This means that matching of only three data items is required: part

number, unit of measure and supplier code between a purchase order and a receipt

order. As a result, Ford achieved a 75% cut in head count.

2.4 Conclusion

Looking at both case studies of process reengineering from IBM Credit and Ford’s

Accounts Payable, it is evident that the reengineering could not have taken place

without the support of IT as it has always been highlighted by Davenport.

We could also perceive that reengineering could involve one department of an

organisation or even across.

It is quite noticeable that both transformations have resulted in a speedy and reduced

paperwork or even paperless process.

Just going back to IBM’s Credit example, it could also be stated that quite a number

of high purchase sales companies theses days now have a computerised credit check

system of which the end result is achieved at click of a mouse. Thus nowadays, if

Ford is still spending 4 hours to achieve such a process, we could still push for a case

of BPR, to slash the process down to even 10 minutes.

It is also true to say that our quest for speed and efficiency in business information

system, would always prevail, hence perhaps BPR has a reason to exist after all.

Though BPR could also have unprecedented consequences in some workers

employment, as the case for Ford, I think businesses could only strike a radical

balance between employment level and profitability. Though we would always

dispute employment redundancy as it is not right for anybody to loose their job as a

result of BPR, but it is an area that the management should study with workers

unions.

6

3. Reasons for BPR Projects Failures Beynon-Davies (1998: 249) believes that the common problems with BPR are its

revolutionary nature, as it seems quite difficult to succeed in the new order of things. I

could not agree more with Davies, as I know from experience in my workplace that

nobody likes change, and thus I could visualize workers of an organisation adapting

themselves to a new way of doing things.

There is also a mismatch between the way IS1 people operate and the way BPR

projects are carried out as a whole, this is equally supported by Davies who advocates

that most analysts and developers are used to creating applications for a single

department and find it difficult to adapt when asked to support newly designed

business processes that span several departments.

Hammer (1990) cited by Davies, also states that as much as 70% of BPR projects fail.

But thankfully he goes on to say that IS is not seen as the primary culprit of such

failure, but faltering support from upper management sponsors is primarily blamed.

Al-Mashari et al (2001) point out that a lack of holistic implementation approach to

exploiting BPR is seen as one of the important reasons amongst others, behind BPR

failures. This proves that, having a methodology that all designers should stick to,

would be help repress the rate of failure, as at least after getting a constructive

feedback from the use of any given methodology, we could review its suitability.

Kotter (1995) cited by Folorunso and Ogunde (2004) identified eight key mistakes

that organisations engaged in BPR make. They are:

1. Not establishing a great enough sense of urgency.

2. Not creating a powerful enough guiding coalition.

3. Lacking a vision.

4. Under-communicating the vision by a factor of ten.

5. Not removing obstacles to the new vision.

6. Not systematically planning for and creating short-term wins.

7. Not anchoring changes in the corporation’s culture.

Although Kotter failed to mention the lack of framework or methodology, we could

conveniently argue that most of his so called mistakes would be addressed in a well

structured approach.

Morgan (2005) also indicates that the reason why many BPR projects never get

beyond the internal efficiency stage of process improvement, is typically because the

company does not spend the necessary time and effort in working with its customers

to develop competitive advantage for both parties.

In perspective to Morgan’s view, it is perceivable that the lack of a sufficient user-

centered approach during the process, is partly to blame.

The mismanagement of human aspects of the change, such as social, career and

procedural dimensions, as these are significantly more complex to manage than any

technological changes are also to blame (Morgan, 2005).

Many authors argue that one of the major problems that contribute to the failure of

business process change projects is a lack of tools for evaluating the effects of

1 IS (Information Systems).

7

designed solutions before implementation (Irani et al, 2005). With respect to Irani et

al view, we need more field trials than tools in order to get accurate data.

In his article, Aeria (2002) argues that the lack of a unified set of criteria with which

to judge the results with is also one of the key reasons for the failure. Though

different companies may have different ways of measuring the results, it is essential to

have a metric system that is integrated in one of the methodologies, so that when

applied by many organisations, its effectiveness could be easily evaluated.

Newman (1996) believes that BPR failures are often the result of Closed-Model2

Systems, whereby conflicts and integration problems arise when attempting to link

together disparate applications that functionally support a common business process.

For example, a residential loan origination business process team might have to log on

to one system to perform data entry, log on to a second system to perform a credit

analysis, and log on yet to a third system to obtain rate information, and so on.

In fairness to Newman’s view, it is true to say that when a major business process is

subdivided into other processes that involve the use of several different entities,

redesigning that process as one is a challenge. But to solve such a problem, Newman

recommends a Class-Based Reengineering (CBR) approach to BPR, whereby classes

would be utilized to model the business to model the business of the firm, define the

organisational structures and information systems.

Ulrich (1995) points out that the reason why the changes have not gone well is due to

the limited ability of organisations to retool existing information systems

environments to support process redesign, but fortunately these could be solved by a

formal discipline called systems redevelopment, that supports the analysis and

migration of legacy systems to meet BPR goals.

Dumay (2005) blames the development of organisational management and the

contradicting interests of the various stakeholders. Although it is possible to argue

that conflicting interests from the stakeholders would only exist if there is improper

planning and poor guidance from the project facilitator.

Overall, all the reasons given by the authors cited, are equally shared by many others,

though it is worth admitting that quite a few made reference to a case study in support

of their views.

4. Methodologies

4.1 Introduction

Although BPR itself is considered as a methodology for organisational transformation

which promises employee empowerment through the adoption of IT as a leverage for

change, as indicated by Sayer and Harvey (1997), there are a few reasons why it is not

considered as one. We could well argue that it is not a methodology because it is not

structured and has not got a notation of any sort. More importantly, it is very

dependant on other methodologies. Even Johnson and Stergiou (2005) argue that

because BPR is not a methodology, it appears that all you can do is start with a clean

sheet of paper and follow the principles of reengineering.

2 A Closed-Model system is one that internalizes within its system boundaries all of the processes and

data entities that are necessary for the system to fulfil its business requirements. They are Function

driven, whereas Open-Models are Class driven.

8

Despite the fact that there are not so many recognizable universal BPR

methodologies, few authors and industrial practitioners have developed their own

approach. Whether those approaches have been tested on real BPR projects, remains

questionable. But from an academic research perspective, a number of literatures have

been explored and revealed some approaches such as Davenport’s five-step approach,

Tseng et al Accountability Centered Approach (ACA) and Muthu et al (1999)

summary of five BPR methodologies.

4.2 Davenport’s five-step approach

Davenport (1993:200) recommends a five-step approach to process change as shown

in fig 1.

Figure 1: An Approach to Process Change as adapted from Davenport (1993:200)

Davenport highlights that Identifying Processes for Innovation involves information

gathering and analysis. He adds by saying that there are two kinds of information that

need to be gathered: information about the performance and structure of candidate

processes, and information about the readiness of the organisation to support the

redesign of those processes.

As for Identifying Change Levers, Davenport talks about identifying enablers for new

process design, and those include knowledge and creative thinking about how IT and

innovative organisational/human resource approaches might be applied to a process

under analysis.

Developing Process Visions relies on a (1) clear understanding of organisational

strengths and weaknesses, coupled with an understanding of market structure and

opportunity and (2) knowledge about innovative activities undertaken by competitors

and other organisation.

Understanding Existing Processes relies on graphical documentation and/or process

modelling tools that are useful for arriving at and documenting a current

understanding of current processes.

Designing and Prototyping the New Process would focus on modelling and analysing

the new process. At this stage, Davenport also highlights that the design process

9

begins simply by starting to build on the high-level process concept that developed

during the visioning stage.

4.3 Accountability Centered Approach

Tseng et al (1998) propose a so called Accountability Centered Approach whereby a

hierarchical decomposition is applied to decompose accountability into sub

accountabilities.

Figure 2: Stages of using ACA approach for business process

design as adapted from Tseng (1998)

Define top level accountability: The top level accountability specifies the ultimate

goal expected to be achieved. In general, the reengineering team can obtain this

important information such as what the deliverables should be and who should be

responsible for the delivery of results from the senior managers or directors.

Define Sub-accountabilities: With the identified top level accountability, the

accountability can be decomposed into sub-accountabilities if necessary. To maintain

the integrity of accountability, the process design team should use the rule of

completeness and the rule of independence. The decomposition of accountability may

be taken iteratively until the desired level of accountability is reached.

Explore possible activities for new process: Based on the sub-accountability defined,

alternative activities for each lowest level sub-accountability need to be explored. To

generate activity alternatives, Designer’s creativity and a radical approach are

required. Brainstorming is a useful technique. The activities supporting each lowest

level sub-accountabilities can be something that has never been considered or adopted

as long as it helps to achieve the accountability. Designers should make sure that

alternative activities satisfy accountabilities.

Evaluate and select new process: Further, all alternative processes are evaluated and

the best alternative would be selected as the new process to be implemented.

Evaluation should be focused on the performance of alternative processes that can be

measured by metrics such as cost, process cycle time, productivity, and quality of the

Define top level accountability

Define sub-accountabilities

Explore possible activities for new process

Evaluate and select new process

10

output, etc…. Techniques like Activity-based costing, Auditing, Focus group, Value

analysis, and Simulation method, can be utilized in the step.

4.4 Muthu et al (1999) Summary of Five BPR Methodologies

Muthu et al (1999) summarized five BPR methodologies as follows:

Feldmann (1998) from his publication entitled The Practical Guide to

Business Process Reengineering using IDEFO proposes a four step approach as

shown below:

1. Develop vision & strategy

2. Create desired culture

3. Integrate & Improve enterprise

4. Develop technology solutions

One thing that is quite unique to Feldmann’s approach is the mention of technology

solutions which Davenport and Tseng et al failed to state. Certainly we cannot

subtract IT from the process, and highlighting its importance during the phase of

reengineering seems very prevalent.

Harrison and Pratt (1993) in their paper entitled A Methodology for

Reengineering Business, advocate a five step approach outlined below:

1. Determine Customer Requirements & Goals for the process

2. Map and Measure the Existing Process

3. Analyze and Modify Existing Process

4. Design a Reengineered Process

5. Implement the Reengineered Process

It seems to me that Harrison and Pratt’s step 2 (Map and Measure the Existing

Process) is not much different from step 3 (Analyze and Modify Existing Process), as

the two steps seem to imply some sort of study of the current business processes.

Furey (1993) in his article on A Seven Step Guide to Process

Reengineering outlines the following steps:

1. Set Direction

2. Baseline and Benchmark

3. Create the Vision

4. Launch Problem Solving Projects

5. Design Improvements

6. Implement Change

7. Embed Continuous Improvement

From Furey’s perspective, we see a different angle of BPR, that attempts to consider

system evolution through continuous improvement and troubleshooting through

problem solving projects.

Mayer and Dewitte (1998) in their paper on Delivering Results:

Evolving BPR from art to engineering, have equally presented a seven step approach

which encompass the following:

11

1. Motivating Reengineering

2. Justifying Reengineering

3. Planning Reengineering

4. Setting up for Reegineering

5. As Is Description & Analysis

6. To-Be Design and Validation

7. Implementation

It could be argued that Mayer and Dewitte first step on Motivating Reengineering,

sounds like a sale of a BPR project to the organisation without taking into account the

views or the fact that whether there is a need for reengineering or not.

Manganelli and Klein (1994) in their book entitled The Reengineering

Handbook: A Step-by-Step Guide to Business Transformation highlight the following

five steps:

1. Preparation

2. Identification

3. Vision

4. Technical & Social Design

5. Transformation

Though Manganelli and Klein’s steps are viewed to be rather brief, they are rather

direct, but in contradiction to their choice of sequence, it is perceived that Vision (3)

should precede Preparation (1). In other words, we could argue that there cannot be

planning or preparing without an understanding or knowledge of the organisation’s

vision.

4.5 Conclusion

It is noticeable that there are some similarities between Davenport and Tseng et al

approach. Davenport’s first step of “Identifying processes for innovation” and Tseng

et al first stage of “Define top level accountability”, are both geared at finding out

what is it exactly that the organisation want to change and why, presumably at this

stage an idea for the revelation of business aims and objectives that are driving the

change.

Tseng et al stage of “Evaluate and select new process” and Davenport’s step of

“Designing and prototyping new process”, both imply an iterative model of a user

centered development, whereby working parts of the process are constantly tested and

refined according to the customer needs. This cycle is usually maintained until a

suitable end result is achieved.

The only difference I seem to find however, is that Davenport’s approach seems more

practical and could easily be adapted in any organisation, whether big or small,

whereas, Tseng et al approach seems a little bit more complicated especially because

of the language used, as words such as ‘accountability’ are fairly strong and implies

quite a lot of responsibilities in their nature. Furthermore, I still do not see the

correlation between process redesign and process accountability. From a project

management perspective, I would probably give in by saying that Tseng et al

approach could be used for larger organisations with a lot of hierarchical layers and

lengthy chains of processes.

12

Taking into account all approaches including the ones from all the authors presented

by Muthu et al (1999), it is evident that they all seem to consider some sort of

planning before moving on to the redesign and reengineering.

5. BPR Tools

5.1 Introduction

BPR like any other approach in systems development, is supported by a number of

specialist tools that help carry out the necessary steps to a successful reengineering. In

this section of the review, we will explore a sampling of some of the commercial BPR

tools outlined by Corbin (1996).

5.2 Tools

5.2.1 WorkFlow Analyzer

This is a software that addresses the entire BPR life cycle, including data capture,

process modelling, simulation, implementation and continuous improvements. It uses

a graphical language to express complex data sets pertaining to budgets, staffing and

equipment requirements. The software equally enables users to test assumptions,

analyze alternatives and measure results.

5.2.3 Simprocess

This is a simulation tool that is also designed for business process modelling and

analysis. When used in conjunction with the company’s object-oriented simulation

languages, Simprocess can help reduce the time spent on mapping reengineering

components.

5.2.4 ReThink

Uses a combination of object-oriented technology with interactive graphics to produce

a tool that provides user-friendly modelling and simulation. The software helps users

monitor process performance and manage real-real time operations.

5.2.5 Extend+BPR

This software package includes 90 pre-built blocks to help users create reengineering

models. It features drag and drop modelling, animation, spreadsheet connectivity and

customized reporting.

5.2.6 Optima

This is a Window application that features process modelling, simulation and

reporting capabilities. It also helps users quickly create and edit presentation-quality

process maps.

5.2.7 SA/BPR Professional

This package analyses what controls the execution of a function, who performs the

function, and what objects or data are produced by the function. It features a built-in

reporting language with a graphical-user interface for creating customized reports.

5.2.8 Composer

This tool enables organisations to use model-driven development to rapidly design,

build, test, install and maintain reengineering applications.

13

5.2.9 BPwin

Activity-based costing metrics are the major feature of this business analysis tool,

which also interfaces with a family of database design tools.

5.2.10 Service Model

This Windows-based simulation tool enables users to test the behaviour and prove the

benefits of redesigned processes before committing to change.

5.2.11 Integrated Modelling Framework

Integrated Modelling helps identify redundancies and non-value-added activities, and

creates a better understanding of relationships.

5.2.12 Process Charter

This tool helps managers visualize flow paths through a process. Resources can be

defined and assigned to different steps of the process and color animated simulations

can identify key constraints.

5.2.13 BPSimulator

BPSimulator provides activity-based analysis by enabling users to track cycle times

and costs of multiple business processes.

5.2.14 Framework

Framework offers an integrated set of object-oriented tools that enable users to create

interactive blueprints of business processes. Software code can be generated from the

hierarchical layout, providing rapid and consistent application development.

5.2.15 FirstSTEP

FirstSTEP is equally a business-process modelling and simulation tool that

incorporates object-oriented technology, and provides reporting and analysis on static

and dynamic states of BPR models.

5.3 Evaluating BPR Tools

Gruninger (2005) present a set of questions which can be used to evaluate BPR tools

with respect to the BPR framework, though he insists that this will require that we

first define the necessary properties of any tools for a particular stage of BPR.

Thus, we must look at the given framework and specify the required expressiveness of

models, the set of analysis tasks, the automation of these analysis tasks, the set of

possible intended users at different stages and their requirements, and the relationship

between these properties and the tool’s software functionality and visualization

(Gruninger, 2005).

Then subsequently, some of the key questions proposed by Gunner (2005) to evaluate

those tools are:

Does the tool provide a repository of models for different enterprises,

problems and solutions?

Can we export and import models with other tools?

Is the tool customizable to the class of problems and the class of users?

Can the tool access information that is available in different forms?

14

Does the tool provide an environment for “meaning mapping”? This involves

identifying the relevant assumptions used by different people, tools, or

enterprise models, and the ability to capture multiple synonyms and utilize

them in translation to various audiences.

Can the tool manage different kinds of data at different levels of formality?

Can the tool represent the enterprise at different levels of abstraction?

Is the tool opportunistic in providing information by tracking the information

that is required?

Can new models be created from old models using templates?

Does the tool have the capability of dynamically constructing and modifying

models?

Can the tool be characterized as an intelligent project coach, that guides the

implementation through the different phases?

Does the tool provide guidelines for establishing experiments useful to

understanding areas that would improve process performance?

In light of Guninger’s evaluation criteria, we could inevitably condone the

development of more AI3 tools to support BPR.

Irani et al (2005) draw attention to the view that most of these tools are not able to

conduct “what if” analysis and show a dynamic change of business processes and

evaluate the effects of stochastic events and random behaviour of resources, which is

possible by using simulation models of business processes. Thus we could agree that

these tools lack built in risk analysis elements, that could pin point possible areas of

danger during the reengineering process.

5.4 Conclusion

So far, none of the literature explored seems to provide a critical evaluation of the

tools outlined above, but it is possible to say that one feature that they all lack is the

support of any known BPR methodology or approach. Ironically, none of the authors

who researched on BPR methodologies makes mention of any of the tools outlined to

be used in conjunction with their approach.

However, the most common features that the majority of these tools share, are process

modelling, resource allocation, activities scheduling and support of an object-oriented

approach to systems analysis and design.

3 AI (Artificial Intelligence) is the science and engineering of making intelligent machines, especially

intelligent computer programs.

15

6. Information Systems Development Techniques that could be

applied in BPR

6.1 Introduction

There is actually surprisingly little guidance as to how to conduct a reengineering

project (Beynon-Davies, 1998: 249). Hence it may be quite inevitable to explore

current IS development methodologies.

One of the most interesting contemporary applications of systems analysis methods is

BPR (Whitten et al, 2004:192). In retrospect to Whitten et al, it is possible to say that

BPR uses systems analysis methodologies.

Whitten et al also go on to say that some BPR projects focus on all business

processes, regardless of their automation. Each business process is thoroughly studied

and analysed for bottlenecks, value returned, and opportunities for elimination or

streamlining. Once the business processes have been redesigned, most BPR projects

conclude by examining how information technology might best be applied to the

improved business processes. (Whitten et al, 2004:192).

Before moving on further in this section that will focus entirely on process analysis

and design techniques, let us first of all agree on the definition of a business process.

Davenport and Short (1990) cited by Malhotra (1998), amongst other definitions

define business process as a set of logically related tasks performed to achieve a

defined business outcome. As for the word process, Davenport (1993) still cited by

Malhotra, states that it is a structured, measured set of activities designed to produce a

specified output for a particular customer or market.

Hence, when we take a closer look at some of the systems development

methodologies that have techniques for analysing current business processes and

redesigning them, we find that there is the SSADM4 Data Flow Diagram and the

OOAD5 Activity and Use Case Diagrams using UML

6 notation.

In this section, we have therefore split the techniques in two categories, Business

Process Analysis which is entirely devoted to studying current processes and Business

Process Redesign which is solely aimed at designing new processes.

6.2 Business Process Analysis

6.2.1 SSADM Physical Data Flow Diagram

Physical DFDs are used to document exactly how processes are carried out in the real

world (Weaver et al, 2002:136). We cannot redesign a business process, without

having an understanding of how that process works, thus the Physical DFD helps

secure just that. With the Physical DFD, we are able to visualize the sort of

documents or information that flow in the organisation in order to initiate a process,

and how they are filed. Through the realisation of any given process within the

physical DFD, we are also able to identify the end results of that process.

4 SSADM (Structured Systems Analysis and Design Methodology) uses a process based approach for

systems analysis. 5 OOAD (Object Oriented Analysis and Design) uses an object oriented approach for systems

6 UML (Unified Modelling Language) is a type of notation used in OOAD.

16

Figure 1: ZigZag Physical DFD adapted from Weaver et al (2002:127)

The sample Physical DFD in fig 1, belongs to a company known as ZigZag, which is

a music a media distribution company, that sells entertainment products in various

formats including CDs, DVDs and videos to customers throughout the UK.

Looking at ZigZag’s Physical DFD, we can observe how the various staff involved in

the organisation carry out their activities. For example, if we take a closer look at the

top right corner of the diagram, we can see that in order to realize the process of

“Allocate Despatch” the Sales and Marketing department put in Customer Order

which are processed by the Despatch Clerk whom as a result produces a Despatch

Report for the Despatch Supervisor. The information of the process is stored in the

“Stock” data store (M2).

17

Despite the space that could be taken up to draw the Physical DFD, depending on the

size of the organisation, its efficiency in studying current business processes prior

redesign is almost unquestionable.

6.2.2 OOAD Activity Diagram using UML notation

Activity diagrams can be used to model different aspects of a system. At a high level,

they can be used to model business activities in an existing or potential system.

(Bennett et al, 2002:105).

There is no doubt that business activities are perceived as processes from an analytical

point of view. As it is almost evident that we cannot have a process without an

activity.

Unlike the Physical DFD, the Activity diagram provides an indication of the sequence

of activities. However, it also shows the author of each activity, so at least we have a

better understanding of what goes on within the organisation.

Figure 2: Agate Ltd Activity Diagram adapted from Bennett et al (2002:109)

Agate Ltd is an advertising agency in Birmingham, and the Activity diagram in Fig 2,

demonstrates the nature of some of the business activities performed by the

organisation and as a result, we could see that from a BPR perspective we have

something concise to help us understand what goes on. In contrast with the Physical

DFD, the Activity Diagram does not give an indication of the documents that flow in

and out of the organisation, and it could be argued that perhaps they do not play an

important role after all in studying current business processes, as what is more

important is identifying the processes and knowing how they are coordinated.

18

6.3 Business Process Redesign

6.3.1 Logical Data Flow Diagram

Figure 3: ZigZag Logical Data Flow Diagram adapted from Weaver et al (2002:174)

19

A Logical DFD represents logical information, not the physical aspects (Avison &

Fitzgerald, 2003: 206). Thus, it could also be said that at this stage, everything is

represented in such a way that if the processes are to be reengineered with the use of

IT, we would have the operations that the new system would perform at least in a

language that is software driven, nor physical. For example if we look back at fig 1

(Physical DFD) in Process No 4 the Despatch Supervisor puts in the Despatch Report

Copy, whereas in the Logical DFD in fig 3, for a redesigned process, he puts in

Despatch Instructions instead in Process No 4.

6.3.2 OOAD Use Case Diagram using UML notation

Bennett et al (2001:25) state that the Use case Diagram is an effective means of

communicating with users and other stakeholders about the system and what is

intended to do. It seems obvious that we are now increasingly using the word system

in this phase of Process Redesign, but it is almost certain that the Use Case diagram

gives us an indication of what the new system is intended to do by telling us about the

process involved through use cases and the actors performing those processes.

Figure 4: Agate Ltd Use Case Diagram adapted from Bennett et al (2002:152)

Looking at the Use Case diagram in fig 4, it is possible to say that redesigned business

processes could well be modelled using Use Case Diagrams, as they contain

information that would lead the developer in process reengineering with IT.

20

6.4 Conclusion

Subsequent to my literature quest on BPR Methodologies, it is true to say that there

do not exist a specific one, but rather a game of pick and match from existing systems

development methodologies. It could be argued that the business process analysis and

the redesign could well be modelled using one technique, and my view is that BPR

project stakeholders must decide which technique has proven more successful and

easier to apply and modify.

Although SSADM models are sequential and generate more paperwork, they may

prove efficient, if one is dealing with a fairly large organisation. But the drawback

with OOAD modelling using UML, is that often if we are dealing with a lot of

processes and quite a greater variety of users or stakeholders, the drawing space to

model the organisation processes would be equally limited.

7. Similarities between System Development and BPR Henne and Moller (1995) argue that one of the most known system development

methods, being the Structured Analysis and Design Method includes the concept of

logical dataflow diagrams, which is the technique that should help the system

developers to think about the minimum set of functions needed to run a business

function. We could therefore agree with Henne and Moller on the fact that the study

of business processes seems to be the communal junction between the two concepts.

Kimble and Quarmby (1998) also outline that the similarities between Object

Orientation as a systems development approach and BPR seem to be that they both

have principles, consequences and benefits. One common principle is that they both

require continuous improvement, as regard to the benefits, a common one is that they

both have the ability to develop systems incrementally, and as for the consequences,

one is that they both have an increased re-use of components.

If we apply a historical perspective, we will argue that BPR is not quite as new an

invention as its gurus often argue (Henne and Moller, 1995). Perhaps it is wise to say

that BPR is just an extension of the analysis stage of the systems development

process.

8. Differences between System Development and BPR Having looked at the similarities between the two concepts, the idea that there could

even be some differences is quite questionable. But according to Henne and Moller,

an important distinction between traditional system development and BPR is that the

latter demand a radical and dramatic improvement of the organisation. Though in

opposition with Henne and Moller’s view, we could also argue that system

development could also bring radical and dramatic improvement to the organisation.

BPR stresses use of IT in an innovative and creative way, and challenges the business

world to break established rules by applying new technology (Henne and Moller,

1995). Both authors went on further to say that BPR directs us to think inductively of

technology during the reengineering process rather than to analyze and try to find

solutions to already known problems. Despite the fact that we could still dispute this

view by saying that the analysis of current business processes applied in BPR does

inevitably imply some sort of understanding of problems with the existing system.

21

9. Assessing Success of BPR Projects Boudreau and Robey (1996) indicate that because there is no generally accepted

measure to assess the outcomes of reengineering, it is wrong to assume that the rate of

success from different studies can be reliably compared. However, Cafasso (1993)

cited by Boudreau and Robey (1996) highlight the fact that a project is considered as

a failure when it is completely abandoned or changed for something more

incremental. Nevertheless, both Boudreau and Robey question whether success could

be measured on economic results, or managers and employees perceptions, but the

answer to their question could only derive from a proven empirical study.

But we could argue that the measurement of all the three factors questioned by

Bourdeau and Robey would form quite a basis for measuring the success a BPR

project.

But Trimble (2005) highlight the fact that the measurement system should cover the

following areas at a minimum:

Customers

Performance against customer requirements

Customer satisfaction

Performance of internal work processes

Cycle times

Product and service quality

Cost performance (could be productivity measures, inventory, etc..)

Suppliers

Performance of suppliers against your requirements

Financial

Profitability (could be at the company, product line, or individual level)

Market share growth and other standard financial measures

Employee

Associate satisfaction

Trimble’s measurement approach seems rather effective in the sense that it does take

into account all the key entities of an organisation and the variables that affect its

success. However, the one metric that all three authors agree on, is the financial or

economic aspect, which has traditionally been used to measure the value of any

commercial organisation.

10. Research and Development

10.1 Introduction

We cannot arrive at drawing potential research areas in BPR, without a knowledge of

previous research. This section of the literature review on BPR would look at the

issues addressed in previous research and give an indication of future work.

10.2 Previous Research Issues

Al-Mashari et al (2001) summarized a list of six representative empirical studies on a

variety of BPR issues, as outlined in Table 1.

22

Author Themes of Research

Doherty and Hosted (1996) - Organisations becoming

increasingly aware of survivor

syndrome during and after BPR.

- Managing both leavers and

survivors a necessity in managing

major change.

- Successful BPR must consider

people-related issues at three

levels: organisational change,

personal transition and

psychological contract.

Zairi and Sinclair ((1995) - Organisations that have adopted

TQM show greater use of

strategic and process management

techniques, benchmarking, and

self assessment in BPR efforts.

- On project basis, BPR appears

less successful at TQ

organisations.

ProSci (1997) - Ensuring sponsorship, creating

strategic alignment, building

strong teams, establishing

business case for change, using

proven methodology, and

managing change effectively are

areas critical to successful BPR

projects.

Hewitt and Yeon (1996) - Ranking of management

philosophies, objectives, ant

techniques associated with BPR.

- BPR practice in terms of duration,

initiators, scope, success factors,

and drivers.

Braganza and Myers (1996) - Degrees of awareness of BPR by

different management personnel.

- Ranking of key reasons for doing

BPR.

- BPR is adopted alongside other

change initiatives.

- Identifying degree of importance

and difficulty associated with five

essential items.

Kohli and Hoadley (1997) - BPR concepts and tools assessed

considered useful.

- BPR effective approach to

improve competitiveness.

- BPR not a passing fad.

- 40% of responding organisations

are planning for more BPR in

future.

Table 1: Summary of Previous Research Issues (Al-Mashari et al, 2001)

23

Henne and Moller (1995) also addressed an important research question, which was:

can BPR and innovation in business process be studied according to the same

principles as used in studies of information systems, what are the consequences of this

alternative, and do we have other alternatives?

Hadi et al (2005) have recently completed a study on prioritizing barriers to

successful BPR efforts in Saudi Arabian construction industry.

Kai Artur (2003) investigated the use of BPR as a change approach in the

pharmaceutical industry.

Clausen, Christian et al (1998) have carried out a study sponsored by the European

Commission, destined to investigate the choices surrounding BPR concepts and their

appropriateness in different national, industrial etc. contexts and to explore the

opportunities for developing socially feasible and acceptable BPR-oriented concepts,

in order to contribute to the development of a European model for long term

sustainable economic development.

Reijers (2004) investigates the possibility for extending the capabilities of intelligent

software tools for workflow process design.

10.3 Future Work

The testing of Case-Based Reasoning (CBR) as a technique for knowledge

management in BPR, as suggested by Mansar et al (2003) could be a breakthrough in

improving the results of BPR projects.

The development of a BPR tool that supports a BPR methodology or approach seems

increasingly essential to automate the steps prescribed in the given reengineering

process.

We could also advocate the development of a universal metric system used to

measure the success of BPR.

Testing the use of a Meta-Model that takes into account principles of Evolutionary

Delivery and Evolutionary Development as suggested by Johnson and Stergiou

(2005).

The development of an AI tool that helps identifying the effects of redesigned

processes before they are implemented, as the lack of such a tool was found to be one

of the main reasons of BPR project failure as indicated by Irani et al (2005).

Investigating the use of Class Based Reengineering to optimize BPR, seems a likely

research theme that would aid to prove its suitability.

11. Discussions Though the terms Business Process Reengineering, Business Process Redesign and

Business Process Renovation all share the acronym BPR, it makes it increasingly

difficult to extricate one from the others. However, due to the common definition of

business process change that they all share, it does help to keep the focus on BPR as a

concept.

24

It is equally surprising that even authors cannot agree on the right spelling of the word

re-engineering, as others would spell it as “Re-engineering” and some as

“Reengineering” this unavoidably gives rise to further misunderstanding,

disagreement, and controversies that surround the term BPR.

No literature on BPR would not mention the work of Hammer, or Champy or

Davenport, whom we know have excelled in pioneering research in BPR. But as

result subsequent methodologies or approaches on the concept lack originality, as they

all contain genes of the masters.

BPR is not new as a concept as what some authors have claimed in the time of their

publication, it is even possible that business process change might have existed even

long before its pioneers wrote about it, but it might have been known as a practice

under a different umbrella.

If more BPR projects are a failure as opposed to success, then there must be

something wrong with the concept or how it is applied. Though others may argue that

BPR is now old and approaching the end of its time, its revival may come when there

is a universally successfully proven methodology that aids its application.

Far little research has been carried out to assess the functionality of any given

approach in BPR, which often leads me to ask the question as to why is it that most

researchers in the field spend more time developing and suggesting new approaches

or methodologies for BPR than actually testing them? A simple answer could be due

to the fact that in the world of academia, we all want to score point in some creative

knowledge, but what about proving to the commercial world that our solutions work?

Should we leave BPR research to the practitioners as they have access to

organisations through which any approach may be tested on? Or, should we reserve

the theories, but often not yet put into practice, that would just be piling up literature

upon literature with words ,but very little action.

Should the task of carrying out BPR be left to BPR Consultants or Systems Analysts

who are at least more aware of system development lifecycle and equally

knowledgeable on BPR? Though BPR project teams may usually comprise of

organisation’s senior managers, BPR consultants, systems analysts and developers, it

may be more advantageous if tasks that imply process analysis and redesign are solely

left in the capable hands of systems analysts. As the latter are aware of a number of

methodologies that would best suit the organisation’s needs. However, without

patronizing the role of BPR consultants who may even come from a systems analysis

and design background, the debate on who should lead the team is certainly opened

for discussion.

Most authors agree that there is no cookbook for BPR, usually most of its

practitioners begin with a clean sheet and develop their own approach as they feel

appropriate. Hence, there is no doubt from a professional point of view, that this is a

messy and disorganised concept. Despite the fact that Hammer and Davenport have

given indications on how the concept should be applied, the debate is how many

practitioners actually follow the steps that the two have prescribed? As most BPR

organisations tend to use their own approach that perhaps may have proven to be

successful for them.

25

The intervention of AI researchers in developing BPR tools that carry out some risk

analysis for redesigned processes before they are implemented seems increasingly

necessary. Although the success of such developments would depend on the

involvement of IS professionals, management and BPR consultants.

Case-Based Reasoning as a technique for knowledge management and Class-Based

Reengineering as an approach to business modelling, both do not support nor promote

the use of any particular tool. The question asked is then, what tool shall we use to get

maximum benefits from these two approaches?

The idea of realigning systems redevelopment methodologies and BPR in order to

maintain efficiency in legacy systems migration seems to pose a challenge that may

require a methodology that actively integrates both disciplines.

Irrespective of the fact that a user-centered development has been advocated time

after time in order to design what the user wants, we have to be delicate about solving

conflicting requirements and managing consensus in order to make a decision on the

ultimate choice of design.

12. Conclusions It is perceivable that BPR seems to act as a roundabout where IT Management and

Information Systems Development meet at least once in a lifetime of any

organisation.

More work is required to redesign and reengineer BPR itself as a concept, than its

successful application in organisations.

In the light of all the controversies surrounding BPR, its future may seem bleak, but

the truth is that organisations need it to enhance their profits, and the challenge

therefore remains in knowing how to apply it well.

13. References Grint, Keith et al. (1995) Business Process Reengineering Reappraised: The Politics

and Technology of Forgetting. Chapman & Hall.

Hammer, M and Champy, J. (1993) Reengineering The Corporation: A Manifesto For

Business Revolution, Harper Business.

Davenport, Thomas. (1995) Business Process Reengineering: Where It’s Been, Where

It’s Going. IDEA Group Publishing.

Hansen, Gregory (1994) Automating Business Process Reengineering. Prentice Hall.

PP1.

Whitten, Jeffrey et al. (2004) Systems Analysis and Design Methods. McGraw-Hill.

PP 192.

Weaver, Philip et al. (2002) Practical Business Systems Development Using SSADM.

Prentice Hall. PP 22, 127, 136.

Bennett, Simon et al (2002) Object-Oriented Systems Analysis and Design. McGraw

Hill. PP 105, 109.

26

Avison, David and Fitzgerald, Guy. (2003) Information Systems Development.

McGraw Hill. PP 206.

Bennett, Simon et al. (2001) UML. McGraw-Hill. PP 25.

Beynon-Davies, Paul. (1998) Information Systems Development. McMillan Press Ltd.

PP 244, 246 – 247

Davenport, Thomas. (1993) Process Innovation. Reengineering Work through

Information Technology. Harvard Business School Press. PP 200 – 207.

Tseng, Mitchell et al. (1998) Accountability Centered Approach to Business Process

Reengineering. Industrial Engineering and Engineering Management Department,

Hong Kong University of Science and Technology. IEEE.

Malhotra, Yogesh. (1998) Business Process Redesign: An Overview. IEEE

Engineering Management Review, vol. 26, no. 3, Fall 1998. [Online]. Available at:

http://www.kmbook.com/bpr.htm

Henne, Anne and Moller, Eva (1995). Innovation in Business Processes. A Discussion

of Research Methods to Study the Process of Innovation. Department of Information

Science, University of Bergen.

Boudreau, Marie-Claude and Robey, Daniel (1996). Coping with contradictions in

Business Process Reengineering. Information Technology & People. Vol. 9 No. 4,

PP. 40-57.

Hadi, Nader Abdul et al (2005). Prioritizing barriers to successful BPR efforts in

Saudi Arabian construction industry. Routledge, part of the Taylor & Francis Group.

Volume 23, No 3, March 2005.

Kai Artur, Simon (2003). BPR in the Pharmaceutical Industry. School of Economics

and Law. Electronic Publishing Centre. Goteborg University.

Clausen, Christian et al (1998). Process Re-Engineering in Europe: Choice, People

and Technology. European Commission Key Action- Socio-economic Research.

Reijers, H.A. (2004). Intelligent Software Tools for Workflow Process Design.

Technische Universiteit, Eindhoven.

Folorunso, Olusegun and Ogunde, Adewale (2004). Data Mining as a Technique for

Knowledge Management in Business Process Redesign. The Electronic Journal of

Knowledge Management, Volume 2, Issue 1, PP 33-44.

Sayer, Kylie and Harvey, Lynda (1997). The Panopticon and Rhetoric of

Empowerment in Business Process Reengineering. [Online]. Available at:

http://linus.socs.uts.edu.au/jim/bpt/s9719.html

Johnson, Leslie and Stergiou, Maria (2005). The Link Between BPR, Evolutionary

Delivery and Evolutionary Development. Computing Laboratory, University of Kent.

Muthu, Subramanian et al (1999). Business Process Reengineering: A Consolidated

Methodology. Proceedings of The 4th

Annual International Conference on Industrial

27

Engineering Theory, Applications and Practice, November 17-20, San Antonio,

Texas, USA.

Mansar, Selma et al (2003). Case-Based Reasoning as a Technique for Knowledge

Management in Business Process Redesign. Electronic Journal on Knowledge

Management. Volume 1, Issue 2, PP 113-124.

Corbin, Lisa (1996). Tools of the Trade. GOVEXEC Magazine. September 1.

Gruninger, Michael (2005). Characterization of Tools for Business Process

Reengineering. Available at: http://www.el.utoronto.ca/grpdoc/tooleval.html

Morgan, David (2004). BPR Unwrapped. PHS Management Training.

Irani, Zahir et al (2005). Business Process Re-Engineering: A Modelling Perspective.

[Editorial].

Aeria, Shawn (2002). Business Process Reengineering: Difficulties in

Implementation. San Diego State University.

Trimble, Dave (2005). How to Measure Success: Uncovering the Secrets of Effective

Metrics. BPR Online Learning Centre. ProSci. Available at:

http://www.prosci.com/metrics.htm

Johnson, Leslie and Stergiou, Maria (2005). BPR-Enabled Systems Engineering.

World Scientific.

Newman, David (1996). Class-Based Reengineering: Reconstructing the Enterprise

through Classes. Object Magazine, March 1996.

Ulrich, William (1995). Business Process Redesign and the Legacy Systems

Challenge. Tactical Strategy Group, January 1995.

Kimble, Chris and Quarmby, Shirley (1998). The Role of Business Process Re-

engineering and Object Orientation in Organisations. 8th

Annual BIT Conference,

4/5th

November 98.

Dumay, Mark (2005). Business Processes. The Theoretical Impact of Process

Thinking on Information Systems Development.