This action might not be possible to undo. Are you sure you want to continue?
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 (email@example.com), 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. 1.1 1.1.1 1.1.2 1.1.3 1.2 1.2.1 1.2.2
BACKGROUND Linkage to Standards 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." Guideline G17 Effect of Nonaudit Roles on the IS Auditor’s Independence provides guidance. Guideline G21 ERP Systems Review provides guidance. Linkage to COBIT 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." 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? 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. 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. 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. 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. Need for Guideline 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. 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. 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. BUSINESS PROCESS REENGINEERING PROJECTS Definition 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. 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. BPR Key Results 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.2.4 1.2.5 1.2.6 1.3 1.3.1
1.3.3 2. 2.1 2.1.1 2.1.2
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 2.3.1 2.3.2 BPR Principles and Activities 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. 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. 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. Sometimes a holistic view is the best approach. BPR Methodology Reengineering is inherently highly situational and creative. Basically, there are two distinct approaches to BPR that can be found in the literature. 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. 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. 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. 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). Six Basic Steps of Several BPR Methodologies 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. 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. 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. 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. 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. 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. BPR Tools 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.
2.3.4 2.4 2.4.1 2.4.2
2.5 2.5.1 2.5.2 2.5.3 2.5.4
2.5.5 2.5.6 2.6 2.6.1
BPR Guideline Page 3
2.6.2 2.7 2.7.1 2.7.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. IS Role in the BPR IS delivers tools and plays four distinct roles within BPR projects. 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. 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. 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. 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. Risks of BPR Projects 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. 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. 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 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
2.7.3 2.7.4 2.7.5
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 AUDIT CHARTER Modifications for BPR Projects 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. 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. INDEPENDENCE IS Audit Roles in BPR Projects 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. 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. 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. COMPETENCE Required Business Knowledge and Technical Skill 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. 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.
3. 3.1 3.1.1 3.1.2
4. 4.1 4.1.1 4.1.2 4.1.3
5. 5.1 5.1.1 5.1.2
BPR Guideline Page 5
6. 6.1 6.1.1
PLANNING Framework for Consideration by the IS Auditor When Reviewing a BPR Project 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. 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 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,. 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. PERFORMANCE OF AUDIT WORK Risk Management Assessment 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. REPORTING Report Content 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. 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 EFFECTIVE DATE 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.
7. 7.1 7.1.1
8. 8.1 8.1.1 8.1.2
. 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: firstname.lastname@example.org Web site: www.isaca.org
BPR Guideline Page 7
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.