Сделайте архитектуру управления риском проверяемой: что приводит к потере контроля, что может произойти после неё и какие барьеры реально прерывают пути.
За одну минуту
В центре Bow-Tie находится одно верхнее событие (top event):
- опасность: источник потенциального вреда, присутствующий в деятельности;
- угрозы: прямые пути к потере контроля;
- top event: момент потери контроля, когда восстановление ещё возможно;
- последствия: правдоподобные результаты после события;
- превентивные барьеры: стоят между угрозой и top event;
- восстановительные барьеры: стоят между top event и последствиями;
- факторы деградации: ослабляют барьер;
- контроли деградации: защищают сам барьер.
Диаграмма не становится количественной оценкой риска автоматически. Она показывает пути, допущения, владельцев и доказательства эффективности.
Какую проблему решает
В реестре риска часто есть предложение, красный балл и список «мер», но не видно, где действует каждая мера. Один слабый контроль учитывается несколько раз, обнаружение называют предотвращением, политику — барьером без механизма. Bow-Tie разделяет предотвращение потери контроля и ограничение последствий.
Когда применять
Используйте метод:
- для одной материальной опасности с несколькими угрозами и последствиями;
- когда реестр не показывает функцию контролей;
- после приоритизации FMEA;
- при расширении полномочий автоматизации или AI;
- после инцидента;
- для назначения владельцев и assurance.
Когда не применять
Не создавайте одну диаграмму на весь риск-универсум, не начинайте без ясной опасности и top event, не заменяйте обязательный инженерный анализ, не считайте процедуру эффективным барьером без проверки и не оставляйте диаграмму без мониторинга.
Для сканирования отказов используйте FMEA, для расследования случившегося — Root Cause Analysis.
Необходимые входы
- ограниченная деятельность, опасность и точное recoverable top event;
- данные инцидентов, near miss, аудита и операций;
- прямые угрозы и отдельные последствия;
- технические, человеческие и организационные контроли;
- владельцы, стандарты исполнения и свидетельства эффективности;
- требования к восстановлению, эскалации и экспертной проверке.
Пошаговый процесс
1. Определите опасность
Опишите источник потенциального вреда, а не само последствие: платёжные полномочия, чувствительные данные, автономное действие, энергия или материал.
2. Определите одно top event
Это наблюдаемый момент потери контроля до окончательного вреда. «Несанкционированная инструкция прошла в очередь согласования» полезнее, чем «случилось мошенничество».
3. Найдите прямые угрозы
Разделяйте их по механизму, а не подразделению. Не придумывайте путь ради заполнения диаграммы.
4. Опишите последствия
Разделите финансовый ущерб, вред клиенту, правовую экспозицию, простой и небезопасное состояние.
5. Разместите превентивные барьеры
Для каждой угрозы укажите механизм, стандарт и доказательство, способные остановить путь до top event.
6. Разместите восстановительные барьеры
Покажите, что после события обнаруживает, останавливает, локализует или уменьшает вред.
7. Проверьте независимость
Ищите общую зависимость от identity provider, данных, модели, оператора, питания или процедуры. Несколько зависимых блоков — не несколько слоёв защиты.
8. Добавьте деградацию
Устаревшие права, alert fatigue, пропущенное обслуживание, плохая калибровка или конфликт стимулов требуют собственных контролей.
9. Назначьте владельцев и assurance
У каждого критичного барьера — один ответственный владелец, порог, свидетельство готовности и действие при отклонении.
10. Подключите к эксплуатации
Задайте мониторинг, упражнения, обучение по инцидентам и триггеры пересмотра при изменении опасности, процесса, данных или полномочий.
Взгляд через AI и автоматизацию
AI может извлекать кандидатов на угрозы и контроли из разрешённых записей и находить пути без барьера или владельца. Он не должен придумывать эффективность, считать политику работающим барьером, скрывать общие зависимости, принимать остаточный риск или получать дополнительные полномочия для самоконтроля.
Визуальная модель
Интерактивный пример
AI-помощник формирует платёжные инструкции из писем и счетов. Человек видит только сгенерированное резюме. Опасность — доступ к данным поставщиков и полномочию подготовки платежа. Top event — инструкция, не совпадающая с авторизованными данными, попала в очередь как валидная. Угрозы: скомпрометированное письмо и изменённый счёт. Превентивные барьеры: сверка с master-data и блокировка изменения банковских реквизитов. Восстановление: независимое подтверждение, payment hold, отзыв и incident response. Human approval не независим, если показывает тот же пересказ.
Заметки фасилитатору
- Одно top event на модель.
- Спрашивайте, что контроль реально делает.
- Требуйте порог и свидетельство.
- Проверяйте общие зависимости.
- Включайте операторов, инженеров, risk и recovery owners.
Ожидаемый результат
- опасность и top event;
- пути угроз и последствий;
- превентивные и восстановительные барьеры;
- стандарты, деградация и зависимости;
- владельцы и assurance evidence;
- мониторинг, реагирование и триггеры пересмотра.
Типичные ошибки
- Последствие поставлено как top event.
- Список контролей без механизма.
- Обнаружение названо предотвращением.
- Зависимые барьеры посчитаны независимыми.
- Нет деградации.
- Диаграмма не связана с эксплуатацией.
Чек-лист качества
- Деятельность, опасность и одно top event явны.
- Угрозы прямо ведут к событию.
- Последствия следуют после него.
- Барьеры правильно расположены.
- У критичных барьеров есть механизм, стандарт, evidence и owner.
- Общие зависимости видимы.
- Деградация и её контроли записаны.
- Мониторинг и пересмотр подключены к операции.
Шаблон
| Поле | Вопрос |
|---|---|
| Опасность | Какое полезное, но потенциально вредное условие присутствует? |
| Top event | Какая наблюдаемая потеря контроля ещё обратима? |
| Угроза и prevention | Что ведёт к событию и что прерывает путь? |
| Последствие и recovery | Что может произойти и что ограничивает вред? |
| Деградация | Что ослабляет барьер и как это обнаруживается? |
| Assurance | Владелец, стандарт, evidence и действие при отклонении |
Проверка знаний
Вопрос: два барьера зависят от одного identity service. Независимы ли они?
Ответ: нет. Общая зависимость и common-mode failure должны быть видимы, после чего нужен отдельный слой или решение о восстановлении.
Связанные методы
Источники
- UK Civil Aviation Authority. “Bowtie.” https://www.caa.co.uk/safety-initiatives/working-with-industry/bowtie/ (откроется в новой вкладке)
- UK CAA. “Creating BowTies — step by step guide.” https://www.caa.co.uk/publication/download/17949 (откроется в новой вкладке)
- UK CAA. CAA Strategy for Bowtie Risk Models. https://www.caa.co.uk/publication/download/15216 (откроется в новой вкладке)
- IOGP. Bow tie diagrams in risk management. Report 544, 2016.
Профиль метода
- Основная задача: сделать один материальный сценарий риска и архитектуру контролей проверяемыми.
- Главный артефакт: threat–top-event–consequence с барьерами и деградацией.
- Граница решения: метод не принимает остаточный риск.
- Стандарт доказательности: правдоподобные пути, механизм, порог, независимость и владелец.
- Триггер пересмотра: инцидент, отказ барьера, новое полномочие, угроза или redesign процесса.