• Tidak ada hasil yang ditemukan

Risk Events—Qualitative Impact Analysis

Dalam dokumen Managing Risk in Organizations (Halaman 92-107)

W

ith risk identification, we go through a system-atic process of surfacing risk issues that can affect operations. As a consequence of this effort, we develop a good idea of things we should look out for when we do our jobs. Of course, not all risk events that we identify are equally significant. Those that we believe are highly significant are categorized as red zone risks. They require special at-tention. Those that are moderately significant are categorized as yel-low zone risks, indicating the need for caution, and those that are insignificant are categorized as green zone risks.

Once risk events have been identified and classified, we turn our attention to answering the question: What are the consequences of the occurrence of the target risk events, particularly the red zone events?

For example, if they arise, will this lead to major increases in expenses and decreases in revenue? (If so, by what amounts?) Will our clients face physical danger? (If so, what kinds of dangers?) Will we encounter delays in rolling out new products? (If so, how long will the delays be?) The attempt to assay the consequences of the occurrence of risk events is called risk impact analysis. As a matter of convenience, we split risk impact analysis into two parts: qualitative analysis and

quan-titative analysis. With qualitative analysis, we attempt to examine the impacts of risk events primarily through the application of a logical reasoning process. For example, if we think Event A will happen, we speculate that it will lead to Consequence A. Consequence A, in turn, may give rise to Event B, which will result in Consequence B. And so on. Effective qualitative impact analysis is heavily dependent on ex-perience, good logic, and good judgment. This chapter addresses qual-itative risk impact analysis.

With quantitative analysis, we try to measure consequences nu-merically. For example, if a grinding machine breaks down on the fac-tory floor, how much production will be lost? What is the dollar value of the losses? How long will it take before we resume production at normal levels? Answers to these types of questions provide insights to develop risk response strategies (see Chapter Eight). Let’s say our quantitative analysis reveals that downtime of the grinding machine costs our company $30,000 a year in lost revenue. Let’s say further that the cost of a new grinding machine is $50,000. The machine will likely pay for itself in less than two years. This information may lead us to conclude that we should purchase a backup grinding machine so that we don’t suffer production losses. Quantitative risk impact analysis is handled in the next chapter.

Every now and then, people get caught up in a debate on which is better: qualitative or quantitative impact analysis. This is a fruitless debate. Both approaches are important, and both should be carried out. The two approaches address different things. The qualitative ap-proach recognizes that experience coupled with hunches and good judgment enable people to develop insights that they cannot develop if they are constrained by the requirement that they work only with measurable phenomena. This is particularly true with a range of sit-uations, including first-of-a-kind experiences, circumstances where politics reign, and situations where outcomes are determined through negotiations.

When you are able to assess impacts quantitatively, why not do so?

Consider the situation where you are engaged in an impact analysis that addresses the following question: What are the financial conse-quences of a three-day interruption of business caused by a break-down of equipment at the plant? Clearly, “A three-day interruption of business will lead to a $15,000 loss of revenue” is a far more informa-tive response than “A three-day interruption of business will lead to a fairly serious financial loss.” In general, an impact analysis based on

valid and reliable quantitative assessments is more valuable than a cor-responding impact analysis based on unsupported speculation.

In this chapter, we examine qualitative impact analysis and in the pro-cess investigate a number of tools that help us to engage in such analy-ses: scenario building, the likelihood-impact matrix, attribute analysis, and Delphi forecasting.

SCENARIO BUILDING

With qualitative scenario building, we bring together a group of informed people and ask them to apply their knowledge and imagi-nations to describe the state of affairs that will be achieved as a con-sequence of an action. While this statement sounds a bit foreboding, we should recognize that we engage in this type of activity all the time.

To see this, consider the following dialogue:

GEORGE:If we leave the house at 7:30 A.M. and encounter no traffic, we can be at Sally’s place by noon.

DOROTHY:That’s right. But if there is traffic, it will delay us by at least a half-hour. We don’t want to be late. So perhaps we should leave here at 7:00 A.M.

In this brief interchange, George and Dorothy create two simple scenarios: a good-case and bad-case scenario. Both scenarios are built on George and Dorothy’s experience. Both entail the application of logical reasoning. By creating the two scenarios, George and Dorothy are even able to develop alternative courses of action. The conserva-tive one would have them leave home at 7:00 A.M. to factor in the pos-sibility of a half-hour traffic-induced delay in their journey. The optimistic one would have them leave home at 7:30 A.M.

George and Dorothy’s scenario-building experience captures on a small scale the essence of what midsized and large-scale scenario-building exercises encounter. Big or little, scenario-scenario-building exercises are adventures in storytelling. The trick is to tell a story that will ac-curately reflect how things actually play out in the real world.

There are many ways that qualitative scenarios can be developed.

We examine two approaches here: extrapolative and normative. The starting point for the extrapolative approach is recent history and where things stand now. Given this information, a future is built step by step, projecting forward from today. With the normative approach,

the starting point of the scenario-building exercise is some imagined future state of affairs. Then stepping backward from the future, we de-velop a scenario in reverse order that gets us back to today.

Extrapolative Scenario Building

Extrapolative scenario building will be illustrated with a real-world example:

The senior management of Gamma Enterprises has decided that a major source of revenue growth for its line of garden tools is sales of the tools overseas. In attempts to identify risks and opportunities of ex-panding its operations abroad, one important source of risk that stands out is Gamma’s inexperience with local market conditions in other countries. Although Gamma has great garden tools, it is obvious that the tools will not sell themselves. They must be marketed effectively.

Gamma’s initial inclination is to adopt the marketing strategy it suc-cessfully employed in the United States and Canada: establish mar-keting/sales offices in a number of regions staffed by local people who know the markets well. Thus, in reviewing market expansion strate-gies overseas, Gamma’s senior managers feel that Gamma should es-tablish local marketing/sales offices in the target countries where Gamma intends to introduce its products.

The senior managers ask the head of their marketing/sales depart-ment to examine the consequences of setting up marketing/sales offices overseas. She puts together a cross-functional group of experi-enced managers from the marketing/sales department (Sally), legal de-partment (Debby), human resource management dede-partment (Tom), finance department (Dick), and operations department (Harry). To-gether, these five people explore alternative scenarios of how things will play out if Gamma establishes marketing/sales offices overseas.

Following is a portion of the dialogue they engage in:

SALLY[marketing/sales]: I’m a little nervous about assuming we can follow our North American expansion strategy overseas. I doubt that what has worked in Phoenix will automatically work in Beijing.

DICK[finance]: I agree. Let’s see what would happen if we adopt our North American model in its entirety.

SALLY: Okay, let me start. Let’s say we’re in Beijing and want to set up a marketing/sales office there. What do we need to do?

HARRY[operations]: That’s just the problem. We don’t know any-thing about doing business in China in general and Beijing in particular.

SALLY: So we need to contact a local consultant who can guide us through the intricacies of local conditions.

DEBBY[legal): We need to be prepared for the fact that from the be-ginning, we will have a host of legal hurdles to contend with. I’m no expert about business law in China, but I know that we need to get a rash of approvals before we can begin operations.

SALLY: Good point, Debby. So let’s say we’ve figured out the legal issues. What next?

TOM[human resources]: Obviously, we have to contend with human resource issues. For example, we will need to hire local staff.

And one condition we must insist on is that they be bilingual, speak-ing both English and Mandarin.

DICK: How do you hire professionals in Beijing? Do they have head-hunters there?

SALLY: Who knows? Let’s assume we can do the job. Now what?

TOM: I’m not a marketing guy, but it seems obvious to me that we will have to develop a marketing strategy that addresses local condi-tions in Beijing. You know, a strategy that focuses on marketing’s 4Ps.

HARRY: That raises an interesting issue. Are we sure that our gar-dening tools are usable in Beijing? Do they even have gardens there?

As Sally, Debby, Tom, Dick, and Harry continue their qualitative scenario-building exercise, it becomes obvious that the establishment of a local marketing/sales office in Beijing is filled with consequences that Gamma is not able to deal with given its total ignorance of local conditions in Beijing. Through the scenario-building exercise, a plethora of legal, marketing and sales, operational, and cultural con-sequences arise. When Gamma senior managers receive a write-up of the results of the scenario-building effort, they realize that copying their North American expansion model is too dangerous. Ultimately, they decide to launch operations overseas with a local partner. (Es-tablishing local partnerships is fraught with risk as well, but we won’t cover that topic here.)

A strength of extrapolative scenario building is that it forces peo-ple to work through the consequences of their proposed actions step by step. It is one thing to say, “Let’s set up marketing/sales offices over-seas; they have served us well here in North America,” and another to think through the impacts of such an action. The very process of building the scenario surfaces a range of issues that need to be ad-dressed and may even suggest strategies for handling them.

For extrapolative scenario building to work, it is important that the right group of people participate in the exercise. They need to be ex-perienced and knowledgeable about the enterprise’s business opera-tions. They should also have a good understanding of developments in their industry. To make sure that the group has the knowledge needed to build workable scenarios, subject matter experts might be invited to participate in the scenario-building exercise. If the wrong people are working on developing the scenario, then the exercise is a waste of time or, worse, misleading.

Normative Scenario Building

The process of conducting a normative scenario-building exercise will be illustrated with an example that actually transpired as reported here. The names of the principal players have been changed for pur-poses of anonymity:

Epsilon Enterprises is an investment banker whose largest client is Kappa Capital, a substantial lending institution. Epsilon and Kappa often work together to structure merger and acquisition deals. Kappa has re-cently informed Epsilon that it would like Epsilon to be its principal partner in arranging mergers and acquisitions. In order to move to-ward this end, it needs Epsilon’s information technology department to develop a software system that will allow Epsilon and Kappa to ex-change financial data electronically, with no manual intervention. Ep-silon creates Project Abacus to address this matter exclusively. The Abacus team prepares a project proposal that it plans to submit to Kappa Capital in one week, on September 15. In the section of the pro-posal document titled “Delivery Date,” delivery of the solution is promised for November 30. The logic for this date is that the amount of programming necessary to deliver the solution would consume the efforts of three full-time analysts working two months.

Before the proposal can be submitted to Kappa, it must undergo a standard risk review to make sure that the proposed effort makes good

business sense and the promises it contains can be achieved. The risk assessment group (RAG) that examines the proposal has a tough time believing that a deliverable of this complexity and importance can be delivered by November 30, so they request the Abacus team members to work with them in conducting a normative scenario-building ex-ercise to test whether the project can be accomplished so quickly. One morning is set aside to carry out this exercise.

The future state of affairs that is used to launch the normative scenario-building effort is: “A fully developed and tested data inter-change system will be delivered to Kappa Capital on or before No-vember 30 that will enable Epsilon and Kappa to exchange financial data electronically, with no human intervention.”

This is how the conversation goes:

RAG TEAM: For this delivery date to be achieved, what efforts need to be completed on Project Abacus two weeks before the final solu-tion is delivered—roughly November 15?

ABACUS TEAM: The final tests of the system should be nearing completion by November 15.

RAG TEAM: If that is the case, when does final testing need to begin?

ABACUS TEAM: Two to three weeks before the tests are completed—

roughly October 24.

RAG TEAM: For the final tests to begin on October 24, what devel-opment work needs to be completed on the system?

ABACUS TEAM: The system’s five principal modules need to be coded.

RAG TEAM: And when can coding begin?

ABACUS TEAM: Roughly on September 30, about four or five weeks before the final tests begin.

RAG TEAM: And before coding can begin, what must be done?

ABACUS TEAM: The system must be designed.

RAG TEAM: And how long will the design effort take?

ABACUS TEAM: Probably three to four weeks. And by the way, in making our estimate for delivering the solution, we forgot to take into account that we need to work with Kappa’s IT department and

lending specialists to provide us with information on the data struc-ture of their database. Those meetings will consume several weeks.

It turns out that there were many other requirements that the Aba-cus team overlooked when developing their estimate of the delivery date. For example, the system is being designed to function over the Web. Epsilon has a corporate policy mandating reviews by the legal department for all Web-based solutions. These reviews typically take six weeks. Furthermore, projects of this nature that are carried out with important partners require periodic senior management reviews, and scheduling such reviews can be a problem. A host of other time-consuming requirements emerge as a result of the normative scenario-building exercise.

At the end of the morning, when the exercise is done, it becomes clear that the earliest date that the product can be delivered to Kappa Capital is May, about nine months after the project’s beginning. If Ep-silon submits the original estimated delivery date of November 30, it will encounter a schedule slippage of at least six or seven months and will have generated plenty of ill will with Kappa Capital.

There is nothing magic about normative scenario-building exer-cises. Their strength lies in the fact that they have us looking into the other end of the telescope. The view we get is sufficiently novel that it helps us to question our operating assumptions. Risk consequences that can be lost through a conventional risk review might be obvious when looked at from a backward perspective.

Scenario-Building Case: Terrorist Attack on Washington, D.C.

Scenario building is particularly appropriate when trying to carry out risk analyses of unthinkable events. For example, in spring 2002, the Center for Strategic and International Studies developed a scenario for an attack on Washington, D.C., by terrorists with a dirty bomb, a conventional bomb wrapped in radioactive material. When it ex-plodes, it disperses radioactivity into the community for an area of several square blocks. If there is a strong wind, the radioactive debris could be transported over a much wider area. The scenario develop-ment team concluded that while the immediate number of casualties of the explosion would be relatively small, the panic it would create in

the community, coupled with cleanup costs, would make its impact very high. Consequently, disaster plans should focus heavily on ad-dressing logistical issues to reduce the chaos that would ensue after a bomb has been detonated, for example, ensuring the free flow of traf-fic, to providing timely information to the public, and keeping busi-nesses and government functioning.

LIKELIHOOD-IMPACT MATRIX

Risk comprises two components: likelihood and impact. When you say, “Getting hit by a bolt of lightning is not so risky, because it hap-pens so rarely,” you are emphasizing its likelihood aspect. Being struck by a bolt of lightning is not very likely.

Someone might disagree with you and respond to your statement in the following way: “I don’t agree. Getting hit by a bolt of lightning is quite risky, because if you are struck, it can fry you alive!” This per-son is looking at the impact aspect of risk. If you are actually struck by lightning, it will harm you severely.

The two components of risk can be combined in a single chart called the likelihood-impact matrix. An example of this matrix is shown in Figure 5.1. A measure of the likelihood of an event is pre-sented on the vertical axis. In our example in Figure 5.1, three levels of likelihood are noted: low, medium, and high. (If you want, you can

Likelihood

Impact High

High Medium

Medium Low

Low

Figure 5.1. Likelihood-Impact Matrix.

picture more levels, for example, not likely, somewhat likely, moder-ately likely, likely, very likely.) A measure of impact is presented on the horizontal axis: low, medium, and high. (Again, you can employ more levels if you want to, for example, no impact, little impact, moderate impact, moderately high impact, high impact.)

The likelihood-impact matrix offers a good way to categorize risk events qualitatively in terms of their probability of occurrence and their consequences. Risk events appearing in the dark shaded cell in the top right-hand corner are called red zone risk events. Those ap-pearing in the medium gray shaded cells are called yellow zone risk events. Those appearing in the light gray shaded cells are called green zone risk events.

Consider how each of the following risk events can be categorized according to the two dimensions of risk:

Encountering ants at a picnic in Maine. This event is very likely to occur, but its impact is low. That makes it a green zone event.

The picnic planners shouldn’t spend too much time worrying about dealing with it.

Earth is struck by an asteroid. This event is very unlikely to occur in the next ten thousand years, but if it does happen, it will have a catastrophic impact. Remember that such an event caused the extinction of dinosaurs 65 million years ago. As terrifying as the consequences of this event may be, the fact that it has a near-zero probability of occurrence makes it a green zone event.

Earth’s citizens should not lose too much sleep worrying about asteroid hits.

You are struck by a car while running blindfolded across a busy street. This is a red zone event. The probability of being struck by a car if you are crossing a busy street while blindfolded is very high. And if you are struck by a car, the consequences can be se-vere. The best way to handle this risk event is to avoid playing such a silly, dangerous game.

The likelihood-impact matrix is one of the most useful tools in the risk manager’s toolbox. By categorizing risk events according to the two dimensions of risk, risk analysts can determine readily whether individual risk events warrant careful attention.

Dalam dokumen Managing Risk in Organizations (Halaman 92-107)