Финансовый директор компании тщательно моделирует рыночные и кредитные риски, готовит сценарии на случай колебаний валютных курсов — при этом компания несёт регулярные, но никем систематически не отслеживаемые потери из-за операционных сбоев: ошибок при вводе данных, отказов IT-систем, случаев внутреннего мошенничества, срывов поставок. Эти потери в сумме оказываются сопоставимы с рыночными рисками, но остаются невидимыми, потому что никто не классифицировал их как единую категорию риска, требующую системного управления.
Задокументированный реальный кейс: в феврале 1995 года 233-летний британский банк Barings — финансировавший в своё время Наполеоновские войны и покупку Луизианы — рухнул за считаные дни. Причиной стал трейдер сингапурского офиса Ник Лисон, который одновременно контролировал и заключение сделок, и расчёты по ним (полное отсутствие разделения front-office и back-office функций) и скрывал убытки на секретном «счёте ошибок» 88888, отчитываясь перед Лондоном о прибыли. К моменту раскрытия убытки по нераскрытым позициям на фьючерсы Nikkei 225 составили около 827 млн фунтов — более чем вдвое больше собственного капитала банка. Официальное расследование Board of Banking Supervision Банка Англии констатировало «фактически полный провал систем управления рисками и контроля» в Barings. Именно крах Barings стал катализатором того, что операционный риск был формально выделен Базельским комитетом в отдельную категорию риска, требующую системного управления, наравне с рыночным и кредитным. Показательная деталь расследования: за месяцы до краха внутренние и внешние аудиторы Barings фиксировали недостаточное разделение обязанностей Лисона как проблему, но эти сигналы не были формализованы в систему управления операционным риском и не привели к своевременным корректирующим действиям — знание о проблеме на бумаге и реальное управление риском на практике оказались двумя разными вещами.
Операционные потери редко попадают в заголовки, но накапливаются тихо и регулярно — просто потому что их никто не считает единой категорией риска.
Происхождение и исследовательская база
Операционный риск как формальная категория систематизирован в банковском регулировании Базель II (2004) и впоследствии распространился на корпоративное управление рисками в целом — стандартная таксономия включает несколько категорий: внутреннее мошенничество, внешнее мошенничество, практики в отношении персонала, ошибки в работе с клиентами и продуктами, ущерб физическим активам, сбои бизнес-процессов и систем, ошибки исполнения и управления процессами. Каждая из семи категорий Базель II имеет собственную типичную динамику потерь: например, внутреннее мошенничество склонно давать редкие, но крупные единичные убытки (как в случае Barings), тогда как сбои бизнес-процессов чаще проявляются как множество мелких, но регулярных потерь — что напрямую подтверждает необходимость раздельной оценки по частоте и серьёзности, а не единой усреднённой метрики риска для всех категорий сразу.
Ключевые идеи и принципы
Принцип: Систематическая категоризация по типам операционного риска
Анализ явно распределяет операционные риски по стандартным категориям — люди, процессы, системы, внешние события — что позволяет увидеть, в какой категории накапливается наибольший объём потерь, и целенаправленно работать именно с ней, а не рассматривать операционные проблемы как разрозненные случайные события. На практике такая категоризация часто выявляет неожиданные закономерности — например, что подавляющая доля операционных потерь компании сосредоточена всего в одной-двух категориях (скажем, сбои ИТ-систем и ошибки в работе с клиентами), тогда как остальные категории вносят незначительный вклад, — это позволяет сфокусировать ограниченные ресурсы риск-менеджмента именно там, где они дают наибольший эффект.
Принцип: Учёт фактических инцидентов потерь (loss event database)
В отличие от чисто прогнозной оценки рисков, операционный риск-менеджмент требует систематического учёта фактически произошедших инцидентов потерь — эта база данных позволяет со временем увидеть реальные паттерны и приоритизировать усилия на основе фактических данных, а не только предположений. Помимо внутренней базы собственных инцидентов, зрелые практики риск-менеджмента используют и внешние базы данных отраслевых операционных потерь (там, где они доступны) — это особенно ценно для оценки редких, но катастрофических событий, которые конкретная организация могла ни разу не пережить сама, но которые уже случались у сопоставимых компаний отрасли.
Принцип: Оценка как частоты, так и серьёзности потерь
Операционные риски оцениваются по двум измерениям — как часто происходят инциденты определённого типа и насколько серьёзны их финансовые последствия, — поскольку редкие, но катастрофические события требуют другого подхода к управлению, чем частые, но незначительные. Практический инструмент для такой двумерной оценки — матрица «вероятность × ущерб», где каждая категория риска размещается по двум осям, а не сводится к единственному агрегированному числу; события в правом верхнем углу такой матрицы (редкие, но катастрофические) требуют принципиально иных мер защиты — например, страхования или архитектурного резервирования — чем частые мелкие сбои, которые эффективнее устраняются постепенным улучшением процессов.
Ограничения, слепые зоны и критика
Операционные риски по своей природе более разнообразны и менее предсказуемы статистически, чем рыночные или кредитные риски, — стандартные количественные модели риска, хорошо работающие для финансовых рисков, применяются к операционным рискам с существенно большей неопределённостью. Сбор полной и честной базы данных об инцидентах также требует организационной культуры, поощряющей открытое сообщение об ошибках, а не их сокрытие, — без такой культуры собранные данные систематически занижают реальный масштаб операционных потерь.
Типовые ошибки
Ошибка 1: Операционные риски не выделяются в отдельную управляемую категорию.
Инциденты операционных потерь фиксируются разрозненно в разных подразделениях без единой систематики, что не позволяет увидеть общую картину и приоритизировать усилия.
Как избежать: Внедрить единую категоризацию операционных рисков и централизованный учёт фактических инцидентов потерь. Проще всего начать с адаптации стандартных семи категорий Базель II под специфику своей отрасли, а не изобретать классификацию с нуля, — это также упрощает последующее сравнение с отраслевыми бенчмарками, если такие данные доступны.
Ошибка 2: Культура компании поощряет сокрытие ошибок вместо их фиксации.
Сотрудники избегают сообщать об операционных сбоях из страха наказания, из-за чего собранные данные систематически занижают реальный масштаб операционных потерь.
Как избежать: Формировать культуру, где сообщение об ошибке воспринимается как ценный вклад в улучшение процессов, а не повод для наказания. Конкретный практический сигнал такой культуры — руководитель публично благодарит сотрудника, сообщившего о собственной ошибке или обнаруженном системном сбое, вместо того чтобы искать виноватого; это меняет реальные стимулы сотрудников значительно быстрее, чем любая формальная политика на бумаге.
Ошибка 3: оценивают инциденты только по частоте, игнорируя серьёзность потенциальных потерь.
Приоритизация усилий строится по количеству случаев, а не по потенциальному масштабу ущерба — редкий, но катастрофический инцидент (как крах Barings, произошедший из-за единственной необнаруженной уязвимости контроля) получает меньший приоритет, чем частые, но малозначительные сбои.
Как избежать: Оценивать каждую категорию операционного риска по двум независимым измерениям — частоте и серьёзности — и приоритизировать в первую очередь риски с высокой потенциальной серьёзностью, даже если их частота исторически низкая. Именно этот принцип нарушила стандартная практика управления рисками в Barings до 1995 года — частота серьёзных инцидентов в подразделении Лисона была крайне низкой (по сути, единственный случай), что и создало ложное ощущение отсутствия проблемы вплоть до момента, когда накопленные скрытые убытки стали катастрофическими.
Ошибка 4: отсутствует разделение обязанностей (segregation of duties) между функциями, создающими и проверяющими риск.
Один и тот же сотрудник или подразделение одновременно совершает операции и контролирует их результат — как в случае Ника Лисона, совмещавшего трейдинг и расчёты, — что структурно устраняет независимую проверку и позволяет скрывать растущие потери месяцами или годами.
Как избежать: Обеспечивать организационное разделение между теми, кто совершает операции, и теми, кто их проверяет и учитывает результат, — это базовый принцип внутреннего контроля, нарушение которого напрямую привело к краху Barings.
Ошибка 5: выявленные операционные риски фиксируются, но не приводят к реальным изменениям процессов или контролей.
Компания добросовестно ведёт базу инцидентов и даже категоризирует риски по частоте и серьёзности, но на этом работа заканчивается — конкретные структурные изменения (разделение обязанностей, автоматизация проверок, изменение процедур) не внедряются, и те же категории риска продолжают из года в год давать одинаковый объём потерь.
Как избежать: для каждой приоритетной категории риска фиксировать не только факт её существования, но и конкретное структурное изменение, устраняющее или снижающее её, — и отслеживать, действительно ли объём потерь по этой категории снижается после внедрения изменения.
Главное, что нужно знать
Анализ операционных рисков систематически категоризирует и отслеживает потери от сбоев людей, процессов, систем и внешних событий — отдельную категорию от финансовых и рыночных рисков, требующую собственной систематики учёта. Ключевой инструмент — база данных фактических инцидентов потерь, позволяющая приоритизировать усилия на основе реальных данных, а не только предположений, что требует организационной культуры, поощряющей открытую фиксацию ошибок.
План внедрения
Неделя 1: внедрить единую категоризацию операционных рисков для компании.
Неделя 2: наладить централизованный сбор данных о фактических операционных инцидентах. На этом этапе важно заранее определить простую, необременительную форму фиксации инцидента — избыточно сложная процедура отчётности сама по себе становится барьером, отбивающим у сотрудников желание сообщать о проблемах.
Неделя 3: проанализировать накопленные данные по частоте и серьёзности потерь.
Неделя 4: приоритизировать управленческие усилия на категориях с наибольшим накопленным ущербом.
Далее: регулярно пополнять базу инцидентов и пересматривать приоритеты.
Как реализовать этот план с помощью фрейма «Анализ операционных рисков» в OrgDevTools
Фрейм — четыре карточки: «Категории риска» (люди, процессы, системы, внешние события), «База инцидентов» (фактические случаи операционных потерь — прямая защита от ошибки 1, поскольку требует централизованного учёта, а не разрозненной фиксации), «Частота и серьёзность» (оценка по двум измерениям для каждой категории — прямая защита от ошибки 3) и «Приоритеты» (куда направляем усилия на основе данных).
Карточка «База инцидентов» работает только при культуре открытого сообщения об ошибках (защита от ошибки 2) — без неё база останется пустой или заведомо заниженной, как показывает кейс Barings, где реальные убытки скрывались, а не фиксировались.