3. Risk Management

1. 3. Risk Management 2006

2. Road SafetyAn Example of Complex Improvement Risk Management Speed control Supervision Law enforcement Protection Helmet, belt… Infrastructure Signal power supply Process efficiency Braking system Recovery Surgery

3. Pre-event Post-event • Hazard • Prevention • Detection • Surveillance • Exposure • Risk Control • Protection • Insurance • Resiliency • Reactivity • Robustness • Adaptability • Contingency • Restore • Repair • Adapt Minimise probability of event Minimise damage if event happens Cope with the damage caused by the event The Risk Chain Event

4. Mis on risk? Riskina mõistame me ebasoovitava sündmuse ilmnemist. Riski iseloomustavad tõenäosus ja mõju - seega on riski rahaline väljendus funktsioon ebasoovitava sündmuse tõenäosusest ja sündmusega kaasnevast kahjusummast. Speculative and Hazard Risks

5. Threat and Risk

6. Riskide tüübid • Krediidirisk • Tururisk • Operatsioonirisk • ...

7. Risk Management Paradigm

8. Function Diagram

9. Example Implementation

10. Continuous Risk Management Application Roadmap

11. Method and Tool Content

12. What Is Identification?

13. Data Items

14. Data Items

15. Methods and Tools

16. Operational Risk Is Integral To Enterprise RiskManagement

17. Business Risk

18. Operational Risk • Operational risk is a form of hazard risk affecting day-to-day businesses operations and, as such, is one of the many facets of business risk. • Operational risk is the potential failure to achieve mission objectives

19. Operational Risk Tolerance • Operational risk tolerance is the maximum overall exposure to operational risk that will be accepted, given the costs and benefits involved.

20. Mission assurance • Mission assurance is establishing a reasonable degree of confidence in mission success.

21. Categories of Operational Threat

22. Mission Threat • The mission is the cornerstone of a work process and defines what success looks like. If that picture is skewed or flawed, the entire system could be out of balance and produce unexpected, or unwanted, results. • For example, if the technical objectives of a software development project are overly ambitious in relation to its budget, you will have to make difficult choices when beginning the project. • Lacking the requisite funds, you might be forced to cut back on staff allocated to certain tasks, or you might decide to eliminate certain equipment expenditures. • Something, somewhere, has to give.

23. Mission Threat • The consequences of your choices will not be felt immediately, but somewhere during the course of the project you will almost certainly encounter a crisis. • When that crisis occurs, you will have to make some difficult decisions. You might be forced to adjust the technical objectives by aligning them more closely with the remaining budget. • Or you might have toconsider assuming a cost overrun for the project. • If the former is chosen, you will have the unpleasant task of informing your customer that the software lacks some of its promised features. • If the latter is selected, your management will undoubtedly be eager to hear your explanation for the budget overrun. • The imbalance that existed from day one will have come full circle and will require a change to the mission objectives.

24. Mission Threat • A mission threat is a fundamental flaw, or weaknesses, in the purpose and scope of a work process. • It injects considerable vulnerability into the very foundation of a work process and exposes it to a substantial amount of operational risk.

25. Design Threat • While the mission describes the goal, or objectives being pursued, the design of a process delineates the roadmap for achieving the mission. • It outlines the resources needed to complete the job as well as all steps, decisions, and handoffs required to execute the process successfully. • A design threat is an inherent weakness in the layout of a work process. • It can have far-reaching consequences because it embeds risk within the structure of a process.

26. Design Threat • A bottleneck is an excellent example of a design threat, illustrating how inefficiencies can be designed into a process. • The presence of a bottleneck means that the flow of work products exceeds the capacity designed into the process, which limits the flow at a particular point in the process. • Such restrictions cause the process to function at a lower level of efficiency than required to meet mission objectives and casts doubt on the potential for success.

27. Activity Threat • Whereas the mission and process design provide the blueprint for operations, activity management is focused on assembling, organizing, and overseeing the resources needed to execute that plan. • An activity threat is a flaw, or weaknesses, arising from the manner in which activities are managed and performed. • This type of threat can result from a variety of sources, ranging from people’s actions to unreliable performance of support technologies. In essence, activity threats occur when actual performance deviates from what was planned or anticipated.

28. Activity Threat • For example, think about what happens when inexperienced people, who also have not received adequate training and education for their positions, staff a process. • Do you expect novices to perform their assigned tasks seamlessly? • In all likelihood, they will be prone to making mistakes and poor decisions, at least initially, which puts the mission at risk.

29. Environment Threat • In an ideal world, managers would be able to ignore the outside world, focusing solely on the tasks at hand. • However, processes are not executed in vacuums. • Managers need to be keenly aware of their surroundings and understand how environmental conditions can affect their work. • An environment threat is an inherent constraint, weakness, or flaw in the overarching operational environment in which a process is conducted. • It represents an inherited source of threat, making it especially difficult to manage in many instances.

30. Environment Threat • Think about an organization plagued by low morale among its staff. • People who work in such environments tend to have higher rates of absenteeism, often leaving key activities short staffed. • They may also take less pride in their work, choosing to go through the motions each day. • The end result of such apathy is poor performance, which, of course, places mission objectives at risk. • Although the manager of a given work process might not be responsible for the root causes of low staff morale, he or she must deal with its effects on process performance, which will likely not be an easy task.

31. Event Threat • Because our world is constantly changing, we must be on guard for sudden events that can immediately derail progress. • An event threat is a set of circumstances triggered by an unpredictable occurrence that introduces unexpected change into a process. • A computer virus is a good example of an event threat. • Many vulnerabilities are embedded in the computer systems that we use every day. • Some can affect a computer’s performance during routine use by causing it to crash periodically. • By contrast, others lie dormant within the computer’s operating system and applications and do not produce any visible effect on the computer’s performance during day-to-day operations.

32. Extrinsic and Intrinsic Risk • Of the five categories of threat, event threats stand out as being fundamentally different from the others. • With event threats, vulnerabilities do not directly place a mission at risk; they are merely a conduit for risk and lie dormant during normal business operations. • An event must combine with one or more of these vulnerabilities to actually produce risk.

33. Extrinsic and Intrinsic Risk • If there is no possibility of the event occurring, there is, by definition, no risk. In this document, the risk produced by an event threat is called extrinsic risk because its underlying trigger (i.e., the occurrence of an event) occurs outside of expected or predictable operational conditions. • The mechanism responsible for generating extrinsic risk (i.e., an event in conjunction with one or more vulnerabilities) also influences its basic properties, which are measured using probability and impact. • In general, the probability associated with extrinsic risk is heavily influenced by the likelihood that its triggering event will occur. • As a general rule, events with the potential for producing very high, often catastrophic, consequences have very low probabilities associated with them.

34. Extrinsic and Intrinsic Risk • By contrast, threats from the other four categories (mission, design, activity, and environment) do not require an external trigger to produce operational risk. • In this case, the mere act of conducting a work process in combination with certain vulnerabilities is sufficient.

35. Extrinsic and Intrinsic Risk • The risk generated by these four categories is called intrinsic risk because it is an inherent part of process execution. • The characteristics of intrinsic risk are quite different from those of extrinsic risk.

36. Extrinsic and Intrinsic Risk • For example, intrinsic risks are often more likely to occur than extrinsic risks because the stimulus needed to produce intrinsic risks (i.e., process execution) is always present. • In addition, while extrinsic risk often produces catastrophic consequences, experience shows that intrinsic risks can cause a variety of impacts, ranging from negligible to very high. • Catastrophic impacts triggered by a specific source of intrinsic risk, although possible, are rare.

37. OR and Operational Excellence • From an operating standpoint, these challenges require a cross-enterprise excellence in at least 3 areas • technology infrastructure • business process architecture • business process integration • Efficiency and resilience are two sides of the same coin • For each $ spend on projects, there is an optimum balance between efficiency and resilience improvement objectives Operational Agility Operational Risk

38. Risk Sources Ordered by Importance 1. Lack of top management commitment 2. Failure to gain user commitment 3. Misunderstanding of requirements 4. Inadequate user involvement 5. Failure to manage end-user expectations 6. Changing scope and/or objectives 7. ….

39. Greater Risk of IT Failure • Business transactions are increasingly dependent on IT, so failures in IT are more likely to impact the business, and that impact is more likely to be severe. • The IT environment is increasingly complex, so even if the environment stays the same size, the number of potential failure points is rising. • IT directly controls less of the infrastructure (“virtual IT environment”), so managing the possibility of failure is more important because IT has less ability to react after the failure occurs. • When an IT failure occurs, there is less time between the failure and its impact on the business. • IT failures are increasingly visible outside the data center, so more people react negatively when a failure occurs.

40. Greater Risk of IT Failure • IT today has more potential to enable business than ever before, but failures in IT have more potential to disable business. • At the same time, the traditional risk management strategy of tight change control is less often available, and less often effective.

41. IT Downtime • IT downtime joins other natural disastersin business risk management. • As IT “becomes” the facility, it is going to raise new, unheard of risks. • A slow Web site could be asdisastrous as a tornado.

42. IT Downtime In a Stage 1 enterprise, the interdependencies of business processes, IT and external entities aremanaged by manual or non-IT interfaces. Thus, if an IT system is not available, it is notapparent to customers or the supply chain, and the business can muddle along until thecomputers are fixed.

43. IT Downtime In Stage 2, IT has permeated the business processes, sowhen thecomputers are down, the business processes come to a halt. This inherently brings morebusiness risk to theenterprise. Most largeenterprises have created some level of dependencybetween business processes and IT (any ERP, HR, integrated financials or sales managementsystem creates this business/IT process interdependency).

44. IT Downtime In stage 3, where enterprises will beduring the next five years, the business risk of IT is maximum. The cost of maintaining theintegrity of these systems will behuge, but the cost of downtime will be evengreater. There hasnever been a more critical time for massive efficiency in IT systems.

45. IT Downtime • IT is permeating the entire business function. • IT is inextricably linking customers, suppliers,business partners and government into a seamless continuum of business activity. • There are noinsulating layers, where a functional failure in one aspect of the business can be an isolatedincident. • Not only are business processes interrelated, they are becoming interdependent.

46. Availability - This is broadly defined as having the resource in a given place, at the given time,and in the form needed by the user. Confidentiality - Some define this as "The concept of holding sensitive data in confidence, limitedto an appropriate set of individuals or organizations". Integrity - One can define this as "The ability of an AIS to perform its intended function in asound, unimpaired manner." The replacement cost The cost to recreate intellectual property The value of an hour of computing time. Other considerations (embarrassment, loss of confidence,…) Threats to the Information Systems

47. Implications • Risk management should be integrated into operations decision making in every job function and every role. • Risk management should be taken seriously and given an appropriate amount of effort. • Risk management should be done continuously to ensure that operations is dealing with the risks that are relevant today, not just the ones that were relevant last quarter.

48. Characteristics of Risk • Risk is a fundamental part of operations. The only environment that has no risk is one whose future has no uncertainty: no question of whether or when a particular hard disk will fail; no question of whether a Web site’s usage will spike or when or how much; no question of whether or when illness will leave the help desk short-staffed. Such an environment does not exist. • Risk is neither good nor bad. A risk is the possibility of a future loss, and although the loss itself may be seen as “bad,” the risk as a whole is not. It may help to realize that an opportunity is the possibility of a future gain. There is no risk without opportunity, and no opportunity without risk. • Risk is not something to fear, but something to manage. Because risk is not bad, it is not something to avoid. Operations teams deal with risks by recognizing and minimizing uncertainty and by proactively addressing each identified risk. If a loss is one possible future outcome, then the other possible outcomes are gains, smaller losses, or larger losses. Risk management lets the team change the situation to favor one outcome over the others.

49. Principles of Successful Risk Management • Assess risks continuously. This means the team never stops searching for new risks, and it means that existing risks are periodically reevaluated. If either part does not happen, risk management will not benefit the company. • Integrate risk management into every role and every function. At a high level, this means that every IT role shares part of the responsibility for managing risk, and every IT process is designed with risk management in mind. At a more concrete level, it means that every process owner: • Identifies potential sources of risk. • Assesses the probability of the risk occurring. • Plans to minimize the probability. • Understands the potential impact. • Plans to minimize the impact. • Identifies indicators that show the risk is imminent. • Plans how to react if the risk occurs.

50. Principles of Successful Risk Management • Treat risk identification positively. For risk management to succeed, team members must be willing to identify risk without fear of retribution or criticism. The identification of a risk means the team faces one less unpleasant surprise. Until a risk is identified, the team cannot prepare for it. • Use risk-based scheduling. Maintaining an environment often means making changes in a sequence, and where possible the team should make the riskiest changes first. An example is beta-testing an application. If the company wants 10 features to work, and two of them are so important that the lack of either would prevent the application’s adoption, test those two first. If they were to be tested last and either was to fail, then the team would have lost the resources invested in testing the first eight. • Establish an acceptable level of formality. Success requires a process that the team understands and uses. This is a balancing act. If the process has too little structure, people may use it but the outputs won’t be useful; if it is too prescriptive, people probably won’t use it at all.