Портал №1 по управлению цифровыми
и информационными технологиями

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

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

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

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

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

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

Комментариев: 3

  • Алексей

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

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

  • Александр Трофимов

    И самое основное: почему сразу “негативные” события? Позитивные – те же риски. И с ними ещё важнее работать. =)

  • Алексей

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM