Анализ операционных рисков (Operational Risk Analysis)

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

Задокументированный реальный кейс: в феврале 1995 года 233-летний британский банк Barings — финансировавший в своё время Наполеоновские войны и покупку Луизианы — рухнул за считаные дни. Причиной стал трейдер сингапурского офиса Ник Лисон, который одновременно контролировал и заключение сделок, и расчёты по ним (полное отсутствие разделения front-office и back-office функций) и скрывал убытки на секретном «счёте ошибок» 88888, отчитываясь перед Лондоном о прибыли. К моменту раскрытия убытки по нераскрытым позициям на фьючерсы Nikkei 225 составили около 827 млн фунтов — более чем вдвое больше собственного капитала банка. Официальное расследование Board of Banking Supervision Банка Англии констатировало «фактически полный провал систем управления рисками и контроля» в Barings. Именно крах Barings стал катализатором того, что операционный риск был формально выделен Базельским комитетом в отдельную категорию риска, требующую системного управления, наравне с рыночным и кредитным. Показательная деталь расследования: за месяцы до краха внутренние и внешние аудиторы Barings фиксировали недостаточное разделение обязанностей Лисона как проблему, но эти сигналы не были формализованы в систему управления операционным риском и не привели к своевременным корректирующим действиям — знание о проблеме на бумаге и реальное управление риском на практике оказались двумя разными вещами.

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

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

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

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

1. Принцип: Систематическая категоризация по типам операционного риска

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

2. Принцип: Учёт фактических инцидентов потерь (loss event database)

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

3. Принцип: Оценка как частоты, так и серьёзности потерь

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

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

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

Ошибка 1: Операционные риски не выделяются в отдельную управляемую категорию.

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

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

Ошибка 2: Культура компании поощряет сокрытие ошибок вместо их фиксации.

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

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

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

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

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

Ошибка 4: отсутствует разделение обязанностей (segregation of duties) между функциями, создающими и проверяющими риск.

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

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

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

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

   Как избежать

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

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

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

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

3. Неделя 3: проанализировать накопленные данные по частоте и серьёзности потерь.

4. Неделя 4: приоритизировать управленческие усилия на категориях с наибольшим накопленным ущербом.

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

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

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

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

Книги по теме

Базельский комитет по банковскому надзору — «International Convergence of Capital Measurement and Capital Standards» (Базель II, 2004). Систематизация категорий операционного риска. Документ Базель II остаётся действующей регуляторной основой для банковского сектора по всему миру и — несмотря на свою специфически банковскую природу — стал де-факто эталонной таксономией операционного риска, которую заимствуют и адаптируют компании далеко за пределами финансовой отрасли, от промышленных производителей до технологических компаний.