Пару слов про управление реализовавшимися рисками

В очередной раз убеждаюсь, что это весьма и весьма полезно — ходить друг к другу на курсы. Конечно же, я про различные курсы, которые проводит Cleverics. Хотя это довольно дорого для компании — выделять двойные ресурсы под трёх- , а то и пятидневный курс, сложно переоценить объём полезной информации, которую можно получить во время курса. Всё потому, что тренер, с виду притаившийся в углу класса и что-то с упоением записывающий, имеет возможность не только подсмотреть приёмы подачи материала у коллеги и, что называется, со стороны оценить обучающие материалы, но и послушать вопросы участников. А в этих вопросах целый мир.

В этот раз меня заинтересовал довольно неожиданный вопрос. Неожиданность вопроса заключалась в том, что сама его формулировка указывала на наличие специфического понимания охвата некоторых практик в рамках отдельно взятой компании. В частности, прозвучала следующая формулировка: «У нас проблема — это реализовавшийся риск». А сам вопрос, обусловленный предыдущим тезисом, звучал так: «В рамках какой практики согласно ITIL осуществляется управление реализовавшимися рисками?». Мне показалось полезным представить сам вопрос и вариант ответа, который лично у меня напрашивается, на рассмотрение вам, уважаемые читатели блога REALITSM.

Давайте разберёмся. Что есть «реализовавшийся риск»? Если посмотреть на определение риска в ITIL4, то «реализовавшийся риск» — это наступившее (уже не «возможное») негативное событие, наносящее вред или приводящее к потерям и усложняющее достижение целей (обращаю внимание, что данная трактовка является производной от определения риска; в ITIL такой формулировки нет). В рамках какой практики мы устраняем последствия негативных событий в первую очередь? Вроде как в рамках практики управления инцидентами. Итого первая часть ответа на поставленный вопрос у нас есть — это управление инцидентами. Случилось негативное событие, риск наступления которого мы возможно оценили заранее (а может и нет), и теперь мы имеем дело с последствиями в виде прерывания или деградации услуги.

С другой стороны, риски, как мы знаем, бывают очень разной природы, и не все негативные события, ими вызванные, регистрируются в виде инцидентов. Более того, по сути каждая из практик, так или иначе, имеет дело с каким-то своим специфическим набором рисков. И, независимо от наличия или отсутствия зарегистрированного инцидента, в рамках каждой из практик необходимо анализировать реализовавшиеся риски, чтобы извлечь уроки из соответствующих ситуаций и предпринять усилия, направленные на снижение или исключение вероятности реализации этих рисков в дальнейшем. То есть регулярно выполнять упражнение по постоянному совершенствованию. Итого вторая часть ответа, похоже, выглядит так: это собственно практика управления рисками, как таковая, а также все практики, которые обрабатывают какие-то «свои» виды рисков. В частности, в случае реализации какого-либо риска мы, в определённых случаях, можем говорить о наличии проблемы, то есть причины инцидентов.

В итоге получается, что управление реализовавшимися рисками не ограничивается рамками какой-то одной практики. Что думаете, коллеги? Похоже на мир, как его понимаете вы?

ITIL ITIL Intermediate: Planning Protection and Optimization

Учебный курс: управление качеством и рисками ИТ-услуг, доступностью, мощностями, непрерывностью — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Алексей

    Управление событиями. В дальнейшем уже в зависимости от собственно самого события которое реализовалось соответственно управление инцидентами или другой подходящий процесс.

    Да, проводя анализ реализовавшихся рисков нужно помнить, что если мы сочли какой то риск маловероятным и потому отказались от его митигации и просто «приняли», а он все таки реализовался — это вовсе не значит что мы тогда приняли неправильное решение. Мы можем выбрать на кубике диапазон от 1 до 5 или выбрать что выпадет 6. Правильный ответ очевиден, но ведь 6 все еще может выпасть...

  2. Алексей

    На мой взгляд, после устранения реализовавшегося риска надо подключать дополнительные процессы. В первую очередь возможно управление проблемами. Как было упомянуто в вопросе в компании есть проблема и возможно что она не технического плана, а есть вероятность, что кто-то постоянно «косячит», в том числе возможно не управляя своими рисками. Во вторую очередь можно подключить управление знаниями, сделав разбор причин и методов устранения и занеся это в скрижали.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
25
Учебный курс:
ITIL® 4 Foundation (очно) 
НОЯ
25
НОЯ
28
Бесплатный вебинар:
ITIL 4: итоги 2019 года