Most organizations use an IT strategy committee or IT steering committee. An IT steering committee is used to convey the current business requirements from business executives to the IT executive. The name of the committee is not as important as the function that it performs; a committee may perform more than one function. An IT steering committee may possibly be the same committee used for the purpose of a business continuity steering committee, but with a slightly different charter (focus). What's important is that the job of steering operations to business requirements is occurring.

Steering committees should have a formal charter designating the participation of each member. This charter grants responsibility and authority in a concept similar to an audit charter. An absence of a steering committee charter would indicate a lack of formal controls—a condition warranting management oversight review.

The steering committee is also discussed in Chapter 5, "Life Cycle Management."

Figure 3.3. Organizational structure of a steering committee

The committee is managed by an executive chairperson. The CEO is expected to provide directional guidance in person or via a representative, such as the COO, to identify targeted sources of revenue. Each member of the committee is expected to participate in focus discussions concerning business issues. On occasion, the committee may invite trusted observers or presenters to the meeting to increase awareness of a particular area.

After the business objectives are identified, the next step is to determine the business objectives for IT to fulfill. The steering committee sticks to high-level objectives rather than dictating technical detail.

Let's look at the representation necessary on the steering committee:

The steering committee reviews ideas and opportunities to make recommendations. Those recommendations go to the board of directors for review. If the idea receives preliminary approval, resources are allocated for project planning. The steering committee executives perform a final review of comparing the total cost and benefit to determine whether the project is a "go" or "no-go."

If a go decision is reached, the organization specifies details, charters the project, allocates funds, commits resources, and moves the plan into execution. If the project is scheduled to be a repeating event, the project is assigned to program status. Otherwise, it is managed as a project with fixed time duration, and the assigned project team members will disband after project completion.

Figure 3.4 is a flowchart of the IT steering process.

Figure 3.4. The IT steering committee process

In strategic planning, plans generally run in a time frame of three to five years. A tactical plan is going to be carried out over six months to a year and it may go into two years. Daily plans are no more than steps in the tactical plan. When an organization projects three to five years, it is really developing a strategy. This strategy can be to run a streamlined low-cost airline operation like Southwest Airlines, offer the best market reach like eBay, provide competitive rate marketing like Progressive insurance, or use the shipping model of FedEx to assure your package is absolutely positively delivered overnight.

Table 3.1 compares strategic plans, long-term plans, and operational plans.

Now that we have discussed the definition of strategic planning, it is time to get specific about the content of the executive strategy.

To set forth a strategic goal without proper planning and meaningful definitions would be both negligent and reckless. One of the most powerful executive planning tools available is the balanced scorecard (BSC). The BSC is a strategic methodology designed for senior executives.

Originally, the balanced scorecard was designed in a university environment to be used by business executives for reporting metrics. A very smart person once said, "the product's actual use will be invented at the customer site," meaning you can build what you want, but the customer will determine how it's used to solve their problem. It turns out that the most successful executives are using the BSC to define internal cause-effect relationships of smaller plans that run their business, not just to report metrics as originally conceived.

The scorecard approach converts organizational objectives of customer perception, business processes, employee growth and learning, and financial goals into a series of defined actions. We typically call these actions either projects or programs, but the BSC doesn't care. The BSC refers to projects and programs as initiatives (what you are doing).

Three years ago, after a less-than-successful board meeting, I set a personal goal to learn how to apply the BSC tool. I searched all websites in the first 200 Google results and read every book available from Barnes & Noble. Plenty of people claimed knowledge of the BSC, yet consistently failed to demonstrate how the inner details actually worked. Frankly, none provided enough direction to make it work. I fell into the same trap as everyone else. It takes special training with firsthand experience to receive the benefits that this type of advanced planning tool offers. ISACA just wants you to know it exists. I teach my students in our seminars how to use it, exceeding the exam study requirement. So this section is my short brochure-level introduction on how it works. I use BSC constantly each week and stand behind all my statements with supporting evidence.

When properly implemented, the scorecard concept enforces better alignment by defining details of strategic business objectives. Overused terms such as world class and customer driven are broken down into low-level definitions that the staff can actually implement. Using the scorecard should eliminate activities of little or no strategic value.

The scorecard methodology is common outside the IT environment. Information technology can benefit from using the balanced scorecard if it is implemented by the CEO or CFO. To be effective, the scorecard must be driven from the top down.

Table 3.2 illustrates the four scorecard perspectives and matching emphasis area of the BSC methodology. For example, the finance perspective will place emphasis on cost control and company profits.

A smaller number of organizations are successful at using the balanced scorecard approach, while many fail. Upon investigation, several of the failing executives referred to BSC as old news. It did not take long to discover that these executives had a lack of BSC training, misunderstood the objective, and possessed little BSC experience. Let's investigate why this occurs.

The advantages and disadvantages of using the scorecard methodology are as follows:

The balanced scorecard can contain whatever you need to define. It is flexible in having three, four, or five perspectives depending on what your executives decide is needed. The typical approach of four perspectives is shown in Figure 3.5. Notice how the different initiatives are linked into a complete process.

Figure 3.5. Balanced scorecard with four perspectives

There are several secrets involved in making the scorecard generate true results. Using a BSC will most likely take beginners at least 20–30 failed attempts, which end in frustration, before it begins to show a glimmer of success. Keep trying; the benefits will far outweigh the effort. Each failed attempt is simply an indicator of an existing relationship problem or definition problem. Problems need to be fixed one by one before you can build an effective linkage. Often this includes retreating a few steps to adapt for changes as they are discovered. That's part of the magic in using BSC. The strategy becomes more defined with each pass, forcing each problem to be fixed before it can effectively function inside the overall strategy plan.

Every planning exercise brings more clarity as you roll the linkages forward and backward to fine-tune the details. It's like using algebra to solve a problem and then using calculus to prove you actually did solve the problem by returning to zero. Now the strategy works forward and backward, with excellent definitions exploding all the details into specific action items. Initiatives (projects or programs) are now selected, scoped, and funded based on which ones generate the highest return on investment (ROI).

What if your project or program doesn't generate revenue? Simply put, it would be linked with a function that is generating revenue and used to calculate the combined operating costs. For example, security costs in a bank are coupled with the profits the bank generates. The final ROI estimate is used to decide whether that area of the business is expanded or shut down. What if you make more money from brokering mortgages? You may switch from being a full-service bank into focusing on mortgages. The final goal is to find the highest-earning ROI and quit wasting resources on marginal or losing activities.

Executives at AMR operate American Airlines and Sabre reservations as two separate companies. One reporter asked which one they would sell if necessary. The response was that American Airlines' business need created Sabre, yet they would keep Sabre, selling the airline if that day ever came. Sabre's reservation system is a better ROI.

The balanced scorecard fundamentally changes how employees prioritize and report their work. Activities and projects are selected on the basis of the value created under established metrics. This also results in a change in how the employee is evaluated. It is essential that management and staff receive proper training prior to implementation. Just remember, without full buy-in at all levels, the balanced scorecard is likely to fail.

The IT balanced scorecard should be a subset of the organization's overall balanced scorecard. When properly implemented, the scorecard methodology supports the highest-level business objectives.

As a CISA, you need to understand how the balanced scorecard can be applied specifically to information technology. ISACA describes the scorecard by using three layers that incorporate the more common four perspectives (customer, business process, financial, and growth and learning). The three layers for IT scoring according to ISACA are as follows:

Executive management selects an IT strategy to fulfill their business objectives. The strategy should be approved from the top down. The strategy is then formalized into a policy and communicated throughout the organization. Figure 3.6 shows the executives involved at the strategy level (in policy making).

Figure 3.6. Executives involved at the IT strategy level

You should assume that the executives have already gone through the process of gathering requirements. Their strategy may be to insource or to outsource. However, one of their most important questions is to determine how the strategy will be funded. Each of the following methods of funding bears unique advantages and disadvantages:

Executive management has the responsibility of setting goals. Each goal should be supported with a defined set of objectives. A strategy should be in place to achieve those objectives. The next step is to specify a policy to communicate management's desires to the subordinates.

Every policy should be designed to define a high-level course of action. The purpose of the policy is to inform interested parties of a chosen solution. A well-designed policy is based on a statement by management of the policy's importance. The statement explains how this particular policy supports a business objective. The policy is signed by the most senior person available to prove authorization.

We discussed the role of policies, standards, and procedures in Chapter 1, "Secrets of a Successful IS Auditor." Table 3.3 should serve as a memory refresher concerning the role of policies, standards, and procedures.

Successful policies are issued from the top down to all subordinates. The policy may designate a department director to create a standard in support of the policy. The final procedures are generated from the workers at the bottom of the hierarchy. Common procedures are intended to be implemented from the bottom up. The procedure is a lower-level person's response in support of the executive's policy.

IT strategy plans must be created to aid the organization in the fulfillment of long- and short-term business objectives. Each IT plan should correlate to a specific organizational goal. The business goal may be to improve customer contact management, expand e-commerce services, or improve operating speed with better software integration. The supporting IT plan could define implementation and support for a new Customer Relationship Management (CRM) system. IT's role is that of a requirements facilitator and custodian. The true strategic value will be determined in the minds of the business executives. There should be a concern if IT's influence is overriding other non-IT business objectives. The IT strategy will be composed of plans for data, software applications, technology, personnel, and facilities.

Organizational Plan

The IT organizational structure needs to be designed to support the business strategy. Information technology is usually regarded as a function of internal administration. This would place IT under the head of internal controls (the CFO, VP of finance, or the comptroller). Figure 3.7 illustrates a typical IT organization. We will discuss the individual positions as we proceed through this chapter.

Tip

Figure 3.7 can serve as a roadmap if you're unsure about the authority of positions we discuss in this chapter.

Figure 3.7. Typical IT organizational structure

Knowing what to do is a challenge for all auditors. Discussions were occurring on this subject long ago in the old Electronic Data Processing (EDP) audit association, before it was renamed ISACA. One of the goals of every association is to add value by improving the performance of its members. ISACA has definitely delivered on this goal. The definitive framework for IS auditing is called the Control Objectives for Information and related Technology, also known as CObIT.

This framework contains a complete set of strategies, processes, and procedures necessary for executives to lead the IT organization. CObIT is now in its fourth edition. Within the supporting manuals, you will find the guidance provided in their audit toolkit invaluable. CObIT is protected under copyright, so it's a good idea not to lose your CISA certification by doing something stupid like having a bootleg copy.

The audit guideline section contains more than enough questions necessary for a first-class audit. It covers the entire spectrum from executive strategy down to device settings. BSC properly combined with CObIT would make a phenomenal audit practice.

Now let's get back to the auditing plan. We have discussed strategy, so the next step is to figure out the work location.

The next step is to identify sourcing locations. The sourcing decision may be based on the operating cost for particular geographic locations. Operating cost is a combined factor of facilities, labor, regulations, and available resources. Organizations may choose to perform functions onsite, in their facility. Alternatively, there may be an advantage to performing functions offsite, at other offices or with an outside vendor. This is a common practice for customer support, employee payroll, and manufacturing. Cheap labor may influence management's decision to move the location offshore, to another country.

Performing functions offshore introduces both opportunities and burdens. The opportunities include a potentially lower production cost. There is also an advantage for an organization to operate 24 hours a day in order to lower turnaround times. Consider the effect when the day shift identifies a problem and the night shift in another country fixes it before the day shift returns in the morning.

Disadvantages include the potential loss of control or the disclosure of proprietary intellectual property. In some countries, the culture, language, or level of education presents unique challenges.

Cultural examples of potential conflicts include India's caste system and Africa's ongoing tribal wars. Another example is the attitudes in some societies toward a woman in an authoritative role.

The executive staff is subject to review by the audit committee. As you recall, it is this committee's job to challenge the assumptions and assurances in the organization. The audit committee is expected to provide management oversight and allow executives the opportunity to discuss confidential issues about the business. An effective audit committee will advise individual executives with an opinion for possible solutions to internal problems.

Independent auditors are hired by the audit committee to provide an impartial (independent) opinion as to the status of internal controls. Audit committees are frequently the client of external audit engagements.

As an IS auditor, you need to find evidence of management governing IT and the enterprise. The composition and performance of the steering committee could be a powerful source of evidence. You may be able to review the plans and meeting minutes from the committee. The auditor's goal is to assess the performance of the CEO and executive management in developing and leading a successful strategy based on business objectives.

All levels of management are responsible for providing leadership. Good leaders generate better performance from individual employees. To manage is to create an unnatural result. If the same result would naturally occur by itself, then you are not managing it. The objective of management is to get a better result. Every organization needs to plan for how to collect continuous evidence of performance. The minimum requirements of good management include the following:

The auditor needs to review a variety of documents, including the organization's strategic plan, policies, IT plans, and operating procedures. These include plans for training, system mitigation, system certification, disaster recovery, continuity, and the inevitability of change. As an auditor, you will need input from people besides IT management to ensure alignment with the enterprise objectives.

Performance Review

Performance review refers to the identification of a target to be monitored, tracked, and assigned to a responsible party, and the resolution of any open issues.

Existing systems require a regular review to determine the ongoing level of compliance to internal controls and the next steps to take.

The Capability Maturity Model (CMM) is a method for evaluating and measuring the maturity of processes in organizations. A rating scale from 0 to 5 is used. A score of zero indicates that nothing is occurring. Level 1 maturity indicates that the initial activity was successful and may later progress up to level 5, when the activity is statistically controlled for continuous improvement. The CMM rating scale was developed by the Software Engineering Institute at Carnegie Mellon University and has been widely used for rating business process capabilities.

Note

The Capability Maturity Model is also discussed in Chapter 5.

Levels of the CMM are as follows:

Level 0 = Nothing yet

The level of zero is implied in the CMM but may not be noticed. This is important when evaluating process maturity. Missing processes and controls without evidence will be rated as zero. Many individuals assume that all controls are present when, in fact, some may be missing. A process or control must have occurred in order to reach a level of maturity (1–5).

Level 1 = Initial

Processes are unique and chaotic. The organization does not have a stable environment. Success is based on individual competencies and heroics. This level often produces products and services that work. However, output may exceed the available resources or be dependent on specific individuals. At level 1, people have the most freedom and flexibility to make their own decisions.

Level 2 = Repeatable

Processes are repeatable. The organization uses project management to track projects. The project status is communicated by using milestones with a defined work breakdown structure. The basic standards, processes, descriptions, and procedures are documented.

Level 3 = Defined

Processes are well documented and understood. Level 3 is more mature and better defined than level 2. Processes have objectives, measurements, improvement procedures, and standards. The results in level 3 are predictable by qualitative measure.

Level 4 = Managed

Management can use precise measurement criteria to control the processes and identify ways to adjust the results. Processes at level 4 are predictable by quantitative measure.

Level 5 = Optimized

This is the highest level, with continuous improvement of processes. Objectives for improvement are defined and continually revised to reflect business needs and objectives. Products at CMM level 5 have been so well defined that they are effectively converted into a commodity.

Level 5 is the ideal maturity for the maximum level of control in outsourcing. It allows the company to switch to using less-skilled people who are told what to do, pay less, and demand unquestionable authority. People have the least authority with the fewest decisions at level 5.

Note

CObIT version 4.1 uses the CMM approach to rate auditee performance by the maturity of their control environment.

Figure 3.9 shows the five maturity levels of the CMM in a lateral view.

Figure 3.9. Capability Maturity Model

Frankly, attaining higher levels in the maturity model increases the likelihood that internal controls are successful. A higher CMM grade indicates a definition of maturity with a higher degree of control.

Consider the typical hooks in an outsource contract. The buyer is hooked to it, and so the following questions should be asked:

• Did the client give away resources, intellectual-property knowledge, or procedures of value that will not be recoverable?

• Has the client given away highly qualified personnel who will no longer be in-house?

• What will a contract change cost, if desired?

• Can the contract be cancelled?

• If a decision is made to cancel, what will it take to get the replacement function online?

This should be enough information for the prospective CISA. Let's take a look at two other sources of governance models. The first is the U.S. National Institute of Standards and Technology.

In Chapter 1, we discussed a few basics of project management and the defined project management processes. Every organization should be following a well-defined project management methodology. Larger organizations will implement a Project Management Office (PMO). The PMO is composed of project managers for the organization. Their function is to manage the larger or more-critical projects.

As a CISA, you should recall that each project will have at least four distinct phases. Recall that the Project Management Institute defines five phases of project management: Initiating, Planning, Executing, Monitoring and Controlling, and Closing. However, PMI considers the process of getting a sponsor as the phase of project initiation. Most employees will never be involved in the Initiating phase. Therefore, ISACA wants the IS auditor to understand the four common phases of Planning, Executing (scheduling), Monitoring and Controlling, and Closing.

Now let's look at risk management in IT governance.

Risks occur at all levels. There are strategic risks, tactical risks, operational risks, and inherent risks. We have discussed these definitions in Chapters 1 and 2. Now let's look at one of the more common risk management formulas.

The first step in risk management is to calculate how much a single loss event would cost. This formula multiplies an asset value (expressed in dollars) by the percentage of loss for a particular event. For example, the percentage of loss of a stolen purse is likely to be 100 percent. In that example, the loss would be 100 percent of purse value. The loss due to data-entry errors may be equal to .007 percent of labor cost. This first formula is expressed as follows:

The single loss expectancy can be multiplied by the number of related events that are likely to occur for the year. The final result would be the estimated annual loss, as shown in the following formula:

Risk management should be pervasive in all areas of business, including the IT department. As you might recall, we covered risk management previously in Chapter 2. The choices are to avoid, mitigate, transfer, accept, or eliminate the risk, and the goal is to reduce the level of risk.

When developing a risk management program, the auditor wants to find evidence that the risk management function has been implemented with an established purpose—in other words, that someone has been assigned responsibility, and risk management is a formal ongoing process, not just a review by lawyers.

Risks can involve many areas of the business. Impacts can be direct or indirect, but in either case will damage the organization's position, capital, or future opportunities. Typical assets include the organization's customer list, general information (which could be information about marketing or development), data, files, hardware, and software. Assets could also include the facility, a particular document, or services rendered. The risks, or threats, could be terror acts, malicious fraud, executing the wrong procedure, theft, or failure of controls.

It's interesting that criminals do not look at vulnerabilities the same way as an upstanding individual. To a criminal mind, a window becomes an entry or exit point to a building with the aid of a brick.

Risk management operates at a variety of levels: Management at the strategic level focuses on whether going forward with a particular strategy over a period of years is a good idea. Management could be at a project level—is the project on track? Or it could be at a daily or hourly or by-the-minute operational level to ensure that personnel are doing what they are supposed to do. Frankly, most major disasters are caused by a domino effect of a tiny failure multiplying into multiple failures that become catastrophic.

Overall, situations of high risk—where high loss, high consequence, or high impact is possible—require a method to ensure that the problem receives adequate consideration and the appropriate level of effort to prevent an unfortunate outcome. It is extremely common for IT staff to execute poor change control when dealing with interruptions, failures, theft, fraud, or just general risk while under pressure.

IT governance is founded on the implementation of formal policies and standards. Each standard is supported by a matching procedure. The purpose of IT governance is to ensure that the risks are properly managed by mitigation, avoidance, or transfer. Let's review a short list of the policies required to address issues faced by IT governance:

IT governance is conjoined with requirements to properly manage people. Good management is founded on human resource management that is well defined, fair, and consistent. Let's take a look at a few of the HR-related policies that affect IT management:

These are just a few of the many policies and procedures necessary to manage human resources. The IS auditor should be concerned about activities that increase the organization's level of risk. This includes Human Resources activities.

All computer systems need to be managed through their entire life cycle. Each system will go through a series of phases starting with a feasibility study. Next, requirements are generated and followed by system design. Systems are tested for integrity, and their fitness of use is determined. The life cycle continues into system implementation. After successful implementation, the system can migrate into production use. Each year of production, the system should undergo a review. The annual post implementation review focuses on the system's present condition compared to the more current requirements. A system may be upgraded to the new requirements or retired. This is just a summary.

The CISA is interested in understanding how the organization manages each phase of this process. Evidence should be obtained to support the auditor's conclusions.

Information technology systems are so pervasive today that most organizations would cease to operate if their computers were unavailable. IT governance requires continuity planning for systems and data. Any disruption to operations could have far-reaching effects. Members of the media can be merciless in their quest to report an interesting story. The damage to an organization's reputation and brand can be fatal. ISACA wants every CISA to be aware of the need for continuity planning. We have expanded coverage of business continuity in Chapter 8, "Business Continuity and Disaster Recovery."

Adequate insurance is the minimum response for asset protection. This is a corrective administrative control. There are issues concerning insurance including the cost versus actual benefits received. Insurance does not replace lost market share, nor damage from unauthorized disclosure of confidential information. Acts of god, war, and terrorism are exempt from coverage in most insurance policies. Proper risk management reduces the organization's exposure. Risk reduction efforts, combined with insurance, are a good practice.

The CISA should be aware that there is a difference between real insurance and self-insurance.

Performance management serves to inform executives and stakeholders as to the progress of current activities. A fair and objective scoring system should be used. Scores may be based on a current service-level agreement. Another method is to use key performance indicators (KPIs), which tend to represent a historical average of monitored events. Unfortunately, a key performance indicator may indicate a failing score too late to implement a change. A perfect example of a KPI is the high-school report card. By the time the score is reported, the target child may not be eligible to graduate.

A process should exist to report the performance of IT budgets and noncompliant activities. Executive management should encourage the reporting of issues without punishing the messenger. Some effort is necessary to ensure the accurate and timely flow of information upward to the executives. False information can be very damaging.

Instead of just having a qualitative assessment of good or bad, or high, medium, or low, this should be an accounting exercise using a quantitative measure. It could be semi quantitative, using a ranking scale similar to scoring in a school: 70 to 79 is a C, 80 to 89 is a B, 90 to 100 represents an A, and then percentages such as A– or A+. This technique will convert a subjective decision into a more objective review. The Capability Maturity Model is very effective for communicating performance metrics.

Figure 3.10 shows a brief glimpse of the CMM used to report metrics.

Figure 3.10. Excerpt of CMM to report metrics

Times change. People change. Needs change. It is said that change is the only constant in life. BPR is used to improve process performance by removing, combining, or replacing steps that are no longer important.

BPR is concerned with reducing costs of the existing process while increasing performance. BPR includes three major areas for improvement:

BPR activities are performed as a unique project. The BPR project will design a new process or improve existing processes to replace the outdated, inefficient processes.

Every good methodology specifies a basic vision to illustrate its strategy, and recommends standards to follow and procedures to use. There is more than one version of the BPR methodology available for businesses. For clarity, we are going to focus on the views representative of ISACA and the CObIT framework of management guidelines. These are considered an excellent resource in the industry.

The key to governance is for management to take responsibility as the leader for implementing change, while establishing an adequate system of internal control. This would include implementing a culture of continuous monitoring to fuel continuous improvement. There is a saying: "You can't fix what you can't prove." It would be ridiculous to charge off on a whim under the guise of BPR without supporting evidence. Yet some companies do it all the time. BPR is often coupled with an enterprise resource planning (ERP) implementation. It would be a reckless misuse of company resources to switch to a particular ERP system just because it sounds cool, makes you look important, or aids your political agenda because it's the same system used at a former employer.

Consider for a moment that many of us are members of the general public. Stock-holding investors are on the outside of the business without full knowledge of the internal processes. We expect you as the auditor to investigate the supporting evidence and tell us whether management is making good, solid decisions based on intelligent facts. We hold you, the auditor, responsible for telling the truth. Please keep this fiduciary responsibility in mind when working on BPR-related projects.

It is a commonly held belief that there is a fine line between genius and insanity. The secret is to know which side of the line you're on. The latter is beyond the scope of this book, so let's focus on the genius side. True genius is grounded in a logical progression of intelligent thought.

History is loaded with the names of famous people regarded as the inspired genius in their fields. One characteristic is pervasive: Every great accomplishment was based on lessons learned from careful observations. These observations provided the facts necessary to fuel a progression of ideas into an intelligent hypothesis. The next step was to determine an objective method for testing the hypothesis. Useful metrics were created to help measure results. If the hypothesis failed, it was back to the drawing board to check their work and revise their ideas. Each test simulation yielded additional data to steer their thoughts.

Even Leonardo da Vinci's ideas were considered wild hallucinations until it was realized he had collected evidence indicating a crystal-clear thought process involving observation, hypothesis, and testing.

All BPR projects are intended to be strategic in nature. We are going to change the way the business operates. Service organizations and manufacturers need a mechanism to support their evolution. Continuous improvement is necessary to survive the challenges of increasing competition with the constant pressure of rising costs. Any change to a running business introduces new magnitudes of risk. Thin profit margins leave little tolerance for bad ideas or inadequate implementation. Proper reengineering will involve comprehensive changes affecting the design structure of management, people in support roles, information systems, and operating policies.

One of the auditor's duties is to impress upon management that controls are necessary. You may need to correct their view that controls appear to slow the process by explaining how controls are necessary to offset the risks that would be difficult to manage or to measure. The most damaging risks are those whose likelihood or effect you cannot calculate. Repeated answers of "I don't know" may indicate that you're on the wrong side of the genius-insanity line.

Let's instill a few guiding principles for your BPR activities. The purpose is to lend a structure to support the innovative thinking necessary for you to be successful. Reengineering projects are founded on specific situations and require creative ideas to generate the appropriate solution. Let's look at three possible approaches:

To be competent in BPR requires a working knowledge of auditing standards and the control frameworks such as CObIT. The competent auditor must possess the following skills before undertaking a BPR project:

The IS auditor can make an important contribution to their knowledge of internal controls and systems. Frequently the auditor will have to reengineer their own skills and audit approach to deal with the radical changes created by BPR. When auditing BPR, the CISA complements the other auditors on the BPR team who will be representing the special needs of finance and regulatory compliance.

ISACA expects every CISA to understand the operating techniques used in BPR projects. There are some conflicting viewpoints by different BPR experts; however, most of the suggested techniques include the following:

BPR projects should be undertaken only when the business value can be demonstrated. Three simple methods to demonstrate business value are to increase capability, to reduce operating cost, or to obtain compliance with a new requirement. The BPR project may commence after the steering committee has reviewed the ROI evidence, agreed with the scope, and granted formal approval to proceed.

ISACA cites six basic steps in their general approach to BPR. These six steps are simply an extension of Shewhart's Plan-Do-Check-Act model for managing projects:

These steps are easier to practice if you can relate them to something meaningful. Let's compare the BPR process steps with similar objectives in PMI project management and System Development Life Cycle (SDLC). An excellent way to get buy-in is to communicate by relating BPR steps to other methodologies already in use. Table 3.4 provides an illustration of the objectives in common.

Now we need to clarify the role of information systems in the BPR effort. Just how does IS help make this project successful?

ISACA has identified four distinct roles to be delivered by information systems within the BPR projects. IT is a key supplier of tools necessary for the business to be successful. The four roles of IS are as follows:

When looking at changes to business processes or when implementing these changes, the CISA should consider the use of the following tools to help define and document the processes being changed:

Now it's time to discuss the types of planning tools available for BPR projects.

High-quality data can be assembled into information that will create significant power. Several planning tools and techniques have been developed to capture the data. We need good tools to combine this data into meaningful information. Let's look at a few of the available options:

The right tools will harness the power necessary for your BPR project to be successful. Let's start with the manual process of setting goals through benchmarking. Later we will discuss the manual process of risk analysis in the BIA project.

Benchmarking is the process of comparing performance data (aka metrics). It can be used to evaluate business processes that are under consideration for reengineering. Performance data may be obtained by using a self-assessment or by auditing for compliance against a standard (reference standard). Evidence captured during the diagnostic phase is considered the key to identifying areas for performance improvement and documenting obstacles. ISACA offers the following general guidelines for performing benchmarks:

The benchmarking process is a valuable first step toward self-improvement. Figure 3.11 illustrates the benchmarking process.

Figure 3.11. Benchmarking process

Another excellent tool is the Business Impact Analysis (BIA). This would be more involved than benchmarking, yet a properly executed BIA will yield extremely valuable information.

The Business Impact Analysis (BIA) is a discovery process. Its purpose is to uncover the inner workings of any process. The BIA will answer questions about actual procedures, shortcuts, workarounds, and the types of failure that may occur. Armed with this knowledge, it is possible to assess priorities.

Part of the BIA is to determine what the process does, who performs the process, and what the output is. The BIA also determines the value of the process output to the organization. The BIA interviewer will ask key managers and key workers a series of questions to discover the low-level details of current processes. Some sample BIA questions that might be asked of key personnel in a BPR process review include the following:

Questions 17 and 21 provide key information for determining the true value of the process. Determining how much revenue the process creates or supports helps define its true value to the enterprise. Another measurement for value is to determine how long the process will remain in use.

For example, an organization can afford to spend $50,000 to reengineer a shipping process if they intend to use the process in perpetuity. The cost savings or cost avoidance saved each year will be used to pay for this effort. Processes expected to end within one year will need to be carefully evaluated to determine whether the payback is worth the effort. Practical advice suggests that processes selected for reengineering should have a lifetime in excess of one year, or be nonworking processes, to provide enough return value for the time and effort expended to reengineer them.

Proper planning of the process reengineering project requires documentation of the process to be modified. If the process has been correctly documented with all outputs and all interrelated activities, the chances of having "leftover parts" is minimized.

Radical improvements are not possible without increased risk. BPR projects are known to have a high rate of failure. Risks associated with changing an existing process must be identified. The ISACA Audit Standards, Guidelines, and Procedures identify several risk areas to consider when planning a BPR project. The risks can be broken down into three broad areas of design risks, implementation risks, and operational risks:

BPR projects require the use all the principles found in project management. It is advisable to consider project management as the framework for your BPR project. Many of the PMI processes, mentioned in Chapter 1 will be utilized to manage the project inputs, tools (techniques), and outputs necessary for the project to be successful. By following a recognized standard, the project manager can prevent most of the errors and common omissions inherent in almost any project.

Let's discuss some practical ground rules for BPR projects:

The following points illustrate how each of these ground rules applies to planning a BPR project.

The BPR selection process looks for areas with the greatest return on investment. The needs of each organization are unique. Executive governance dictates that the executives must define unique selection criteria and a selection process. Each process under consideration for reengineering must be evaluated and generally fits into one of the following categories:

In addition to these categories, the overall value needs to be considered in the equation. Is there a reasonable ROI for reengineering each process under consideration? Using a report in the format of Table 3.5 is helpful for organizing the discussion of investment, return, and priority.

Let's summarize each of these categories with a little more detail:

Without excellent leadership, the BPR project can become a convoluted mess. Even the simplest of objectives may wander aimlessly into failure. We want to take a few minutes to diagnose some of the more common BPR problems you may encounter as an auditor:

Tactical management involves the departmental director and manager. Tactical performance reporting should occur during weekly and monthly status meetings with senior-level executives. Tactical performance is frequently included during a regular audit.

As an IS auditor, you will be interested in learning the scope and extent of project management methodologies in use. Your interest will include gaining an understanding of the management tools in use and application of management controls. Tactical management should be using a change control process that exercises advance planning, risk management, and due diligence. The auditor should seek materially relevant evidence demonstrating management's efforts in support of the strategic objectives. The auditor's opinion should include a determination of the effective level of IT integration with various stages of project management. Is tactical management well integrated with measurable performance?

Every organization faces the challenges of sustaining operations. You will investigate whether the IT staff has the capability to sustain current operations. Three areas of interest are immediately identifiable. The auditor should seek evidence to discover whether the following three sustaining factors are met:

It would be practically impossible to sustain regular operations without documented procedures executed by an adequate number of well-trained IT staff members. The staff members must be able to interact and communicate effectively inside the IT organization and with the business organization. To ensure these objectives, each member of the IT team will need to have specified roles and responsibilities.

Performance of all operations should be tracked and reported by using metrics developed for the user's needs. These metrics should be based on best practices of NIST, COSO, ISACA's CObIT, and other industry standards. It is the responsibility of tactical management to develop the metrics. Operations management is required to report the detail necessary to generate a score.

Change control is an organized process for making sure that the best possible decision is reached. The reality is that any change introduces new variables. A person can execute a minor change that does what it intended, but then also has unintended consequences such as disabling or invalidating a previous control setting or a processing method. So change control must be a methodical process.

The change process should be evidenced by supporting policies and procedures. One employer, for example, had a policy that changes would occur only on Tuesdays and Thursdays in the evening. Users were required to provide their work-acceptance test procedures along with a competent user from their department. The user would run their own tests to prove whether the evening change had an impact. Positive impacts were desired. Negative impacts signaled the need to rerun the intended change procedure or restore the system to its earlier condition. Management allowed changes over the weekend if the requirement was so broad as to exceed an 8-hour window. Their preference was to avoid scheduling changes that would result in the next workday being on Monday. Problems occurring on Monday tend to set a negative tone for the entire week.

Internal auditors should be involved in change control meetings. The visibility and experience of the internal auditor present a valuable opportunity for the client. An internal audit should review requested changes to ensure that each change complies with the best practices of change management. You can bet that the staff will become more alert when they realize that the internal auditors are watching.

The auditor will need to evaluate whether the organization has provided effective daily support in accordance with the IS strategy. What is IT expected to deliver? Taking that into consideration, what are the issues considering fulfillment and capacity to supply this need? There should be a systematic decomposition of how each business objective is translated down into specific needs, which are fulfilled by specific tasks. If there is no stated requirement in a business objective, there should be no specific need, only a request. The IT alignment concept is to dedicate all efforts toward bona fide goals identified in the business strategy, not requests.

The auditor's job is to ensure that proper controls are in place and are appropriate to the unique risks of each source and location.