bpr review

8/14/2019 Bpr Review

1/7

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 ISACAprofessional contribution to the audit community. The framework for the IS Auditing Standards provides multiple levels of guidance.

Standardsdefine 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 professions 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 achieveimplementation of the standards, use professional judgment in their application and be prepared to justify any departure. The objective of theIS 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 provideinformation on how to meet the standards when performing IS auditing work, but do not set requirements. The objective of the IS AuditingProcedures 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, asdefined in the COBIT Framework. COBIT is intended for use by business and IT management as well as IS auditors; therefore, its usageenables the understanding of business objectives, and communication of best practices and recommendations, to be made around acommonly understood and well-respected standard reference. COBIT includes:

Control ObjectivesHigh-level and detailed generic statements of minimum good control

Control PracticesPractical rationales and guidance on how to implement the control objectives

Audit GuidelinesGuidance for each control area on how to obtain an understanding, evaluate each control, assess compliance andsubstantiate the risk of controls not being met

Management GuidelinesGuidance on how to assess and improve IT process performance, using maturity models, metrics and criticalsuccess 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 professionalresponsibilities set out in the ISACA Code of Professional Ethics for IS auditors. ISACA makes no claim that use of this product will assure asuccessful outcome. The publication should not be considered inclusive of any proper procedures and tests or exclusive of other proceduresand tests that are reasonably directed to obtaining the same results. In determining the propriety of any specific procedure or test, thecontrols professional should apply his/her own professional judgment to the specific control circumstances presented by the particularsystems 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 StandardsBoard also seeks out those with a special expertise or interest in the topic under consideration for consultation where necessary. TheStandards Board has an ongoing development programme and welcomes the input of ISACA members and other interested parties toidentify emerging issues requiring new standards. Any suggestions should be e-mailed ([email protected]), faxed (+1.847. 253.1443) ormailed (address at the end of document) to ISACA International Headquarters, for the attention of the director of research standards andacademic relations.

This material was issued on 1 April 2004.

Information Systems Audit And Control Association 2003-2004 STANDARDS BOARDChair, Claudio Cilli, Ph.D. CISA, CISM, CIA, CISSP Value Partners, Italy

Svein Aldal Scandinavian Business Security AS, NorwayJohn W. Beveridge, CISA, CFE, CGFM, CQA Commonwealth of Massachusetts, USA

Sergio Fleginsky, CISA PricewaterhouseCoopers, UruguayChristina Ledesma, CISA, CISM Citibank NA Sucursal, Uruguay

Andrew J. MacLeod, CISA, FCPA, MACS, PCP, CIA Brisbane City Council, AustraliaRavi Muthukrishnan, CISA, CISM, FCA, ISCA NextLinx India Private Ltd., India

Peter Niblett, CISA, CA, MIIA, FCPA WHK Day Neilson, AustraliaJohn G. Ott, CISA, CPA Aetna Inc., USA

IS AUDITING GUIDELINEBUSINESS PROCESS REENGINEERING (BPR)


2/7

Page 2 BPR Guideline

1. BACKGROUND1.1 Linkage to Standards1.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 analysisand interpretation of this evidence."

1.1.2 Guideline G17 Effect of Nonaudit Roles on the IS Auditors Independence provides guidance.1.1.3 Guideline G21 ERP Systems Review provides guidance.1.2 Linkage to COBIT1.2.1 COBITFrameworkstates, "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-assessmentspecifically focused on: Performance measurementHow well is the IT function supporting business requirements? IT control profilingWhat IT processes are important? What are the critical success factors for control? AwarenessWhat are the risks of not achieving the objectives? BenchmarkingWhat 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 goalindicators identify and measure outcomes of IT processes, and the key performance indicators assess how well the processes areperforming by measuring the enablers of the process. Maturity models and maturity attributes provide for capability assessmentsand benchmarking, helping management to measure control capability and to identify control gaps and strategies forimprovement.

1.2.4 Management Guidelines can be used to support self-assessment workshops, and they also can be used to support theimplementation 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 ITprocesses and consideration of COBITs information criteria.

1.2.6 ACOBIT reference is located in the appendix of this document for the specific objectives or processes of COBIT that should beconsidered when reviewing the area addressed by this guidance.

1.3 Need for Guideline1.3.1 Manufacturing and service organisations are taking an increasing interest inbusiness process reengineering (BPR) to support

their evolution in a dynamic and rapidly changing business environment. BPR offers an invaluable opportunity to achieve a realbreakthrough in business performance, but it also introduces risks, for example, in the case of wrong reengineering choices or ofinadequate 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 astrong 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 shouldbe cognisant and espouse to management that controls, though they appear in nature to slow the process down, are a necessityto 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 keytasks and risks associated with BPR projects with special attention to the IS aspects.

2. BUSINESS PROCESS REENGINEERING PROJECTS2.1 Definition2.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 dramaticimprovements in critical, contemporary measures of performance, such as cost, quality, service and speed.

1

2.1.2 BPR aims to improve business processes by substantially revising their structure and by dramatically changing the way in whichthe processes are managed and implemented. This ordinarily produces a great effect on the people involved and the workingpractices and supporting technologies, particularly information technologies.

2.2 BPR Key Results2.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

1Hammer and Champy, Reengineering the Corporation, 1993


3/7

BPR Guideline Page 3

Redefined roles for clients and customers providing them with more direct and active participation in the enterprisesbusiness processes

2.3 BPR Principles and Activities2.3.1 PPrinciples 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 includeselimination of nonvalue added activities), 2) standardisation, 3) integration, 4) parallelism, 5) variance control, 6) resourceallocation, 7) automation. They indicate the BPR process should tackle steps 1 to 7 in a strict sequence. It would, for example, bewrong to attempt automating a process with an IT application without first considering its simplification; not only couldsimplification make automation redundant but the full benefits of automation may not be realised either. However, there is adanger in restricting the thinking process to a strict sequence. For example, integration of activities requiring different resourcesinto 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 Methodology2.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 teamshould focus on determining how the strategic objectives of the organisation can be met without letting its thinking be constrainedby the existing process. The emphasis is on the to-be process, and is consistent with the step-change philosophy that the authorspresented.

2.4.3 The more incremental change methodology outlined by Harrington is a bottom-up approach which advocates modeling theexisting process to gain understanding of it, and then streamlining it appropriately to meet the strategic objectives. The focus is onchanging 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 isstill a need to understand the current functionality and to define carefully the transition path from the current to the preferred futureprocess. With a bottom-up methodology, BPR teams can spend too much time on detailing the current process and loseinnovative thinking. A mixed approach would encourage the team to consider high-level changes without being cluttered by thedetails 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 onimproving subprocesses, which may only require relatively small changes (perhaps to remove some bottlenecks).

2.5 Six Basic Steps of Several BPR Methodologies2.5.1 EnvisionThis stage typically involves a BPR project champion engendering the support of top management. A task force,

including senior executives and individuals knowledgeable about a firms processes, is authorised to target a business process forimprovement based on a review of business strategy and IT opportunities in the hope of improving the firm's overall performance.

2.5.2 InitiateThis 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 viabenchmarking, identifying external customer needs and cost-benefit analysis.

2.5.3 DiagnoseThis stage is classified as the documentation of the existing process and its subprocesses in terms of processattributes, such as activities, resources, communication, roles, IS and cost. In identifying process requirements and assigningcustomers value, root causes for problems surface and nonvalue-adding activities are identified.

2.5.4 RedesignIn the redesign stage, a new process design is developed. This is accomplished by devising process designalternatives 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 ofnew information systems to support the new process is completed.

2.5.5 ReconstructThis stage relies heavily on change management techniques to provide reasonable assurance of a smoothmigration to new process responsibilities and human resource roles. During this stage, the IT platform and systems areimplemented and the users go through training and transition.

2.5.6 EvaluateThe last stage of a BPR methodology requires monitoring of the new process to determine if i t met its goals and ofteninvolves linkage to a total quality program.

2.6 BPR Tools2.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 typicalBPRtool supports its modeling, analysis and evaluation, and the simulationof its probable behaviour.


4/7


2.6.2 As the diagnostic phase (2.5.3) is considered the key for the identification of performance improvement opportunities andobstacles, 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 BPR2.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 longbefore 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 andteleconferencing, 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 anorganisation and also among business partners. ERP systems are totally integrated and help to enforce the reengineeringprocess, by concentrating on the BPR implementation process.

2.8 Risks of BPR Projects2.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 offailure. The benefits of reengineering do not necessarily come in due time. That means that BPR projects must be carefullymonitored 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 aresummarised 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


5/7


- 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 CHARTER3.1 Modifications for BPR Projects3.1.1 The audit charter of the IS audit function may need to be modified as a result of an organisations decision to implement BPR

projects. BPR considerations require the IS auditors 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 organisations senior and system management fully understand and support the IS auditors role(s) as itrelates to BPR project. The IS Auditing Guideline G5 Audit Charter should be reviewed and considered within the context of theBPR projects and related initiatives of the organisation.

4. INDEPENDENCE4.1 IS Audit Roles in BPR Projects4.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 Auditors 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 ISACAsStandards 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. Morespecifically the IS auditor should refuse the review of systems, procedures or processes that have been subjected to a BPR and inwhich he/she was part of the BPR team.

5. COMPETENCE5.1 Required Business Knowledge and Technical Skill5.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 inthe 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 ofother auditors in the financial, operational and regulatory areas with his/her skill in the IS areas. However, the IS auditor shouldensure that he/she has the necessary business knowledge to review the BPR project. The IS auditor also should providereasonable assurance he/she has access to the relevant technical skill and knowledge to carry out the review of the BPR project.


6/7


6. PLANNING6.1 Framework for Consideration by the IS Auditor When Reviewing a BPR Project6.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, theIS auditor can measure the relevant current performance variables and identify the performance gaps. As the use of informationand IT can be the levers for dramatic changes in the organisation processes, the IS auditor can provide useful contributions fromthe 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 andIT 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 ifthe BPR project has met its goals, the transition to the new structure is effective and reliable, and a total quality program has beenactivated.

7. PERFORMANCE OF AUDIT WORK7.1 Risk Management Assessment7.1.1 As reengineering is inherently highly situational and creativethere is no right way to do itand 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 theassessment of risk management and how bottom-line improvements in outcomes, which are important to customers andstakeholders, are achieved.

8. REPORTING8.1 Report Content8.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 beissued.

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 organisations environment

9. EFFECTIVE DATE9.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..

APPENDIXReference 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 TechniquesA number of tools and techniques have been specifically developed to capture and present process knowledge, while others are alreadyexisting tools and techniques considered useful in reengineering studies. Different views of the same process may all help to understand it insome way, but ordinarily they do not enhance the necessary innovative thinking. Tools and techniques can be broadly classified into thefollowing categories:

Soft systems methodsThese 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


7/7


Presentation toolsThese are techniques for presentation of process views to understand and communicate the current process or theproposed 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 componentsat various stages in the process

Analysis toolsThese 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 actualdecisions.

COBIT ReferenceSelection of the most relevant material in COBIT, applicable to the scope of the particular audit, is based on the choice of specific COBIT ITprocesses and consideration of COBIT information criteria.

The procedure links to the following primary COBIT processes:

M1Monitor the Processes M2Assess Internal Control Adequacy DS1Define and Manage Service Levels DS10Manage Problems and Incidents AI6Manage Changes

PO1Define a Strategic IT Plan PO9Assess Risks PO10Manage Projects

The procedure links to the following COBIT processes:

PO4Define the IT Organisation and Relationships PO5Manage the IT Investment PO6Communicate Management Aims and Direction PO7Manage Human Resources PO11Manage Quality DS3Manage Performance and Capacity DS7Educate and Train Users DS13Manage Operations

The information criteria most relevant to a BPR audit are:

Effectiveness Efficiency Compliance Reliability of information

Copyright 2004Information Systems Audit and Control Association3701 Algonquin Road, Suite 1010Rolling Meadows, IL 60008 USATelephone: +1.847.253.1545Fax: +1.847.253.1443E-mail: [email protected] site: www.isaca.org

bpr review

Documents