IS AUDITING GUIDELINE

BUSINESS PROCESS REENGINEERING (BPR)

PROJECT REVIEWS DOCUMENT G26
The specialised nature of information systems (IS) auditing and the skills necessary to perform such audits require standards that apply
specifically to IS auditing. One of the goals of the Information Systems Audit and Control Association (ISACA) is to advance globally
applicable standards to meet its vision. The development and dissemination of the IS Auditing Standards are a cornerstone of the ISACA
professional contribution to the audit community. The framework for the IS Auditing Standards provides multiple levels of guidance.

Standards define mandatory requirements for IS auditing and reporting. They inform:
− IS auditors of the minimum level of acceptable performance required to meet the professional responsibilities set out in the ISACA Code
of Professional Ethics for IS auditors
− Management and other interested parties of the profession’s expectations concerning the work of practitioners
®
− Holders of the Certified Information Systems Auditor (CISA ) designation of requirements. Failure to comply with these standards may
result in an investigation into the CISA holder's conduct by the ISACA Board of Directors or appropriate ISACA committee and, ultimately,
in disciplinary action.

Guidelines provide guidance in applying IS Auditing Standards. The IS auditor should consider them in determining how to achieve
implementation of the standards, use professional judgment in their application and be prepared to justify any departure. The objective of the
IS Auditing Guidelines is to provide further information on how to comply with the IS Auditing Standards.

Procedures provide examples of procedures an IS auditor might follow in an audit engagement. The procedure documents provide
information on how to meet the standards when performing IS auditing work, but do not set requirements. The objective of the IS Auditing
Procedures is to provide further information on how to comply with the IS Auditing Standards.

COBIT resources should be used as a source of best practice guidance. Each of the following is organised by IT management process, as
defined in the COBIT Framework. COBIT is intended for use by business and IT management as well as IS auditors; therefore, its usage
enables the understanding of business objectives, and communication of best practices and recommendations, to be made around a
commonly understood and well-respected standard reference. COBIT includes:
− Control Objectives—High-level and detailed generic statements of minimum good control
− Control Practices—Practical rationales and guidance on how to implement the control objectives
− Audit Guidelines—Guidance for each control area on how to obtain an understanding, evaluate each control, assess compliance and
substantiate the risk of controls not being met
− Management Guidelines—Guidance on how to assess and improve IT process performance, using maturity models, metrics and critical
success factors

Glossary of terms can be found on the ISACA web site at www.isaca.org/glossary. The words audit and review are used interchangeably.

Disclaimer: ISACA has designed this guidance as the minimum level of acceptable performance required to meet the professional
responsibilities set out in the ISACA Code of Professional Ethics for IS auditors. ISACA makes no claim that use of this product will assure a
successful outcome. The publication should not be considered inclusive of any proper procedures and tests or exclusive of other procedures
and tests that are reasonably directed to obtaining the same results. In determining the propriety of any specific procedure or test, the
controls professional should apply his/her own professional judgment to the specific control circumstances presented by the particular
systems or information technology environment.

The ISACA Standards Board is committed to wide consultation in the preparation of the IS Auditing Standards, Guidelines and Procedures.
Prior to issuing any documents, the Standards Board issues exposure drafts internationally for general public comment. The Standards
Board also seeks out those with a special expertise or interest in the topic under consideration for consultation where necessary. The
Standards Board has an ongoing development programme and welcomes the input of ISACA members and other interested parties to
identify emerging issues requiring new standards. Any suggestions should be e-mailed (standards@isaca.org), faxed (+1.847. 253.1443) or
mailed (address at the end of document) to ISACA International Headquarters, for the attention of the director of research standards and
academic relations.

This material was issued on 1 April 2004.

Information Systems Audit And Control Association 2003-2004 STANDARDS BOARD

Chair, Claudio Cilli, Ph.D. CISA, CISM, CIA, CISSP Value Partners, Italy
Svein Aldal Scandinavian Business Security AS, Norway
John W. Beveridge, CISA, CFE, CGFM, CQA Commonwealth of Massachusetts, USA
Sergio Fleginsky, CISA PricewaterhouseCoopers, Uruguay
Christina Ledesma, CISA, CISM Citibank NA Sucursal, Uruguay
Andrew J. MacLeod, CISA, FCPA, MACS, PCP, CIA Brisbane City Council, Australia
Ravi Muthukrishnan, CISA, CISM, FCA, ISCA NextLinx India Private Ltd., India
Peter Niblett, CISA, CA, MIIA, FCPA WHK Day Neilson, Australia
John G. Ott, CISA, CPA Aetna Inc., USA
 1. BACKGROUND

1.1 Linkage to Standards

1.1.1 Standard S6 Performance of Audit Work states, "During the course of the audit, the IS auditor is to obtain sufficient, reliable and
relevant evidence to achieve the audit objectives. The audit findings and conclusions are to be supported by appropriate analysis
and interpretation of this evidence."
1.1.2 Guideline G17 Effect of Nonaudit Roles on the IS Auditor’s Independence provides guidance.
1.1.3 Guideline G21 ERP Systems Review provides guidance.

1.2 Linkage to COBIT

1.2.1 COBIT Framework states, "It is management's responsibility to safeguard all the assets of the enterprise. To discharge this
responsibility, as well as to achieve its expectations, management must establish an adequate system of internal control."
1.2.2 COBIT Management Guidelines provides a management-oriented framework for continuous and proactive control self-assessment
specifically focused on:
„ Performance measurement—How well is the IT function supporting business requirements?
„ IT control profiling—What IT processes are important? What are the critical success factors for control?
„ Awareness—What are the risks of not achieving the objectives?
„ Benchmarking—What do others do? How can results be measured and compared?
1.2.3 Management Guidelines provides example metrics enabling assessment of IT performance in business terms. The key goal
indicators identify and measure outcomes of IT processes, and the key performance indicators assess how well the processes are
performing by measuring the enablers of the process. Maturity models and maturity attributes provide for capability assessments
and benchmarking, helping management to measure control capability and to identify control gaps and strategies for
improvement.
1.2.4 Management Guidelines can be used to support self-assessment workshops, and they also can be used to support the
implementation by management of continuous monitoring and improvement procedures as part of an IT governance scheme.
1.2.5 COBIT provides a detailed set of controls and control techniques for the information systems management environment. Selection
of the most relevant material in COBIT applicable to the scope of the particular audit is based on the choice of specific COBIT IT
processes and consideration of COBIT’s information criteria.
1.2.6 A COBIT reference is located in the appendix of this document for the specific objectives or processes of COBIT that should be
considered when reviewing the area addressed by this guidance.

1.3 Need for Guideline

1.3.1 Manufacturing and service organisations are taking an increasing interest in business process reengineering (BPR) to support
their evolution in a dynamic and rapidly changing business environment. BPR offers an invaluable opportunity to achieve a real
breakthrough in business performance, but it also introduces risks, for example, in the case of wrong reengineering choices or of
inadequate implementation of the devised changes.
1.3.2 Reengineering involves comprehensive changes not simply to business processes but to management and support structures,
people and organisation, technology and information systems, and policies and regulations. That means that BPR projects have a
strong effect on the control system of the organisations that have implemented the BPR. Specifically, there is an increased risk
that essential controls are reengineered out of the process to expedite business transactions. Accordingly, the IS auditor should
be cognisant and espouse to management that controls, though they appear in nature to slow the process down, are a necessity
to avoid risk that cannot be easily managed or measured in either likelihood or effect.
1.3.3 The purpose of this guideline is to provide IS auditors with the basic reengineering issues as a framework for assessing the key
tasks and risks associated with BPR projects with special attention to the IS aspects.

2. BUSINESS PROCESS REENGINEERING PROJECTS

2.1 Definition
2.1.1 Although there is no universally accepted definition of business process reengineering, the definition most often quoted is that
offered by Hammer and Champy: The fundamental rethinking and radical redesign of business processes to bring about dramatic
1
improvements in critical, contemporary measures of performance, such as cost, quality, service and speed.
2.1.2 BPR aims to improve business processes by substantially revising their structure and by dramatically changing the way in which
the processes are managed and implemented. This ordinarily produces a great effect on the people involved and the working
practices and supporting technologies, particularly information technologies.

2.2 BPR Key Results

2.2.1 A BPR project is extremely pervasive. The effect is a substantial modification of all organisation processes and relationships. The
main results of a BPR project can therefore be summarised as follows:
„ Strategic in concept
„ New business priorities based on value and customer requirements (customer driven, output focused) with concentration on
process (focus on key business processes) as a means of improving product, service and profitability
„ New approaches to organising and motivating people inside and outside the enterprise
„ New approaches to the use of technology in developing, producing and delivering goods and services
„ Redefined roles for suppliers, including outsourcing, joint development, quick response, just-in-time inventory and support

1
Hammer and Champy, Reengineering the Corporation, 1993

Page 2 BPR Guideline

 „ Redefined roles for clients and customers providing them with more direct and active participation in the enterprise’s
business processes

2.3 BPR Principles and Activities

2.3.1 Principles help with the innovative thinking necessary to change the process structure. The principles are mainly of value in what
is ordinarily the most difficult stage of BPR projects, namely considering the options for changing the process.
2.3.2 The BPR principles suggested by Hammer are as follows:
„ Several jobs are combined into one.
„ Workers make decisions.
„ The steps in a process are performed in a natural order.
„ Processes have multiple versions.
„ Work is performed where it makes the most sense.
„ Checks and controls are reduced (while controls on implementation are critical).
„ Reconciliation is minimised.
„ A case manager provides a single point of contact.
„ Hybrid centralised/decentralised operations are prevalent.

2.3.3 Others, including Carter and Handfield, suggest carrying out the BPR activities in sequence: 1) simplification (which includes
elimination of nonvalue added activities), 2) standardisation, 3) integration, 4) parallelism, 5) variance control, 6) resource
allocation, 7) automation. They indicate the BPR process should tackle steps 1 to 7 in a strict sequence. It would, for example, be
wrong to attempt automating a process with an IT application without first considering its simplification; not only could
simplification make automation redundant but the full benefits of automation may not be realised either. However, there is a
danger in restricting the thinking process to a strict sequence. For example, integration of activities requiring different resources
into a single activity to be carried out by an individual may sometimes become possible only with automation.
2.3.4 Sometimes a holistic view is the best approach.
2.4 BPR Methodology
2.4.1 Reengineering is inherently highly situational and creative. Basically, there are two distinct approaches to BPR that can be found
in the literature.
2.4.2 The methodology originally prescribed by Hammer and Champy is a top-down approach, which suggests that the BPR team
should focus on determining how the strategic objectives of the organisation can be met without letting its thinking be constrained
by the existing process. The emphasis is on the to-be process, and is consistent with the step-change philosophy that the authors
presented.
2.4.3 The more incremental change methodology outlined by Harrington is a bottom-up approach which advocates modeling the
existing process to gain understanding of it, and then streamlining it appropriately to meet the strategic objectives. The focus is on
changing the as-is process by identifying opportunities for improving it.
2.4.4 In practice, a BPR team will ordinarily need to adopt a mixed approach. If the top-down methodology is used as the basis, there is
still a need to understand the current functionality and to define carefully the transition path from the current to the preferred future
process. With a bottom-up methodology, BPR teams can spend too much time on detailing the current process and lose
innovative thinking. A mixed approach would encourage the team to consider high-level changes without being cluttered by the
details of the current process.
2.4.5 It is important to recognise that an initial BPR study may lead to recommendations for a number of more detailed projects on
improving subprocesses, which may only require relatively small changes (perhaps to remove some bottlenecks).

2.5 Six Basic Steps of Several BPR Methodologies

2.5.1 Envision—This stage typically involves a BPR project champion engendering the support of top management. A task force,
including senior executives and individuals knowledgeable about a firm’s processes, is authorised to target a business process for
improvement based on a review of business strategy and IT opportunities in the hope of improving the firm's overall performance.
2.5.2 Initiate—This stage encompasses the assignment of a reengineering project team, setting of performance goals, project planning,
and stakeholder/employee notification and buy-in. This is frequently achieved by developing a business case for reengineering via
benchmarking, identifying external customer needs and cost-benefit analysis.
2.5.3 Diagnose—This stage is classified as the documentation of the existing process and its subprocesses in terms of process
attributes, such as activities, resources, communication, roles, IS and cost. In identifying process requirements and assigning
customers value, root causes for problems surface and nonvalue-adding activities are identified.
2.5.4 Redesign—In the redesign stage, a new process design is developed. This is accomplished by devising process design
alternatives through brainstorming and creativity techniques. The new design should meet strategic objectives and fit with the
human resource and IS architectures. Documentation and prototyping of the new process is typically conducted, and a design of
new information systems to support the new process is completed.
2.5.5 Reconstruct—This stage relies heavily on change management techniques to provide reasonable assurance of a smooth
migration to new process responsibilities and human resource roles. During this stage, the IT platform and systems are
implemented and the users go through training and transition.
2.5.6 Evaluate—The last stage of a BPR methodology requires monitoring of the new process to determine if it met its goals and often
involves linkage to a total quality program.

2.6 BPR Tools

2.6.1 The availability of appropriate BPR tools that help in reducing BPR risks can greatly benefit organisations that undertake BPR.
Given an existing or a new business process, a typical BPR tool supports its modeling, analysis and evaluation, and the simulation
of its probable behaviour.

BPR Guideline Page 3

 2.6.2 As the diagnostic phase (2.5.3) is considered the key for the identification of performance improvement opportunities and
obstacles, BPR tools play an important role in the BPR project. They should be also reviewed by the IS auditor.

2.7 IS Role in the BPR

2.7.1 IS delivers tools and plays four distinct roles within BPR projects.
2.7.2 IS enables new processes. IS may help to devise innovative business processes, which would otherwise not be attainable. IS can
be the key enabler of BPR. The use of IT challenges the assumptions inherent in the work processes that have existed since long
before the advent of modern IT applications. Although BPR can have its roots in IS management, it is primarily a business
initiative that has broad consequences in terms of satisfying the needs of customers and the organisation's other constituents.
2.7.3 IT tools help to facilitate project management. Project management tools help to analyse processes and define new processes.
They can also be used to define the introduction of process-oriented application software packages.
2.7.4 IS lets people work together more closely. Special software systems, such as e-mail, groupware, workflow-management and
teleconferencing, are elements of the pervasive role IS is taking.
2.7.5 IS helps to integrate businesses. The process view of businesses includes the integration of business processes within an
organisation and also among business partners. ERP systems are totally integrated and help to enforce the reengineering
process, by concentrating on the BPR implementation process.

2.8 Risks of BPR Projects

2.8.1 Radically improved business processes may satisfy customer requirements better than before and achieve drastic improvements
to the operational results of an organisation. However, the dramatic improvements do not come without risks and a high rate of
failure. The benefits of reengineering do not necessarily come in due time. That means that BPR projects must be carefully
monitored during the life cycle of the project.
2.8.2 At each step of the change process (design, implementation and operational/rollout) problems related to sponsorship, scope,
organisational culture, leadership, skills, human resources and management can arise. Examples of the types of problems are
summarised as follows.
2.8.3 Design risks include the following:
„ Sponsorship issues
- CEO not supportive
- Insufficient top management commitment
- Management skepticism
- Wrong executive leading the effort
- Wrong members on the design team
- Poor communication of importance
„ Scope issues
- Unrelated to strategic vision
- Scope too narrow or too ambitious
- Sacred cows protected
- Existing jobs protected
- Analysis paralysis
„ Skill issues
- Insufficient exploration of new ideas
- Absence of out-of-the-box thinking
- Closed to new ideas
- Design misconceptions
- Cultural change not calibrated to organisation
- Inadequate consideration of human resource issues
- Beyond the ability of IS department to support
„ Political issues
- Sabotage by managers losing power
- Sniping
- Uncontrolled rumors
- Fear of change
- Cultural resistance

2.8.4 Implementation risks include the following:

„ Leadership issues
- Insufficient attention, commitment or clout by top management
- Ownership struggle
- CEO/sponsor's political will wavers or falters
- Switch in CEO/sponsor
- Inadequate resources
- Failure to communicate compelling vision
- Failure of CEO to unify management behind effort
„ Technical issues
- Beyond the capability of IT to build
- Delayed software implementation
- Capability of packaged software insufficient
- Functional and design requirement problems
- Key issues not initially identified

Page 4 BPR Guideline

 - Complexity underestimated
- Unanticipated scope change
- Time consuming or costly development strategies
„ Transition issues
- Loss of key personnel from design phase
- Loss of momentum
- Staff burnout
„ Scope issues
- Slower than expected results
- Budget overruns
- Unrealistic time frames
- Narrowing of original scope
- Neglect of human resource issues
- Magnitude of effort overwhelming

2.8.5 Operational/roll out risks include the following:

„ Cultural/human resource issues
- Cultural resistance increases
- Dysfunctional behaviour does not diminish
- Lack of buy in leads to erosion of projected benefits
- Training insufficient or unsuccessful
- Outcomes not as promised or generally understood
„ Management issues
- Unsuccessful implementation of new management skills
- No provision for ongoing continuous improvement activities
- Ownership/turf/power issues not satisfactorily resolved
- Insufficient will to overcome problems encountered
- Poor communication
- Active or passive sabotage by employees and managers
„ Technical issues
- Support late and/or flawed
- Operational problems with systems/software bugs
- Systems do not meet user needs/expectations
- Inadequate testing
- Data integrity problems undermine confidence

3. AUDIT CHARTER

3.1 Modifications for BPR Projects

3.1.1 The audit charter of the IS audit function may need to be modified as a result of an organisation’s decision to implement BPR
projects. BPR considerations require the IS auditor’s scope of work or relationships with other audit functions (such as, financial
and operational) to be expanded and more closely integrated.
3.1.2 It is imperative that the organisation’s senior and system management fully understand and support the IS auditor’s role(s) as it
relates to BPR project. The IS Auditing Guideline G5 Audit Charter should be reviewed and considered within the context of the
BPR projects and related initiatives of the organisation.

4. INDEPENDENCE

4.1 IS Audit Roles in BPR Projects

4.1.1 If the IS auditor is to perform or be responsible for nonaudit roles associated with BPR projects, IS Auditing Guideline G17 Effect
of Nonaudit Role on the IS Auditor’s Independence should be reviewed and adhered to appropriately.
4.1.2 If the IS auditor is to have a nonaudit role in BPR project, the IS auditor should also review and appropriately adhere to ISACA’s
Standards of Information Systems Control Professionals.
4.1.3 The reason for this is because there is a substantial likelihood that the IS auditor's independence will be compromised. More
specifically the IS auditor should refuse the review of systems, procedures or processes that have been subjected to a BPR and in
which he/she was part of the BPR team.

5. COMPETENCE

5.1 Required Business Knowledge and Technical Skill

5.1.1 IS auditors can play a critical role in the reengineering of core business processes due to their knowledge of systems and controls,
even though they have to reengineer their skills and audit approach because much of what IS auditors were accustomed to find in
the processes is affected or disappears due to the radical changes of BPR.
5.1.2 In the auditing of a BPR project, the IS auditor is ordinarily a component of the audit team where he/she complements the skills of
other auditors in the financial, operational and regulatory areas with his/her skill in the IS areas. However, the IS auditor should
ensure that he/she has the necessary business knowledge to review the BPR project. The IS auditor also should provide
reasonable assurance he/she has access to the relevant technical skill and knowledge to carry out the review of the BPR project.

BPR Guideline Page 5

 6. PLANNING

6.1 Framework for Consideration by the IS Auditor When Reviewing a BPR Project
6.1.1 The initiate and diagnose phases are when the existing processes, the information and the IT systems currently in use are
analysed and compared with other systems via benchmarking. At this time, for each of the processes chosen for investigation, the
IS auditor can measure the relevant current performance variables and identify the performance gaps. As the use of information
and IT can be the levers for dramatic changes in the organisation processes, the IS auditor can provide useful contributions from
the early stages of the BPR process.
6.1.2 The redesign phase is when the:
„ New processes are redesigned
„ New information or new ways to use existing information are searched
„ Blueprint of the new business system is defined
„ Migration strategy is developed
„ Migration action plan is created

6.1.3 The IS auditor can review:

„ The to-be model of the new workflow, how the new information is to be shared across functional areas of the business, the
transformation of the IT systems, how new information and new technologies will be introduced, and how old information and
IT systems are discarded, how reliable will be the new control system,.

6.1.4 The evaluate phase is when the new processes and IS systems are operating. It is a specific task of the IS auditor to determine if
the BPR project has met its goals, the transition to the new structure is effective and reliable, and a total quality program has been
activated.

7. PERFORMANCE OF AUDIT WORK

7.1 Risk Management Assessment

7.1.1 As reengineering is inherently highly situational and creative—there is no right way to do it—and there are several BPR
procedures in the literature. An audit of a BPR project cannot be one of compliance to a methodology, but rather it is the
assessment of risk management and how bottom-line improvements in outcomes, which are important to customers and
stakeholders, are achieved.

8. REPORTING

8.1 Report Content

8.1.1 In BPR reviews, reporting should be performed progressively as and when risks and issues are identified. These reports should
be addressed to the appropriate management for necessary action. A final report listing all issues raised during the review can be
issued.
8.1.2 Depending on the type of review, the report should address aspects such as:
„ Appropriateness of the BPR approach model and methodology
„ Risks and issues, their causes and effects
„ Possible risk mitigation actions
„ Cost/benefit comparison and effect on the organisation’s environment

9. EFFECTIVE DATE
9.1 This guideline is effective for all information systems audits beginning on or after 1 July 2004. A full glossary of terms can be
found on the ISACA web site at www.isaca.org/glossary.
.
APPENDIX

Reference Literature
■ Carter, M.; R. Handfield; Identifying Sources of Cycle-time Reduction, Reengineering for Time-based Competition, Quorum Books,
1994
■ Hammer, M.; J. Champy; Reengineering the Corporation: A Manifesto for Business Revolution, Harper-Collins, USA, 1993
■ Harrington, H.J.; Business Process Improvement, McGraw-Hill, USA, 1991

BPR Tools and Techniques

A number of tools and techniques have been specifically developed to capture and present process knowledge, while others are already
existing tools and techniques considered useful in reengineering studies. Different views of the same process may all help to understand it in
some way, but ordinarily they do not enhance the necessary innovative thinking. Tools and techniques can be broadly classified into the
following categories:
■ Soft systems methods—These are qualitative/brainstorming techniques for formalising the thought process, and are often used in:
− Setting process/system goals
− Problem analysis, for example, to identify causes of process failure (such as, cause and effect diagram)
− Risk analysis

Page 6 BPR Guideline

■ Presentation tools—These are techniques for presentation of process views to understand and communicate the current process or the
proposed future process. Examples are:
− Role activity diagrams to view the dependency of individuals/teams/departments within the process
− Process flow diagrams to view the activity dependencies
− Functional decomposition models, useful for viewing information dependency
− Time-based process mapping to present decomposition of process lead time into value-added and nonvalue-added components
at various stages in the process
■ Analysis tools—These are tools that can be used to analyse process behaviour over time. Various tools exist with different levels of
modeling capability, such as PERT/CPM, Petri Nets and Discrete Event Simulation.

The IS auditor should be aware of the risk of an overemphasis on modeling the as-is process as that can become a substitute for actual
decisions.

COBIT Reference
Selection of the most relevant material in COBIT, applicable to the scope of the particular audit, is based on the choice of specific COBIT IT
processes and consideration of COBIT information criteria.

The procedure links to the following primary COBIT processes:

■ M1—Monitor the Processes
■ M2—Assess Internal Control Adequacy
■ DS1—Define and Manage Service Levels
■ DS10—Manage Problems and Incidents
■ AI6—Manage Changes
■ PO1—Define a Strategic IT Plan
■ PO9—Assess Risks
■ PO10—Manage Projects
The procedure links to the following COBIT processes:
■ PO4—Define the IT Organisation and Relationships
■ PO5—Manage the IT Investment
■ PO6—Communicate Management Aims and Direction
■ PO7—Manage Human Resources
■ PO11—Manage Quality
■ DS3—Manage Performance and Capacity
■ DS7—Educate and Train Users
■ DS13—Manage Operations
The information criteria most relevant to a BPR audit are:
■ Effectiveness
■ Efficiency
■ Compliance
■ Reliability of information

 Copyright 2004
Information Systems Audit and Control Association
3701 Algonquin Road, Suite 1010
Rolling Meadows, IL 60008 USA
Telephone: +1.847.253.1545
Fax: +1.847.253.1443
E-mail: standards@isaca.org
Web site: www.isaca.org

BPR Guideline Page 7