Malcolm Chisholm is one of the presenters at the www.dataWarehouse.com online trade show, “Extending the Use of BI to Achieve Rapid Return on Investment.” His presentation, The Value Proposition for Reference Data,” is a must-see for those involved in designing an enterprise architecture. Learn about the scope, costs and risks of managing reference data and the added value proposition. Registration is free! Click here to view his presentation www.dataWarehouse.com/tradeshow A >.
Risk is something we all live with, but since the terrorist attacks on the U.S. and the wave of corporate scandals, it is a much greater factor in our economy. Individuals and enterprises have been forced to confront risk and incorporate it into everyday decision making. Yet “risk” is a very difficult term to define. To some people it implies vague threats that cannot be quantified and about which little can be done other than taking the chance that adverse events will not materialize or engaging in hand wringing and inaction. Other people have a very definite idea of risk – but nearly always in very specialized circumstances. For instance, credit risk is the chance that a loan will not be repaid. Although, very important, it applies only to enterprises that originate loans and only to the operations of these enterprises that originate loans. Credit risk is well understood, including the data that has to be collected to measure and mitigate it. Similarly, there are other specialized risks such as market risk (the chance that a stock market will lose value) and interest rate risk (the chance that interest rates will change adversely). Everything apart from these specialized financial risks tends to be placed it a category called operational risk. This means that practically all risk is called operational risk, but the term does not really mean that operational risk factors share common characteristics. It is simply used to lump together risk factors that are not credit, market or interest rate risks. As such, it is better to simply use the general term “risk” rather than “operational risk” with the understanding that the specialized financial risks are topics not covered under “risk” in general.
Just as there is a pressing need to understand what risk is, today there are even more urgent needs to measure and mitigate it. This is where BI can play a role but, unfortunately, as we shall see, it is more a question of understanding how to apply BI to risk management than simply implementing prescribed solutions.
What is Risk?
Figure 1 shows one way of looking at risk. The enterprise and the environment it is situated in are constantly subject to events. These events may trigger other events that, in turn, lead to outcomes that cause some kind of harm to the enterprise. The harm that is done can vary, as can the tolerance for it. Some harm may be regarded as simply a cost of doing business and may not even be seen as the result of adverse outcomes. Other harm may be viewed as adverse but about which little can be done. Some enterprises view certain levels of theft in this way. Then there are adverse outcomes that result in severe losses, such as an error of judgment by an employee that renders an enterprise liable to a lawsuit. Finally, there are catastrophic losses that can permanently damage an enterprise or even force it out of existence.
Figure 1: The Spectrum of Risk
Risk management tends to focus on the factors that can lead to severe or catastrophic losses for an enterprise. The realm of reducing what are viewed as legitimate, or even questionable, expenses is covered by efforts focused on improving operational efficiency or reducing waste. Risk management, by contrast, focuses on preventing or mitigating what an enterprise clearly recognizes as losses. Interestingly, however, BI plays a role across the spectrum illustrated in Figure 1, since metrics of operations and events are critically important to both improving operational efficiency and risk management.
The banking sector provides a good example of the focus of risk management. Banking regulators worry about what can cause banks to fail. Thus banks are required to set aside money (capital reserves) to cover losses, e.g., from defaulted loans (credit risk).
However, in the 1995 Barings Bank suffered a huge loss due to a rogue trader who covered up trading losses he suffered. Barings was essentially broken as a result, although it was later taken over by another bank. Similar incidents happened at Sumitowo, Daiwa and more recently at AIG. Bank regulators, principally represented by the Bank for International Settlements (BIS), have long understood the nature of these kinds of risks, and in1998 introduced an initiative known as the Second Basel Accord to try to make banks more resilient to “operational risk” (as opposed to credit, market and interest rate risk). The Second Basel Accord wants banks in the future to increase their capital reserves to cover operational risk. However, the problem is that operational risk is so general that it cannot be estimated easily, and so the loss reserves cannot be calculated. Furthermore, banks do not like the idea of covering operational risk by placing a lot of money in reserves where it cannot generate a high return. Thus, the Second Basel Accord is taking longer than originally anticipated to implement and is currently targeted for 2006.
One way for banks to reduce the need for capital to cover risk would be to quantify it accurately and take steps to mitigate it, thus reducing their risk profile and the need for reserves. The problem is that risk in general cannot usually be identified, measured or managed centrally. Businesses are simply too complex, and detailed understanding of business processes is usually in the hands of subject matter experts distributed throughout the various organizational units of an enterprise. Thus, senior management does not usually have the working knowledge to be able to assess risks in an accurate fashion. Attempts to impose detailed risk management from above tend to be counterproductive, unless senior management is dealing with specific risk factors where interaction with business operations is clearly and widely understood. Unfortunately, this is usually only possible after losses have occurred. Risk management is better applied before significant losses occur, and it requires individual business units to understand the risks inherent in their operations. This means that a great deal of risk management is a bottom-up rather than a top-down process.
In parallel with the decentralization of risk management, there has been growing emphasis on self-assessment of risk. This involves creating a more proactive “risk culture” in enterprises and not waiting for auditors or external regulators to provide direction. “Self-assessment” means that enterprises will build in controls to detect and mitigate risk within their operations rather than rely on post facto checklists. Yet, establishing a risk culture is not easy because risk is simply too amorphous a concept until detailed specific business processes are considered.
One way to measure risk is to have individual business units follow a goal/question/metrics approach, a methodology originated by Basili et al in 1984. Subject matter experts first need to determine goals, i.e., how to manage risk factors in the operations they deal with. To do this involves formulating questions, which conceptually model how these goals will be attained. Lastly, each question needs to be associated with a set of metrics that provide answers to the questions and can thus measure the extent to which each goal is being attained. Brainstorming techniques are recommended to implement the technique.
A goal/question/metrics approach, or any other methodology used to implement risk management, will result in the identification of key risk indicators and ways to measure them. BI is ideally placed to function as a component in this environment. Rather than gathering data for competitive advantage, it needs to be used to monitor business operations for risk management, in particular looking for rare events that have the potential to trigger a key risk factor and cause a misfortune. Another difference to the usual way in which BI is used, is that the focus of the data is not financial but operational. A great deal of management reporting produced from BI is financially oriented. This has limited usefulness for risk management, because it does not directly show how an enterprise’s operations are functioning. Even worse, the financial perspective may actually blind management from obtaining a clear picture of these operations. Thus, simply trying to reuse, or marginally extend, BI implementations to cover risk management is unlikely to be an effective approach. An enterprise does have to adopt a minimum level of risk culture and go through the process of identifying risk factors and setting up measures for them.
One other aspect of data collection for risk management is somewhat unique. This is the need to collect data on “near misses.” A near miss is an event that is recognized as having had the potential to cause an adverse outcome, although it did not actually do so. Near misses are important as they may highlight the need for additional risk mitigation or, more positively, they may show how current risk management is operating successfully. It may not be easy to capture data on near misses in a traditional BI environment, particularly if someone with operational responsibility has the task of characterizing near misses. Staff may fear repercussions for drawing attention to these events. This is one reason why creating a risk culture within an enterprise is so important – staff should be able to provide adequate feedback that can improve risk management without fear of adverse consequences for themselves.
After business units determine the risk factors that they deal with and the metrics needed to measure these risk factors, there is often a need to stratify risk. The most important risk factors are those that have the potential to affect the survival of the enterprise or the implementation of its mission. With data collection in place, BI can be used to monitor those risks and the controls that are in place for them.
Figure 2: Ways of Analyzing a Risk Factor
Although the traditional BI analysis tools are useful, and indeed even necessary, the way in which they are used may often be different from more traditional financial reporting or competitive analyses.
Figure 2 shows some of the considerations for analytical reporting from BI applications for well-understood risk factors. A well-understood risk factor often combines a predisposition with one or more determining factors. For instance, this is true when people catch diseases. Some people have natural immunity to a disease (i.e., lack a predisposition) and cannot catch it even if they are exposed to the infectious agent (the determining factor). Thus, for any particular risk factor, analytical reports can separate predispositions from determining factors. Risk management associated with preventing predisposition (akin to vaccination) can also be reported on as can avoidance of determining factors or operational controls that stop determining factors from causing adverse outcomes. Quick recognition of losses once they occur is another aspect of analytical reporting as is tracking the timeliness and costs of cures. Historical reporting of assumed losses (i.e., paid for by the enterprise) and/or the cost of insurance versus the cost of losses are yet other facets of analytical reporting. Once again, BI provides an excellent toolset to analyze risk, but the way in which BI needs to be applied is different to its more traditional financial applications.
Risk management is still a relatively new area for most enterprises, and those that focus on it tend to worry about business continuity. Yet, risk management can also be used to reduce costs. For instance, if an enterprise clearly understands a particular risk and can control it, it may be able to reduce the insurance it buys to cover the risk. No insurance company can know more a risk and the way an enterprise deals with it than the enterprise itself. BI provides the means to gather data on risks and to monitor their management, and BI is available to a very wide spectrum of enterprises today. Risk management simply requires that it be used in a different way for a different set of goals.
Malcolm Chisholm, Ph.D. has over 25 years of experience in enterprise information management and data management and has worked in a wide range of sectors. He specializes in setting up and developing enterprise information management units, master data management, and business rules. His experience includes the financial, manufacturing, government, and pharmaceutical industries. He is the author of How to Build a Business Rules Engine and Managing Reference Data in Enterprise Databases and Definition in Information Management. He writes numerous articles and is a frequent presenter on these topics at industry events. Chisholm runs the websites http://www.bizrulesengine.com, http://www.refdataportal.com and http://www.data-definition.com. Chisholm is the winner of the 2011 DAMA International Achievement Award.