IS Auditing Guidelines G1 Using the Work of Other Experts
APPENDIX COBIT Reference
2. BUSINESS PROCESS REENGINEERING PROJECTS 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 improvements 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 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 profitability1
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
Redefined roles for clients and customers providing them with more direct and active participation in the enterprise’sbusiness processes
2.3 BPR Principles and Activities
2
2..33..11 Principles help with the innovative thinking necessary to change the process structure. The principles are mainly of value in whatP 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.
G26 Business Process Reengineering (BPR) Project Reviews cont.
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.
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
- 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.
G26 Business Process Reengineering (BPR) Project Reviews cont.
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.
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, and new information or new ways to use existing information are searched, the blueprint of the new business system is defined, the migration strategy is developed and the migration action plan is created. 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, can all be reviewed by the IS auditor.
6.1.3 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