Хотите понять, действительно ли вы используете управление рисками в своей работе? Возьмите несколько недавних управленческих решений и попробуйте восстановить, какую роль в них сыграли риски. Лучше выбрать разные ситуации: например, связанные с распределением ресурсов, изменением ИТ-услуги или переносом работ на более поздний срок.
Какие риски рассмотрели до принятия решения? Насколько актуальными и обоснованными были оценки? Учли ли возможные последствия для целей и результатов? Помогла ли информация о рисках сравнить альтернативы и выбрать подходящий вариант? Затем посмотрите, что происходило после принятия решения: предусмотрели ли необходимые меры, отслеживали ли изменения и возвращались ли к решению, когда обстоятельства менялись?
Подобный разбор поможет оценить, насколько управление рисками действительно встроено в вашу работу. И если окажется, что вы не всегда опираетесь на риски при принятии решений, стоит разобраться в причинах. Возможно, дело в том, что информация о рисках не помогает принимать решения так, как могла бы.
А вот какой должна быть информация о рисках, чтобы она действительно помогала руководителю выбирать между вариантами действий, — об этом и поговорим в статье.
Информация должна быть достаточно полной
При выявлении рисков легко сосредоточиться на знакомой области. Технические специалисты обращают внимание на отказы оборудования, уязвимости программного обеспечения и проблемы производительности. Но риски могут быть связаны и с организацией работ, доступностью компетенций, отношениями с поставщиками, бюджетными ограничениями или изменением потребностей бизнеса.
Например, при планировании перехода на новую систему команда может подробно оценить технические сложности миграции, но не учесть, что для сопровождения системы потребуются компетенции, которых сейчас нет у сотрудников. Технически успешный переход в таком случае ещё не гарантирует, что организация сможет полноценно использовать систему и поддерживать её работу.
Если при выявлении рисков учитывается только одна область, руководитель получает неполную картину и может принять решение, которое выглядит обоснованным с технической точки зрения, но создаёт проблемы в других частях организации.
Чтобы снизить вероятность таких упущений, необходимо использовать несколько источников информации и привлекать участников с разной экспертизой. Технические специалисты могут оценить технологические ограничения, руководитель эксплуатации — последствия для повседневной работы, менеджер услуги — влияние на её качество, а представитель бизнеса — возможные последствия для достижения бизнес-целей.
Дополнительно помогает согласованная система категорий рисков. Она задаёт ориентиры для анализа и позволяет проверять, какие области уже рассмотрены, а какие остались без внимания. При этом перечень категорий должен соответствовать деятельности организации: чрезмерно подробная классификация усложнит работу, а слишком общая не поможет обнаруживать пробелы.
Информация должна быть актуальной
Оценка риска отражает ситуацию на определённый момент времени. По мере изменения условий может измениться и сам риск: его вероятность, возможные последствия или доступные способы реагирования.
Предположим, ИТ-подразделение использует систему, которую поддерживает внешний поставщик. Год назад риск прекращения поддержки оценили как невысокий: поставщик продолжал выпускать обновления, а замена системы не планировалась. Позже поставщик объявил о прекращении поддержки через шесть месяцев. Прежняя оценка больше не подходит для принятия решения о сроках миграции и необходимых ресурсах.
Если реестр не пересматривается, руководитель может опираться на оценки, которые уже не соответствуют действительности. Особенно опасна ситуация, когда риск формально закрыт или имеет низкий приоритет, хотя обстоятельства давно изменились.
Для поддержания актуальности необходимы согласованные процедуры пересмотра рисков. Они должны определять, когда проводится плановая проверка, какие события требуют внеочередного пересмотра, кто отвечает за получение информации и кто фиксирует изменения в реестре.
Источники информации зависят от характера риска. Это могут быть сообщения поставщиков, результаты мониторинга, сведения об инцидентах, планы изменений, результаты проверок информационной безопасности, изменения бюджета или требования бизнеса. Важно не просто перечислить источники, а определить ответственных за работу с ними и порядок передачи значимой информации тем, кто управляет соответствующими рисками.
Информация должна иметь нужную степень детализации
Чтобы принять решение о риске, руководителю необходимо понимать, какое событие может произойти и к каким последствиям оно приведёт. Формулировка «риск проблем с поставщиком» для этого недостаточна: непонятно, что именно может случиться, какие последствия ожидаются и на что следует направить усилия.
Более содержательное описание может выглядеть так: «Поставщик может прекратить поддержку используемой системы до завершения перехода на альтернативное решение, что приведёт к отсутствию исправлений критических ошибок и увеличит вероятность длительного простоя услуги».
Такая формулировка позволяет обсуждать конкретные меры: ускорить переход, договориться о продлении поддержки, подготовить резервный вариант или пересмотреть сроки изменения.
Степень детализации при этом зависит от задачи. Для руководителя, выбирающего между несколькими вариантами развития услуги, достаточно понимать основные риски каждого варианта, их последствия и стоимость реагирования. Специалисту, который отвечает за конкретный риск, потребуется более подробная информация: условия возникновения события, затрагиваемые компоненты, причины, существующие меры контроля и действия при изменении ситуации.
Чтобы сотрудники описывали риски с нужным образом детализации, нужны единые правила формулирования. Они должны помогать отделять возможное событие от его причин и последствий, не допускать чрезмерно общих описаний и сохранять информацию, необходимую для дальнейшего анализа. Сотрудников, участвующих в выявлении и оценке рисков, следует обучить применять эти правила на практике.
Информация должна быть связана с целями и решениями
Оценка риска сама по себе мало что говорит о том, насколько он важен для организации. Необходимо понимать, на какую цель, услугу, проект или обязательство риск может повлиять.
Например, риск недоступности системы резервного копирования может казаться менее значимым, чем риск кратковременного снижения производительности пользовательского приложения. Однако если первый риск препятствует восстановлению критичной услуги после серьёзного сбоя, его последствия могут оказаться значительно тяжелее.
Поэтому при анализе рисков необходимо устанавливать связь между возможным событием и тем результатом, достижение которого может оказаться под угрозой. Для ИТ-подразделения такими целями могут быть соблюдение согласованного уровня услуг, выполнение требований информационной безопасности, завершение проекта в установленный срок или обеспечение непрерывности критичных операций бизнеса.
Эта связь позволяет обосновать приоритеты. Если риск влияет на достижение важной для бизнеса цели, его нельзя оценивать исключительно по техническим характеристикам затрагиваемого компонента. И наоборот, техническая проблема не обязательно требует немедленного реагирования, если её последствия для услуг и бизнеса ограничены.
Практически это означает, что при регистрации риска следует фиксировать, с какой целью он связан, какие показатели или обязательства может затронуть и для какого решения эта информация будет использоваться. Тогда реестр рисков становится инструментом управления деятельностью, а не отдельным перечнем потенциальных неприятностей.
Оценки должны быть однозначно понятны
Даже корректно выявленный и подробно описанный риск сложно использовать, если участники по-разному понимают его оценку. Например, один руководитель считает высоким влияние, которое может привести к нескольким часам простоя, а другой относит к высокой категории только последствия, способные остановить работу всей компании.
В такой ситуации сравнение оценок теряет смысл. Более того, участники могут спорить о приоритетах, хотя в действительности используют разные критерии.
Чтобы оценки можно было сопоставлять, необходимо установить единые подходы к определению вероятности и влияния. Для каждой шкалы следует описать, что означают её значения и на каких данных или предположениях основывается оценка.
При оценке влияния полезно учитывать конкретные последствия: продолжительность недоступности услуги, финансовые потери, нарушение обязательств перед заказчиками, последствия для информационной безопасности или репутации. При оценке вероятности необходимо определить, какие свидетельства позволяют отнести событие к той или иной категории. Это могут быть данные об аналогичных событиях, статистика инцидентов, результаты анализа уязвимостей или экспертные оценки с явно обозначенными допущениями.
Например, оценка вероятности отказа оборудования будет обоснованнее, если она учитывает историю отказов, условия эксплуатации и сведения о состоянии оборудования, а не только субъективное мнение специалиста.
Единые критерии не гарантируют полного согласия участников. Их задача — сделать основания для оценки прозрачными, чтобы различия в оценках можно было обсуждать предметно, а решения — объяснять и пересматривать при появлении новых данных.
Информация должна быть доступна нужному человеку в нужный момент
Даже качественная информация не поможет принять решение, если ответственный за него не может своевременно её получить.
Предположим, руководитель проекта выбирает дату запуска новой версии системы. Сведения о рисках известны технической команде, но находятся в отдельном файле, который не включён в материалы планирования. Руководитель принимает решение, не зная, что один из критичных компонентов ещё не прошёл необходимые испытания. Проблема возникает не из-за отсутствия информации, а из-за того, что она не дошла до участника, который должен её использовать.
Для предотвращения подобных ситуаций необходимо определить, кому и в каких обстоятельствах нужна информация о рисках. Например, руководителю проекта — при выборе сроков запуска, менеджеру услуги — при оценке изменений, руководителю ИТ — при распределении бюджета и ресурсов.
Затем следует организовать соответствующий доступ: определить права пользователей в информационной системе, установить порядок предоставления сведений и предусмотреть передачу существенных изменений тем, кого они касаются. Для критичных рисков могут потребоваться уведомления при изменении оценки, приближении контрольной даты или наступлении определённого события.
При этом доступность не означает, что все сотрудники должны видеть весь реестр. Состав предоставляемой информации и права доступа определяются ролями, задачами и требованиями конфиденциальности.
Информация должна быть представлена в подходящей форме
Один и тот же риск можно представить по-разному в зависимости от того, какое решение предстоит принять. Универсальный отчёт, содержащий все доступные сведения, не всегда удобен: он может быть слишком подробным для руководителя и недостаточно конкретным для специалиста, отвечающего за реагирование.
Например, если руководство выбирает вариант развития услуги, ему потребуется сравнительная таблица, в которой для каждого варианта указаны основные риски, возможные последствия, стоимость мер реагирования и оставшиеся после их применения риски. Такое представление позволяет сопоставить альтернативы и оценить, какой вариант лучше соответствует целям организации и имеющимся ограничениям.
Для оперативного управления конкретным риском больше подойдёт карточка, содержащая описание события и последствий, текущую оценку, действующие меры контроля, запланированные действия, ответственных и условия пересмотра. Специалист сможет быстро понять, что происходит с риском и какие действия требуются.
Чтобы организовать такую работу, необходимо определить подходящие форматы представления информации для основных типов решений. Если реестр ведётся в автоматизированной системе, желательно настроить необходимые представления и отчёты так, чтобы не приходилось вручную собирать отдельные документы для каждого совещания. Это снижает трудозатраты и вероятность того, что разные участники будут использовать неодинаковые версии данных.
Как проверить, помогает ли информация о рисках принимать решения
Перечисленные требования описывают разные аспекты информации: не учтя одно из них, мы не сможем использовать информацию о рисках. Так, полная, но устаревшая информация может привести к неверной оценке ситуации. Актуальная и точная оценка не поможет, если риск описан слишком общо или не связан с целями организации. Наконец, качественная информация не принесёт пользы, если она недоступна участнику, принимающему решение.
Поэтому оценивать организацию работы с рисками стоит не только по наличию реестра, количеству зарегистрированных рисков или регулярности заполнения карточек. Важно вспомнить те самые вопросы, которые мы обсуждали в начале статьи: используются ли сведения о рисках при выборе вариантов, планировании мероприятий, распределении ресурсов и пересмотре ранее принятых решений? Может оказаться полезно взять несколько недавних управленческих решений и проследить, на сколько полно были ли рассмотрены существенные угрозы? Соответствовали ли оценки текущей ситуации? Понимали ли участники, на какие цели влияют риски? Была ли информация доступна до принятия решения и позволяла ли она сравнить альтернативы?
Ответы помогут обнаружить не только недостатки реестра, но и проблемы в организации работы: отсутствие источников данных, неясную ответственность, несогласованные критерии оценки или неудобные способы представления информации.
Ценность управления рисками определяется не количеством собранных сведений, а тем, насколько они помогают принимать обоснованные решения.
Как выстроить управление ИТ-рисками на практике
Курс Cleverics «Управление рисками в ИТ» посвящён практическим методам выявления, описания, оценки и приоритизации рисков, выбору мер реагирования и интеграции риск-менеджмента с другими практиками ИТ-организации.
Участники разбирают практические ситуации и формируют инструменты для дальнейшей работы, включая реестр ИТ-рисков, адаптированный к задачам организации.
Подробнее о программе: https://edu.cleverics.ru/it-risk-management
