Risk Management

Service Design – As Risk Managment

Konstantin Naryzhny has already written broadly on the subject. In the “warranty” processes (availability management, capacity management, continuity management and information security management) there is a minor but very important risk management component with a requirement to continually analyse the threats relating to each process and present effective and efficient countermeasures. And it is better done together: one service, one budget, and ideally one leader. The importance of communication between processes on the issue of risks is described in ITIL.

PROBLEM MANAGEMENT – As Risk Management

When first hearing about problem management, our course members often exclaim: “So this is risk management!” It is difficult to disagree: problem identification, classification, diagnosis, and root cause analysis solution implementation ongoing control – the activities that are part of the process strongly resemble those in the risk management cycle.

One could define risks as things that have not yet occurred but may happen and problems as existing things to be dealt with. However, this can be disputed when we take a look at proactive problem management which tackles the incident prevention by identifying errors that have not “played” yet, based on information from sources external to the production environment. These sources include, but are not limited to, information from vendors, known vulnerabilities, test results colleagues experience and errors that can be identified and assessed early enough (Sometimes even before service operation starts). Although proactive problem management is initiated at the operation stage, it is managed in the context of continual service improvement.

RISK MANAGEMENT as part of Continual Service Improvement

Charles T. Betz has noted of risk management and continual service improvement:

“On a practical level, both need tracking and often involve the same sorts investigators. At least that’s been my experience in working with business partners on both kinds of effort. Certainly, I have been involved in any of many continuous improvement reviews that have resulted in risk identification. I’ve also seen risks recognised that resulted in a continuous improvement cycle.”

To return to the point, let’s look at the definition: according to ISO 31000 “risk is the result of uncertainty on the objectives”. In turn, risk management is “coordinated activities to direct and control an organization regarding risk”. To me, it seems extremely important to point out that we do not manage risks, but manage an organisation that takes risks into account. Going back to the definition of risk and simplifying it, we find that risk management is the management of an organisation in terms of uncertainty. The better the uncertainty is “worked through” (correctly identified, analysed and evaluated), the more justified the managerial decisions we make and the more foreseeable, our achievements are.

If risk/uncertainty is an inevitable part of a purposeful activity, and management is a means of administering the purposeful activity, risk management is part of a manager’s work at any level. It is the part that makes outcomes supplementary, and management more mature in general.

Now it is relatively clear that risk management is not an ancient history 27th ITIL process, but something that is present in many sections of the entire library. In addition to the processes mentioned above, it is not difficult to find risk management in change and release management and even in-service portfolio management, for example. Moreover, IT service management system is nothing but a tool to reduce business risks associated with IT, as well as to optimize resources and gain value from IT. Therefore, the following answer to the headline question looks quite precise. “ITIL is risk management in many ways.

However, it can be reasoned that risk management should be its own separate process within ITIL. To some, it can look as though risk management has been bounced over because it does not have its own chapter or specific process.

Imagine a tyre (an example from the FAIR technique). It is important to consider whether it is used for its intended purpose or hung from a tree branch by a rope. How worn-out is the rope? How strong is the branch? Is the tyre hanging within a metre of the ground or over an abyss? Assessments of the same risk can vary widely depending on who the assessors are, where they are located and what information they have. Obviously, risk management benefits greatly from the scale and from the use of an integrated approach to identifying and analysing risks and making decisions about countermeasures. It is also helpful if the assessment reports from experts in different fields are reduced to a common denominator.

When we say that there is no risk management described in ITIL, first of all, we mean that there is no centralized function for risk management a single centre for accumulating and maintaining information about risks in their current state (include indicators of probability and impact that can change significantly over time due to our actions and external factors) and its provision to all interested parties for making management decisions.

Do you use the concept, of risks in your activities? Is there a risk management function in your IT organization? If you have it in the business organization, then how does it interact with IT? Is there a shared risk register? If so. how do you assess its effectiveness? what does IT service management tasks it helps to perform? How is the interaction with other processes set up? If there is nothing like that in place or planned, what are the arguments against it? Your thoughts and experience are welcome in the research community.