Термины и сокращения

RCSA — Risk and Control Self-Assessment — самооценка рисков и контролей.

KRI — Key Risk Indicator — ключевой индикатор риска.

KCI — Key Control Indicator — ключевой индикатор контроля.

ORMF — Operational Risk Management Framework — система управления операционным риском.

CRO — Chief Risk Officer — руководитель функции управления рисками.

COO — Chief Operating Officer — операционный директор.

IOR — Institute of Operational Risk — Институт операционного риска.

IRM — Institute of Risk Management — Институт управления рисками.

PRA — Prudential Regulation Authority — Управление пруденциального регулирования Великобритании.

DORA — Digital Operational Resilience Act — регламент цифровой операционной устойчивости.

IBS — Important Business Service — значимая бизнес-услуга.

ORM — Operational Risk Management — управление операционным риском.

Операционная устойчивость

[picture]

Ключевая схема по теме руководства (русская адаптация по материалам IOR/IRM).

Практическое руководство по надлежащему управлению операционным риском

Institute of Operational Risk (IOR), компания группы IRM

Русское электронное издание подготовлено по предоставленному пользователем оригиналу. Термины ORMF, RCSA, KRI/KCI и другие общепринятые сокращения сохранены там, где это помогает сопоставлять перевод с профессиональной литературой.

Предисловие

Институт операционного риска (Institute of Operational Risk, IOR) был создан в январе 2004 года, а в 2019 году вошёл в состав Institute of Risk Management. Миссия IOR — содействовать развитию управления операционным риском как профессиональной дисциплины, а также разрабатывать и распространять практики качественного управления операционными рисками.

Потребность в эффективном управлении операционным риском сегодня особенно высока. Такие события, как мировой финансовый кризис или пандемия COVID‑19, показали, насколько далеко могут распространяться последствия операционных рисков и насколько серьёзными могут быть результаты ошибок управления. Поэтому организации должны обеспечивать соответствие своих политик, процедур и процессов управления операционным риском потребностям заинтересованных сторон.

Это руководство дополняет существующие стандарты и кодексы по риск-менеджменту, например ISO 31000. Его цель — дать практические рекомендации, специально сфокусированные на операционном риске. Документ предназначен прежде всего для специалистов по управлению операционным риском, которые хотят совершенствовать практику в своих организациях. Тем, кому необходимо базовое знакомство с дисциплиной, IOR рекомендует начать с программы Certificate in Operational Risk.

Не все рекомендации одинаково применимы к каждой организации или отрасли. Материал написан с расчётом на максимально широкий круг организаций, поэтому читатель должен сам определить, какие подходы релевантны его ситуации. Главное — постепенное, но постоянное улучшение.

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

объясняют, как проектировать и внедрять надёжную и эффективную систему управления операционным риском;

показывают ценность управления операционным риском для организации;

отражают опыт практикующих риск-менеджеров, включая сложности построения и развития ORMF.

Содержание

Введение

Определения

2.1 Организационная и операционная устойчивость

2.2 Важные бизнес-сервисы

2.3 Допустимый уровень воздействия

2.4 Ответственность и корпоративное управление операционной устойчивостью

Жизненный цикл риск-менеджмента

Выявление важных бизнес-сервисов

4.1 Выявление всех бизнес-сервисов

4.2 Картирование процессов

4.3 Измерение влияния на сервис

4.4 Определение важных бизнес-сервисов

Установление допустимого уровня воздействия

Сценарии операционной устойчивости

Мониторинг и контроль операционной устойчивости

Сложности внедрения

Выводы

1. Введение

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

Исторически операционная устойчивость обеспечивалась проактивно через систему управления операционным риском (Operational Risk Management Framework, ORMF), а также через мониторинг ИТ- и киберрисков. Реактивная часть обеспечивалась процедурами реагирования на инциденты, управления непрерывностью бизнеса, кризисного управления и восстановления.

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

Принципы организационной устойчивости ISO 22316:2017 были дополнены более подробными требованиями для финансового сектора, в том числе материалами британского Prudential Regulation Authority и принципами операционной устойчивости Базельского комитета по банковскому надзору.

Пандемия COVID‑19 стала фактически масштабным «живым тестом» этих принципов. Некоторые организации создали специальные команды операционной устойчивости и отдельные системы управления. Однако позиция IOR и Базельского комитета состоит в том, что операционная устойчивость является компонентом управления операционным риском и по возможности должна опираться на уже существующие ORMF и механизмы непрерывности бизнеса.

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

2. Определения

2.1. Организационная и операционная устойчивость

ISO определяет организационную устойчивость как способность организации поглощать последствия изменений и адаптироваться в меняющейся среде. Её характеристики условно можно разделить на стратегические/культурные и операционные.

Стратегические и культурные характеристики | Операционные характеристики
Общее видение и ясность цели | Развитие и координация управленческих дисциплин
Эффективное руководство, наделённое полномочиями | Поддержка постоянного улучшения через мониторинг и оценку
Культура, поддерживающая устойчивость | Способность предвидеть изменения и управлять ими
Совместное использование информации и знаний | Достаточность ресурсов
Понимание внутренней и внешней среды для более обоснованных стратегических решений о приоритетах устойчивости | —

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

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

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

Следовательно, операционная устойчивость — это итог эффективности всех этих элементов. Управлять ею невозможно изолированно: требуется координация и единое понимание взаимосвязей.

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

2.2. Важные бизнес-сервисы

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

Финансовые регуляторы Великобритании и Европы определяют бизнес-сервис как услугу, которую организация предоставляет внешнему конечному пользователю. Ключевой момент: бизнес-сервис должен обеспечивать конкретный результат для идентифицируемого пользователя. Это не то же самое, что бизнес-направление, которое обычно объединяет множество услуг и видов деятельности.

Бизнес-сервис считается важным, если его нарушение способно:

существенно повлиять на финансовую или операционную жизнеспособность организации;

причинить значительный вред клиентам;

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

Примеры:

платёжные сервисы банка;

производственная способность промышленной компании;

процесс комплектации и выполнения заказов интернет-магазина.

2.3. Допустимый уровень воздействия (допустимый уровень воздействия)

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

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

2.4. Ответственность и корпоративное управление операционной устойчивостью

Универсальной структуры ответственности нет. Она зависит от:

размера и сложности организации;

зрелости существующей системы операционного риск-менеджмента;

зрелости управления непрерывностью и восстановлением;

степени интеграции этих механизмов.

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

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

2.4.1. Ответственность

Совет директоров

Совет директоров является конечным владельцем операционной устойчивости и должен:

активно формировать общее понимание подхода организации к операционной устойчивости;

рассматривать и утверждать ожидания в области устойчивости с учётом риск-аппетита, способности принимать риск и текущего риск-профиля;

утверждать перечень важных бизнес-сервисов, допустимые уровни воздействия и ключевые сценарии;

убеждаться, что у организации имеются подходящие стратегии, процессы и системы для выявления и управления рисками устойчивости;

конструктивно оспаривать и проверять позицию высшего руководства;

ежегодно утверждать самооценку операционной устойчивости.

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

В крупных сложных организациях глубокое участие совета не всегда практически возможно. Поэтому риск-специалисты должны как минимум фасилитировать процесс на уровне совета или высшего руководства, а решения должны опираться на операционные данные.

Высшее руководство

Высшее руководство отвечает за выполнение стратегии, утверждённой советом. Следовательно, оно должно обеспечивать работу важных бизнес-сервисов в пределах заданных допусков и готовность к корректирующим действиям при внутренних или внешних нарушениях.

Общая ответственность за операционную устойчивость обычно закрепляется за COO, CRO или аналогичной должностью. В финансовых организациях специальная команда по устойчивости может находиться в операционном блоке, однако надзор и корпоративное управление должны осуществляться через общую систему риск-менеджмента и соответствующие комитеты.

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

За устойчивость каждого важного бизнес-сервиса должен быть явно назначен старший владелец. Его управленческий уровень зависит от масштаба компании, но принцип один: владелец должен быть достаточно близок к операциям, чтобы быстро восстановить сервис, и обладать реальными полномочиями для принятия решений.

Высшее руководство, отвечающее за операционную устойчивость, должно проводить ежегодную самооценку и выносить её на утверждение совета директоров.

Руководители бизнес-подразделений

Линейные и функциональные руководители ежедневно управляют множеством операционных рисков и тем самым непосредственно влияют на устойчивость. Часть из них может быть формально назначена владельцами важных бизнес-сервисов.

Обычно бизнес-руководители не определяют общий аппетит организации к операционной устойчивости — это функция совета. Однако они могут участвовать в установлении рабочих порогов и допусков для отдельных элементов сервиса. Эти локальные пороги не должны противоречить общему аппетиту к операционному риску и устойчивости.

Функция операционного риск-менеджмента

У неё несколько взаимосвязанных ролей:

поддерживать работу совета директоров;

контролировать и направлять работу бизнес-руководителей и владельцев важных сервисов при установлении порогов допустимого воздействия;

разрабатывать и поддерживать методологию;

обеспечивать обучение;

организовывать ежегодную оценку;

осуществлять надзор и профессиональный challenge.

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

2.4.2. Корпоративное управление

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

Такая архитектура должна обеспечивать последовательность решений о распределении ресурсов на устойчивость и гарантировать, что эти решения поддерживают достижение целей организации, а не мешают ему.

IOR считает операционную устойчивость компонентом ORMF и рекомендует управлять ею внутри существующей системы операционного риск-менеджмента. Некоторые крупные организации создают отдельные команды устойчивости, независимые от операционного риска, непрерывности, управление инцидентами и IT/cyber. При выборе модели следует учитывать:

размер и сложность организации;

широту предоставляемых услуг;

зрелость проактивных механизмов — ORM, IT/cyber, change management, third-party/outsourcing risk;

зрелость реактивных механизмов — business continuity, реагирование на инцидент, disaster recovery.

3. Жизненный цикл риск-менеджмента применительно к бизнес-сервисам

Ключевые элементы операционной устойчивости и уже существующие источники, которые могут их поддерживать:

Элемент | Что требуется | На что можно опереться
Ответственность | Назначить владельцев | См. раздел 2.4.1
Идентификация сервисов | Определить бизнес-сервисы организации | Карты клиентского/продуктового пути
Картирование сервиса | Оценить важность и выявить риски при предоставлении сервиса | RCSA, карты процессов
Impact tolerance | Утвердить важные бизнес-сервисы и пределы допустимого воздействия | KRI/KCI уровня совета, IT/cyber MI, операционная управленческая информация, журнал инцидентов, риск-аппетит
Сценарии | Сформировать сценарии нарушения устойчивости, протестировать их и извлечь уроки | Business continuity, IT/cyber, управление инцидентами, recovery plans, сценарии операционного риска
Мониторинг и отчётность | Постоянно отслеживать показатели через органы корпоративного управления | Риск-аппетит совета, KRI, KCI
Обучение | Обеспечивать внутреннее обучение | Существующая программа обучения риск-менеджменту
Проверка и надзор | Периодически пересматривать систему и проводить самооценку | Внутренний аудит и другие независимое подтверждение-механизмы

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

Интеграция в существующий ORMF — RCSA, операционные риск-дашборды и другие инструменты — даёт несколько преимуществ:

не создаёт лишней сложности;

быстрее внедряется;

требует меньше времени на проведение и обновление оценок;

легче объясняется и обучается.

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

4. Выявление важных бизнес-сервисов

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

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

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

4.1. Выявление всех бизнес-сервисов

В идеальной ситуации у организации уже существует перечень оказываемых сервисов, карты процессов и сопутствующая документация. Если такой сквозной картины нет, COO и CRO должны организовать её построение.

При этом важно учитывать, что специалисты операционного риска и внутреннего аудита обладают риск-экспертизой, но именно бизнес-руководители обычно лучше всех знают реальную ежедневную работу. Совмещение этих двух типов знаний делает управление устойчивостью и эффективнее, и дешевле.

Хорошая отправная точка — анализ клиентского пути, а для производства — производственного и распределительного процесса. Дополнительные источники:

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

списки критических активов и критических поставщиков/третьих сторон, а также их оценки риска;

планы непрерывности бизнеса и восстановления.

После формирования перечня сервисов можно сделать первоначальную экспертную оценку их важности. Это позволит приоритизировать ресурсы на более детальное картирование и последующий количественный анализ.

4.2. Картирование процессов и ресурсов сервиса

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

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

В картировании должны участвовать профильные эксперты бизнеса и операций. Для каждого выявленного сервиса рекомендуется назначить владельца уровня высшего руководства, который отвечает как за сам процесс картирования, так и за дальнейшую устойчивость сервиса.

Для крупных компаний, особенно работающих в нескольких юрисдикциях и юридических лицах, это может быть значительной работой. Единого мирового стандарта картирования нет. Однако британские финансовые регуляторы требуют от организаций выявлять и документировать ресурсы, необходимые для предоставления каждого важного бизнес-сервиса, и отдельно выделять критические ресурсы.

Картирование должно быть связано с реестром рисков и выявлять внутренние и внешние взаимозависимости. Здесь особенно важна роль менеджера по операционному риску/устойчивости: у него более целостный обзор рисков, чем у коллег, сфокусированных на одном процессе или активе. Поэтому риск-функции полезно фасилитировать рабочие сессии и обеспечивать единообразие подхода.

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

Контрольный перечень по источникам операционного риска

Источник | Что учитывать
Люди | Исторически человеческий фактор часто недооценивался. COVID‑19 и массовая удалённая работа показали критическую роль людей в предоставлении сервисов. Следует оценивать уязвимости и устанавливать требования устойчивости не только к ИТ, но и к персоналу.
Процессы | Рассматривать не только сам процесс, но и входящие ресурсы: сырьё, результаты других внутренних сервисов, услуги третьих сторон.
Системы | Это не только ИТ и связь. Системой может быть производственное оборудование, банкомат и т. п. Особое внимание — взаимосвязям, аутсорсингу, облачным технологиям и защите данных.
Внешние события | Регуляторные изменения, геополитика, климатические события, финансовые и иные рынки и другие внешние факторы.

4.3. Измерение воздействия на сервис

Жёсткого требования использовать какой-либо единственный набор метрик нет. Однако показатели должны быть:

соответствующими характеру предоставляемых услуг и регуляторным требованиям;

согласованными со стратегическими целями и риск-аппетитом;

измеримыми на операционном уровне.

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

Существующие KRI организации — полезная отправная точка. При этом показатели устойчивости должны быть связаны с RCSA и деятельностью по непрерывности бизнеса. Основной принцип — меньше показателей, но более качественных и действительно полезных.

4.4. Определение важных бизнес-сервисов

После первичной оценки сервисы сравниваются между собой. Можно использовать суммарные баллы по нескольким показателям либо дать одному показателю — например вреду клиентам — повышенный вес.

Результаты количественной оценки необходимо сопоставить и валидировать экспертным мнением совета директоров или соответствующего органа управления.

Пример шкалы воздействия

Уровень | Вред клиентам | Масштаб/ёмкость | Финансовое воздействие | Регуляторное воздействие
Низкий (0) | Существенного вреда нет | затронуто менее 5% клиентов/производства | менее £1 000 | незначительное
Средний (1) | отдельные неудобства клиентам | 5–20% клиентов/производства | £1 001 – £1 млн | событие подлежит сообщению; возможен штраф без серьёзного публичного порицания
Высокий (3) | значительный вред клиентам | более 20% клиентов/производства | более £1 млн; может угрожать жизнеспособности бизнеса | вероятны значительный штраф и публичное порицание

Примеры показателей воздействия бизнес-сервиса

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

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

Финансовое воздействие. Оценивается прежде всего через потерю выручки/экономического результата, а не только через стоимость ремонта. По возможности должно быть связано с финансовыми KRI риск-аппетита.

Регуляторное/репутационное воздействие. Некоторые сервисы могут быть не самыми крупными по выручке или объёму, но критичными с точки зрения лицензии на деятельность, регулятора или репутации. Для непрерывности такие сервисы могут иметь очень высокий приоритет.

5. Установление допустимый уровень воздействия

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

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

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

Чаще всего допуск выражается во времени простоя сервиса. В финансовых организациях Великобритании это обязательная метрика. Её можно сочетать с другими показателями — числом затронутых клиентов, производственным объёмом и т. д.

Предел должен устанавливаться не позже точки, после которой нарушение становится неприемлемым из-за:

вреда потребителям или участникам рынка;

финансового ущерба организации;

угрозы лицензии или способности продолжать деятельность.

Методы калибровки порогов

анализ исторических рядов: что является нормальным, необычным и неприемлемым;

сравнение с отраслевыми/регуляторными нормативами;

сравнение между похожими внутренними сервисами, особенно если они используют общие критические ресурсы;

экспертная оценка, если статистики и бенчмарков нет.

Если применяется экспертное суждение, допущения должны быть документированы и утверждены, а сами пороги — уточняться по мере накопления данных.

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

Значительная часть этих KRI уже существует в рамках операционного риска, непрерывности бизнеса и IT/cyber; задача состоит не в создании всего заново, а в привязке уже существующих показателей к сервисной модели.

Практический пример 1: платёжный сервис

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

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

Организация делает вывод, что простой более трёх суток способен угрожать её устойчивости и причинять значительный вред клиентам. Поэтому предел должен находиться ниже этой точки. Impact tolerance устанавливается на уровне 72 часов — выше обычного регуляторного риск-аппетита, но непосредственно на трёхдневной критической границе.

Практический пример 2: производство продукта X

Организация устанавливает допустимый уровень воздействия для производственного процесса продукта X.

В среднем на складе находится 3 000 единиц готовой продукции, покрывающих спрос и будущие заказы. Существенный вред начнётся после исчерпания этого запаса. Исторически среднесуточное производство — 1 500 единиц с учётом ремонтов, среднесуточные продажи — 1 250 единиц.

Чтобы выполнять ежедневные заказы без уменьшения складского запаса, производство должно работать примерно на 80% мощности. При полной остановке запас будет исчерпан примерно за 2,5 дня.

Организация анализирует два сценария:

полная остановка производства — 0% мощности;

отказ одной из двух линий — работа на 50% мощности.

Устанавливаются следующие допуски:

2,5 дня при полной остановке;

6 дней при работе на 50% мощности.

Таким образом, допустимый уровень воздействия связывает операционную реальность, существующие запасы/резервы и точку, после которой ущерб становится неприемлемым.

6. Сценарии операционной устойчивости

Функция операционного риск-менеджмента обычно отвечает за проектирование и внедрение сценарного анализа, стресс-тестирования и обратного стресс-тестирования для операционных рисков. IOR рекомендует, чтобы та же функция отвечала и за разработку и тестирование сценариев операционной устойчивости. Если в организации существует отдельная команда устойчивости, эта работа может быть передана ей. В любом случае ответственный владелец процесса должен обеспечивать его эффективность и периодически пересматривать методологию и практику применения.

Сценарии давно используются в реактивной части устойчивости — для проверки планов непрерывности бизнеса, IT/cyber, disaster recovery и других механизмов восстановления. Формирование сценария дополнительно даёт владельцам процессов и сервисов возможность:

проверить способность организации выдерживать конкретные операционные события и заранее обсудить действия;

сформировать взгляд вперёд, а не опираться только на прошлые инциденты;

выйти за рамки повседневной работы и спокойно рассмотреть нестандартные будущие события;

обменяться знаниями и опытом между функциями;

выявить пробелы и слабости существующих контролей и улучшить контрольную среду.

6.1. Определение сценариев

Традиционные сценарии операционного риска часто ориентированы на предотвращение событий и используют KRI, KCI и RCSA для оценки риска и эффективности контролей.

Impact tolerance строится на другом допущении: нарушение уже произошло. Поэтому сценарий операционной устойчивости должен прежде всего проверять, способна ли организация отреагировать и восстановиться так, чтобы остаться в пределах установленной толерантности.

Этапы формирования сценария устойчивости похожи на обычный сценарный анализ операционного риска, но итоговые переменные отличаются. При использовании методики сценарного анализа IOR в этой задаче не требуется оценивать вероятность события — сценарий рассматривается как уже реализовавшийся.

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

Обычно значительная часть подготовительной работы уже выполнена в рамках business continuity, управление инцидентами и recovery planning. Поэтому существующие планы следует пересмотреть и использовать или расширить, а не создавать параллельные механизмы. Степень интеграции зависит от размера и сложности организации и выбранной модели корпоративного управления устойчивостью.

Пример структуры результата сценария

Переменная | Что фиксируется
Важный бизнес-сервис | Описание сервиса, для которого проводится сценарий
Impact tolerance | Утверждённый советом предел допустимого воздействия
Описание сценария | Краткий сюжет: что произошло и в каком контексте, например отказ ключевого поставщика в период рецессии или нарушение работы во время пандемии
Воздействие | Количественная оценка влияния на сервис, привязанная к метрикам допустимый уровень воздействия
Причины | События и сбои людей, процессов, систем или внешней среды, которые привели к сценарию. Несмотря на допущение, что событие уже произошло, причины важно изучать, потому что они определяют решение
Эффекты | Как нарушение влияет на сервис, людей, здоровье и безопасность, мораль сотрудников, взаимозависимые активы и другие сервисы
Реагирование | Как организация отвечает на инцидент: действия, внутренние и внешние коммуникации, взаимодействие с клиентами и при необходимости регуляторами
Восстановление | Что требуется для возвращения сервиса к приемлемому уровню; возможны ссылки на планы непрерывности, IT/cyber, реагирование на инцидент и recovery playbooks
Результат | Количественный уровень сервиса после восстановления, сопоставимый с допустимый уровень воздействия

После завершения сценария результаты следует по возможности валидировать через:

собственный опыт — организация могла не переживать весь сценарий целиком, но иметь опыт отдельных его элементов, например отказов ИТ;

внешнее сравнение с известными событиями;

обмен информацией в профессиональном сообществе.

Сценарии также должны периодически рассматриваться советом директоров и внутренним аудитом.

6.2. Тестирование сценариев

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

Возможные формы:

кабинетная/документальная оценка;

имитационное моделирование;

практическое тестирование работающих систем.

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

6.3. Использование результатов

Сценарный анализ требует ресурсов, поэтому его результаты нужно использовать максимально широко:

для корпоративного управления;

для подтверждения соответствия требованиям;

для стратегических решений;

для операционных решений;

для корректировки контролей и планов действий.

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

Высшее руководство и риск-комитет также должны получать результаты и информацию о действиях по снижению вероятности и/или воздействия связанных операционных событий.

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

потенциальных финансовых и репутационных последствиях;

влиянии на финансовое положение и бизнес-план;

значимых слабостях контролей;

ключевых корректирующих действиях.

На операционном уровне результаты сценариев могут использоваться как входные данные RCSA, особенно при оценке присущего (inherent/gross) риска. Такая оценка по определению гипотетична, так как предполагает отсутствие или неэффективность ключевых контролей; сценарии помогают сделать её более содержательной.

7. Мониторинг и контроль операционной устойчивости

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

7.1. Мониторинг на операционном уровне

Интеграция устойчивости в существующие комитеты и отчётность может выглядеть сложной, но большая часть «строительных блоков» уже существует.

KRI и KCI уже используются на уровне функций и активов. Их нужно связать с конкретными бизнес-сервисами. Карта сервиса, связанная с реестром рисков, позволяет определить, какие показатели действительно необходимо отслеживать.

IOR рекомендует включать операционную устойчивость в существующие форумы и отчётность по операционному риску, а не создавать без необходимости новую параллельную систему.

Главное правило — использовать существующую информацию и не переусложнять.

Цель мониторинга — своевременно выявлять возникающие риски, которые могут:

нарушить предоставление важного бизнес-сервиса;

привести к выходу за допустимый уровень воздействия при уже произошедшем сбое;

потребовать дополнительных мер снижения риска.

Особое внимание следует уделять:

взаимозависимостям и связанности систем и сервисов;

зависимости от третьих сторон и аутсорсинга, особенно при использовании облачных технологий;

управлению изменениями и влиянию изменений на сервисы;

внешней среде.

7.2. Мониторинг на уровне совета директоров

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

Совету следует предоставлять:

данные об операционных событиях, повлиявших на устойчивость, и действиях по восстановлению;

сведения о возникающих рисках и новых регуляторных требованиях, способных повлиять на будущую устойчивость и потребовать инвестиций;

сводные результаты сценарного анализа, особенно по событиям, способным затронуть стратегию, бизнес-план и финансовую жизнеспособность;

результаты аудитов устойчивости.

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

8. Сложности внедрения

Внедрение операционной устойчивости как управляемого результата непросто. Естественный соблазн — сначала разработать новую систему целиком, а затем «спустить» её в бизнес. На практике это часто вызывает сопротивление: сотрудники воспринимают её как ещё одну бюрократическую риск-процедуру поверх основной работы.

Поэтому важны раннее вовлечение ключевых участников, коммуникация выгод сервисного подхода и обучение.

С самого начала рекомендуется учитывать четыре принципа.

Простота

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

Чёткие роли и полномочия

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

Сотрудничество

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

Решения на основе данных

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

9. Выводы

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

Пандемия COVID‑19 и высокая скорость технологических изменений сделали очевидной необходимость управлять устойчивостью более гибко и через призму сервисов.

Единого межотраслевого стандарта внедрения пока нет. Однако IOR рекомендует рассматривать операционную устойчивость как часть ORMF, а не как ещё один изолированный «риск-силос».

Первым шагом организация должна использовать то, что у неё уже есть: существующие процессы риск-менеджмента, непрерывности, IT/cyber, реагирование на инцидент и recovery. В этих системах уже содержится большая часть информации и инструментов, необходимых для управления устойчивостью.

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

Практический смысл подхода IOR можно свести к цепочке:

важный сервис → его критические ресурсы → сценарий нарушения → допустимое воздействие → реагирование и восстановление → KRI/KCI и постоянный мониторинг → решения руководства.

Ссылки из оригинала

ISO 22316:2017, Security and resilience — Organizational resilience — Principles and attributes.

PRA, Operational Resilience Part 1.

PRA, Operational Resilience Part 1.

CP29/19, Operational resilience: Impact tolerances for important business services.

В числе релевантных требований упомянуты PRA CP30/19 по аутсорсингу и рискам третьих сторон, а также европейское регулирование цифровой операционной устойчивости DORA.

Источник: Institute of Operational Risk / Institute of Risk Management — www.theirm.org.