Что такое управление рисками в ИТ и чем ёмкость отличается от аппетита

Зачем управление рисками

Риск — возможное событие, которое способно причинить вред или потерю либо затруднить достижение целей; это же слово означает неопределённость исхода, и оно применимо к вероятности как плохого, так и хорошего 1. ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 даёт организации способ находить риски и обходиться с ними осознанно, а не по факту.

ITIL связывает риски с самой природой услуги. УслугаУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation определена как способ дать заказчику нужный результат, избавив его от связанных с этим затрат и рисков 1. Отсюда мысль, которая объясняет, почему практика важна именно провайдеру:

Каждая услуга снимает часть рисков с потребителя и одновременно накладывает на него новые. Соотношение снятого и наложенного — часть ценностного предложения услуги 1.

Второе, о чём стоит помнить: несделанное тоже риск. Организация, которая не вкладывается в услуги и отношения с заказчиками, теряет положение на рынке; окружение меняется, и неспособность меняться сама становится риском 1.

Когда практика работает

Три вопроса, ответы на которые лежат в реестре рисков, а не в презентации о рисках.

У каждого риска есть владелец. Как проверить: по любой записи видно имя человека, отвечающего за то, чтобы риск был понят и обработан 1.

Известно, сколько риска организация готова принять. Как проверить: аппетит к риску задан руководством и на него ссылаются при решениях 1.

Обработка выбрана и доведена до конца. Как проверить: у риска записан способ обработки и оценка после неё — остаточный риск 1.

Что входит и что рядом

Ёмкость и аппетит: два предела, которые путают

Понятия здесь два, и разница между ними определяет, кто и что решает 1.

Ёмкость риска — предельный объём риска, который организация вообще способна вынести. Определяется руководством и опирается на то, чем организация рискует: репутацией и имуществом. Превышение угрожает самой способности продолжать работу.

Аппетит к риску — объём риска, который организация согласна принять. Тоже задаётся руководством, но служит для принятия решений в повседневной работе.

Правило, которое стоит запомнить: аппетит всегда меньше ёмкости 1. Организации, которые выбирают крупный риск ради крупной выгоды, и те, кто рискует мало и тем самым теряет возможности, различаются именно аппетитом 1.

Практический смысл: спор «рискованно или нет» бесплоден, пока не названы оба предела. С ними он превращается в разговор о том, вписывается ли конкретное решение в согласованные рамки.

Что на входе и что на выходе

Практика собирает риски отовсюду: из проектов, изменений, инцидентовИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами, поставщиков, планов. Отдаёт — понимание, что делать, и решения, которые принимает не она.

Особенность: практика редко устраняет риск сама. ITIL говорит об этом честно — полностью исключить риск иногда возможно, но это редкость 1; остальное — снижение, разделение и принятие.

Реестр рисков

По каждому риску в реестре стоят свои поля 1:

Про владельца сказано отдельно и жёстко. Сам он действия по управлению риском может и не выполнять, но обязан убедиться, что они правильные и что их действительно выполнили. Назначают его сразу при выявлении риска и записывают в реестр 1.

Четыре способа обойтись с риском

Перечислены они одинаково и в этой практике, и в безопасности 1 4:

Избежание — не делать рискованное действие вовсе. Работает, когда от действия можно отказаться.

Изменение — внедрить меры, снижающие вероятность или последствия. Самый частый способ и самый дорогой.

Разделение — передать часть риска третьей стороне: страхование, подряд, договорные обязательства.

Принятие — сознательно принять риск, если он ниже приемлемого порога и вписывается в аппетит организации.

Практическая проверка зрелости: принятые риски записаны и подписаны. Непринятое решение выглядит на бумаге так же, как принятое, — разница обнаруживается в момент, когда риск сработал.

Как это работает

Процессов три: руководство рисками, выявление с анализом и обработкой, наблюдение и пересмотр 1.

Цвет шага: техническая работа решение и полномочия проверка, разбор, улучшение

Два места стоит объяснить отдельно.

Первый шаг — не формальность. ITIL называет налаженное руководство рисками отдельным фактором успеха и напоминает: любая работа с рисками требует ясного понимания ёмкости и аппетита организации 1.

Второй шаг — про культуру, а не про форму. ITIL сводит в один фактор успеха и выращивание культуры работы с рисками, и само выявление 1. Причина простая: риски находят люди, которые не боятся о них говорить.

Что с чем путают

Риск и проблема. Риск ещё не случился; проблема уже есть. Разные практики и разные решения.

Риск и угроза. Угроза — источник; риск — событие с вероятностью и последствиями.

Управление рисками и запрет. Запрет — одна из четырёх возможных обработок, причём не самая частая 1.

Аппетит и осторожность. Аппетит — согласованный на уровне организации объём риска, а не свойство характера руководителя 1.

Кто участвует

Как измерять

Самый честный показатель — сработавшие риски, которых не было в реестре. Он показывает не качество обработки, а качество разговора: видит ли организация то, что с ней происходит.

Оценку риска Брукс предлагает сверять с тем, что случилось на самом деле. Два показателя об одном: доля инцидентов, которые происходили чаще предсказанного, и доля элементов конфигурацииЭлемент конфигурацииЛюбой объект, которым надо управлять, чтобы предоставлять услугу: сервер, приложение, лицензия, документ.ITIL, простой которых оказался дольше ожидаемого; у обоих цель 50%, тревога 70 5. Это калибровка: реестр рисков перестаёт быть упражнением в воображении и начинает проверяться фактом. Ограничение он называет сам — приём работает на частых мелких рисках и бесполезен на крупных редких, где сравнивать не с чем.

Словам «высокая» и «низкая» он требует придать числа. Чтобы сверка вообще состоялась, градации вероятности должны быть заданы количественно, и пример дан прямо: высокая — свыше двухсот событийСобытиеИзменение состояния, замеченное мониторингом.ITIL 4 в месяц, средняя — от ста до двухсот, низкая — меньше ста 5. Без этого прогноз непроверяем: любое случившееся подходит под «средний риск» задним числом.

Показатель из таблицы выше у него тоже есть, и с порогами. Инциденты по рискам, которых в оценке не было: цель 10, тревога 20 5. Обоснование стоит того, чтобы его повторить: предусмотреть все опасности невозможно, и смысл счёта не в упрёке, а в том, чтобы увидеть, в какой области распознавание рисков хромает.

И два числа против бумажной работы. Выявлять новые риски мало — нужны действия, и они считаются отдельно: цель 5 при тревоге в 3 5. А совещания с поставщиками и владельцами внутренних процессов заведены как метрика потому, что без них внимание сторон к рискам сходит на нет: цель 3 встречи, тревога 1. Числа Брукса — образцы для настройки, а не отраслевая норма.

Отдельно стоит заметить, чего в его наборе нет. Это единственное приложение книги без показателя удовлетворённости: работу с рисками он не считает предметом мнения заказчика 5.

Зрелость управления рисками

✕

Где ломается чаще всего

Шесть мест, в порядке частоты.

Реестр ведётся для аудита. Записи обновляются перед проверкой, решения принимаются мимо них.

Владельцы не назначены. Риск описан, отвечать за него некому — владельца положено назначать сразу при выявлении 1.

Аппетит не задан. Каждое решение обсуждается заново, потому что не с чем сравнивать 1.

Обрабатывают только плохое. Возможности не рассматриваются как риск, хотя ITIL прямо говорит: несделанное тоже риск 1.

Принятие не оформляется. Решение принять риск нигде не записано, и в день срабатывания оказывается, что его никто не принимал.

Пересмотра нет. Оценки, сделанные два года назад, применяются к изменившейся обстановке.

Что говорят своды

Своды знаний и стандарты, которые описывают эту практику:

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ITIL держит риски отдельной практикой с тремя процессами и четырьмя факторами успеха, включая культуру разговора о рисках 1.

ГОСТ Р ИСО/МЭК 20000-1 требует определять и управлять рисками для системы управления и услуг: подход к рискам, критерии и оценка в заранее назначенные сроки, а также отдельная оценка рисков доступности, непрерывности и безопасности 2.

COBIT выделяет управление рисками отдельной целью домена согласования и планирования 3.

Специализированные стандарты по управлению рисками дают методику оценки и обработки, к которой своды управления услугами отсылают.

Вывод для практики: рамка одинакова у всех — выявить, оценить, обработать, наблюдать. Разница в том, кто задаёт пределы: своды сходятся, что это работа руководства, а не службы рисков.

Где описано

Что почитать дальше

Три соседние практики, где риски проявляются заметнее всего: SECУправление информационной безопасностью — риски для сведений, CONУправление непрерывностью услуг — риски перерыва в работе, CHNКонтроль изменений — риски конкретного изменения.