Реестр рисков (Risk Register)

На стратегической сессии кто-то упоминает риск зависимости от единственного поставщика критичного компонента — все кивают, тема кажется важной, но никто не фиксирует это формально. Через год этот же риск реализуется, поставщик срывает поставки, и компания несёт серьёзные убытки — при этом на предыдущей сессии риск был явно назван, просто нигде не записан, ни за кем не закреплён и никогда больше не обсуждался.

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

Происхождение и исследовательская база

Реестр рисков — базовый инструмент управления рисками проектов и организаций. Управление рисками занимало скромное место в первом издании PMBOK Guide (1987, Project Management Institute) — лишь одна из областей знаний наравне с содержанием, сроками и стоимостью, — но к третьему изданию (2004) выросло в самостоятельную ключевую область со детально прописанным форматом реестра рисков. Международный стандарт ISO 31000 «Risk Management — Guidelines» (впервые опубликован в 2009 году, второе издание — 2018) дал универсальную рамку принципов управления рисками для организаций любой отрасли — при этом сам термин «реестр рисков» в тексте ISO 31000 не используется: стандарт требует документировать риски, а конкретный формат реестра определяют практические руководства вроде PMBOK и PRINCE2.

Самый известный документированный пример того, к чему приводит игнорирование зафиксированного риска, — катастрофа шаттла Challenger 28 января 1986 года. Инженер компании-подрядчика Morton Thiokol Роджер Боисжоли (Roger Boisjoly) ещё за 6 месяцев до катастрофы написал служебную записку, прямо предупреждая о «катастрофе высшего порядка — гибели людей», если проблема с уплотнительными кольцами (O-ring) не будет решена; накануне пуска инженеры формально рекомендовали не запускать шаттл при низкой температуре (ниже 53°F), но менеджеры Morton Thiokol под давлением NASA отменили эту рекомендацию, и старт состоялся при температуре 36°F. Социолог Diane Vaughan в книге «The Challenger Launch Decision» (1996) ввела для этого явления термин «нормализация отклонения» (normalization of deviance): поскольку прошлые полёты с аномалиями уплотнительных колец заканчивались благополучно, каждый такой случай постепенно превращал тревожное отклонение в «приемлемый» и в итоге незамечаемый риск — известный, названный, но постепенно переставший восприниматься как актуальный.

Ключевые идеи и принципы

1. Принцип: Каждый риск имеет владельца

   Риск без назначенного ответственного человека фактически остаётся ничьей проблемой — реестр требует явного закрепления владельца за каждым риском, который отвечает за мониторинг его вероятности и готовность плана реагирования. В кейсе Challenger формальный владелец решения о запуске существовал (менеджмент Morton Thiokol и NASA), но реальная ответственность за конкретный технический риск размылась между инженерами, поднявшими тревогу, и руководством, принявшим решение под давлением графика запусков.

2. Принцип: Оценка по вероятности и последствиям

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

3. Принцип: Регулярный пересмотр, а не разовая фиксация

   Реестр рисков — живой документ, требующий регулярного пересмотра: вероятность и последствия рисков меняются со временем, появляются новые риски, некоторые старые риски теряют актуальность — реестр, составленный один раз и забытый, быстро теряет практическую ценность. При каждом пересмотре стоит явно спрашивать не только «что изменилось», но и «какой риск мы обсуждаем реже, чем год назад, хотя объективных оснований снижать его приоритет нет» — именно так постепенно теряются самые опасные, но привычные риски (см. Ошибку 6).

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: риски фиксируются, но не назначается ответственный владелец.

   В реестре появляется описание риска, но колонка "владелец" остаётся пустой или указывает на отдел в целом, а не на конкретного человека, отвечающего за мониторинг. Практический тест — спросить конкретного названного человека, знает ли он, что числится владельцем именно этого риска; часто выясняется, что запись в реестре и реальная осведомлённость сотрудника — разные вещи.

   Как избежать

   Требовать назначения конкретного ответственного человека, а не отдела, для каждого риска в реестре.

2. Ошибка 2: реестр составляется один раз и больше не пересматривается.

   Документ создаётся в начале проекта или года и больше не открывается, хотя реальная ситуация с рисками успевает существенно измениться. Это частный случай более широкой проблемы нормализации отклонения (см. Ошибку 6) — риск не обязательно исчезает из документа физически, он просто перестаёт быть предметом реального внимания при пересмотрах.

   Как избежать

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

3. Ошибка 3: оценка рисков ведётся интуитивно, без явной шкалы вероятности и последствий.

   Риски ранжируются «на глаз» — какой кажется важнее, тот и в приоритете — вместо явной оценки по двум измерениям, что делает приоритизацию непрозрачной и зависимой от того, кто последний высказался на совещании. Даже простая матрица 3×3 (низкая/средняя/высокая по каждому измерению) уже значительно прозрачнее и честнее интуитивного ранжирования «на глаз».

   Как избежать

   Оценивать каждый риск по единой шкале вероятности и потенциальных последствий, а не по субъективному впечатлению.

4. Ошибка 4: риски зафиксированы и оценены, но план реагирования не описан.

   Реестр содержит описание и оценку риска, но не отвечает на вопрос «что конкретно делаем, если риск реализуется» — при наступлении события команда реагирует импровизированно, хотя риск был известен заранее. В кейсе Challenger план реагирования на конкретный сценарий «пуск при экстремально низкой температуре» существовал в виде рекомендации инженеров не запускать шаттл вовсе — но это была устная рекомендация накануне, а не заранее согласованный и обязательный протокол, поэтому её оказалось возможно отменить под давлением графика.

   Как избежать

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

5. Ошибка 5: реестр рисков существует отдельно от процесса принятия решений.

   Документ ведётся и периодически обновляется, но реальные стратегические и операционные решения принимаются без обращения к нему — реестр превращается в формальность, а не рабочий инструмент. Простая диагностика: если за последний год ни одно решение (новый поставщик, выход на рынок, крупная инвестиция) не сопровождалось явной сверкой с реестром — реестр де-факто не участвует в управлении, каким бы подробным он ни был на бумаге.

   Как избежать

   Явно сверяться с реестром рисков при принятии значимых решений — новых проектах, изменении поставщиков, выходе на новые рынки.

6. Ошибка 6: Риск, который долго не реализуется, постепенно понижается в приоритете и перестаёт восприниматься всерьёз («нормализация отклонения»).

   Каждый раз, когда зафиксированный риск не реализуется, у команды растёт неявная уверенность, что он и не реализуется — этот психологический эффект (документированный на примере катастрофы шаттла Challenger) постепенно превращает по-настоящему опасный, но пока не сработавший риск в фоновый шум реестра, из-за чего именно самые «привычные» риски регулярно оказываются наименее защищены к моменту реализации.

   Как избежать

   при регулярном пересмотре реестра явно проверять риски с долгой историей ненаступления отдельно — задавать вопрос не «изменилась ли вероятность», а «не снизили ли мы бдительность просто потому, что пока пронесло».

План внедрения

1. Неделя 1: сбор рисков

   собрать все известные риски компании через интервью с ключевыми сотрудниками.

2. Неделя 2: оценка

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

3. Неделя 3: владельцы и план реагирования

   назначить владельца и план реагирования для каждого приоритетного риска.

4. Неделя 4: регулярный цикл

   согласовать регулярный цикл пересмотра реестра рисков, включив в него отдельную проверку рисков с долгой историей ненаступления на признаки нормализации отклонения (см. Ошибку 6).

5. Далее: использование в решениях

   Далее: регулярно обновлять реестр и использовать его при значимых управленческих решениях. Реестр рисков логично дополняет реестр процессов (см. отдельную статью) — риски часто прямо привязаны к конкретным процессам компании и их критичности.

Как реализовать этот план с помощью фрейма «Реестр рисков» в OrgDevTools

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

Неделя 1 — карточка «Выявленные риски». Подсказка карточки прямо формулирует: «все зафиксированные риски с описанием» — каждый риск с прошлых обсуждений вносится сюда явным текстом (защита от вступительного сценария, когда риск был назван вслух, но нигде не записан).

Неделя 2 — карточка «Вероятность и последствия». Подсказка требует «оценку каждого риска по двум измерениям» — прямая защита от ошибки 3 (интуитивной приоритизации без явной шкалы).

Неделя 3 — карточки «Владельцы рисков» и «План реагирования». Вердикт фрейма прямо утверждает: «реестр рисков рабочий, если у каждого риска есть владелец и план реагирования» — риск без ответственного и без плана «остаётся только записью в таблице», не давая реестру остаться формальным списком (защита от ошибок 1 и 4).

Книги по теме

ISO 31000 — «Risk Management — Guidelines» (впервые 2009, актуальная редакция 2018). Международный стандарт принципов управления рисками.

Vaughan D. — «The Challenger Launch Decision» (1996). Первоисточник термина «нормализация отклонения» — детальный социологический разбор того, как известный, зафиксированный риск постепенно перестаёт восприниматься всерьёз.