Банк ведет соответствующую матрицу полномочий (таблицу), в которой каждая ИТ-система распределена на каждое ответственное подразделение.
6.7.4.4. Сервисная среда обслуживания ИТ-архитектуры и технологий банка.
Банк обеспечивает сервисную среду, которая поддерживает эффективность ИТ-архитектуры и технологий банка, а также её соответствие стратегическим целям банка. Для этого назначается ответственное подразделение, которое:
• разрабатывает порядок назначения целевой ИТ-архитектуры и технологий банка, организует её определение на горизонт 5 лет (с учетом стратегических целей банка и инициатив подразделений), разрабатывает соответствующий план-график внедрения или модернизации систем и технологий с учетом планируемых изменений на горизонт 5 лет и контролирует его исполнение;
• разрабатывает порядок ввода / упразднения / сопровождения систем;
• организует сопровождение систем и их необходимые доработки;
• координирует внедрение ИТ-системы учета систем и их связей; координирует использование этой системы;
• ежемесячно готовит отчет для рассмотрения на заседании комитета по рискам о деятельности по поддержанию ИТ-архитектуры и технологий банка, а также о значимых изменениях в структуре, причинах этих изменений, ближайших планах и прогнозах;
• организует исполнение иных требований п. 6.7.4.
6.7.4.5. ИТ-архитектура банка формируется для обеспечения его продуктов и процессов банка (см. п. 6.7.2). Все изменения ИТ-архитектуры определяются продуктово-процессной структурой, планами её изменения, плановыми значениями объемов продуктов, объемов операций и должны согласовываться с подразделением, указанным в п. 6.7.2.2 на соответствие этим планам.
6.7.5. Стандарты целевой структуры нормативных документов банка
Банк выделяет следующие виды внутренних нормативных документов (ВНД):
• ВНД однократного пользования (приказы, распоряжения и другие документы текущего характера);
• ВНД многократного пользования (политики, регламенты, методики и пр.);
• бланки документов и отчетов (внутренних и внешних).
6.7.5.1. Особые условия построения структуры нормативных документов банка определяются в п. 6.7.2.1.
6.7.5.2. Сервисная среда построения структуры нормативных документов банка определяются в п. 6.7.2.2.
7. Особенности процедур управления рисками
7.1. Типовой план-график мероприятий
Менеджмент операционных рисков должен быть зрелым, системным и скоординированным. Это возможно при наличии план-графика (дорожной карты) как минимум на один год вперед. Руководитель подразделения по операционным рискам должен сформировать этот план-график и представить руководству (в рамках презентации) для его согласования и утверждения.
Желательно, чтобы такой график состоял из разделов, пунктов и подпунктов с указанием сроков (с диаграммой Ганта), ответственных, ресурсов и прочих характеристик. Есть множество программных инструментов такого планирования (например, MS Project), в т. ч. с удобной опцией «схлопывания» детализированной информации.
Такой план целесообразно представлять руководству банка в виде верхнеуровневого план-графика с диаграммой Ганта (с сохранением готовности «расхлопывать» те этапы, по которым могут возникнуть вопросы).
В качестве разделов такого графика можно предложить нижеследующие пункты.
1. Первоочередные неотложные действия:– экспресс-аудит эффективности управления операционными рисками; – экспресс-аудит рисков наиболее значимых процессов и их устранение.
2. Запуск базовых механизмов управления операционными рисками (ОР):– общая отчетность для регулярной оценки ОР; – утверждение политики правления ОР.
3. Координация команды централизованного управления ОР:– Отдел координации инцидент менеджмента в подразделениях; – Отдел по выявлению и устранению рисков; – Отдел раннего предупреждения рисков.
4. Поэтапная легализация кураторов ОР в департаментах и регионах:– учет кураторов ОР;– обучение кураторов ОР; – организация рабочего взаимодействия с кураторами ОР.
5. Запуск всех компонентов управления ОР:– № 1. Эффективная работа с инцидентами. – № 2. Выявление рисков и их устранение. – № 3. Система раннего предупреждения рисков. – № 4. Обеспечение непрерывности деятельности. – № 5. Координация работы всех департаментов в управлении рисками. – № 6. Система отчетов и прогнозов, поддержание базы рисков. – № 7. Контроль соблюдения стандартов минимизации рисков.
6. Внедрение автоматизированной системы управления ОР:– проведение тендера; – формирование договора и приложений (бизнес-требований); – интеграция системы и наполнение ее справочниками; – тестирование и подписание актов; – подготовка инструкций и обучение персонала; – ступенчатый ввод в эксплуатацию (по регионам, по департаментам).
Если какие-то действия уже осуществлены или какие-то компоненты управления операционным риском уже присутствуют, такой план будет выглядеть по-другому.
7.2. Утверждение политики
7.2.1. Ключевые препятствия.
Внедрение процедур управления операционными рисками начинается обычно с утверждения политики по операционным рискам и ключевых документов. Перед утверждением их проекты рассылаются во все подразделения для их согласования и получения замечаний. При этом возникают первые проблемы, которые при неправильном отношении могут «поставить крест» на всей деятельности по операционным рискам, не дав ей даже проявится.
Все согласующие делятся на три группы:
• первая группа согласовывает, читая поверхностно;
• вторая группа читает и согласовывает (если это заинтересованное подразделение, как, например, служба качества или служба внутреннего аудита);
• третья группа читает, видит, что на неё будет возложена реальная ответственность за риски и убытки, что появляется контроль, и не согласовывает документы.
Чаще всего руководители, которые не согласовывают политику, выдвигают следующие, вполне обоснованные, аргументы:
1. Эти рисковые функции являются для банка новыми, они вызывают много дополнительных операции и требуют набора новых сотрудников («давайте деньги»).
2. Изменения очень масштабны, требуют запуска новых процессов, закупки новых систем, осуществления большого объема работ, и их реализация в ближайшие год-два физически невозможна.
3. Это нереалистичные правила, они носят формальный характер и поэтому не нужны.
4. В проекте политики очень много деталей, их целесообразно перенести в подчиненные документы.
7.2.2. Способы преодоления препятствий.
Если согласиться с этими аргументами, то утверждение политики станет невозможным, что вызовет отказ от полноценного управления операционными рисками.
По замечаниям 1-й группы («Эти рисковые функции являются для банка новыми, они вызывают много дополнительных операций и требуют набора новых сотрудников») можно выдвинуть следующие контраргументы.
Такие сотрудники (по работе с рисками) имеются во всех департаментах банка[71], так как каждый департамент в текущем состоянии производит разбирательства с наступившими инцидентами, проводит методологические и технологические улучшения своих процессов, обеспечивает взаимозаменяемость сотрудников (в рамках непрерывности деятельности) и т. д.
Если эти субъекты департаментов не оформлены должным образом[72], то риск-менеджеры оказывают помощь этому подразделению для соответствующего их оформления[73] и обучения.
Обо всем этом говорит п. 4.1 проекта политики (если настоящие Рекомендации переименовать в политику).
По замечания 2-й группы («Изменения очень масштабны, требуют, запуска новых процессов, закупки новых систем, осуществления большого объема работ, и их реализация в ближайшие год-два физически невозможна») можно выдвинуть следующие контраргументы.
Смысл политики как раз и заключается в том, чтобы обозначить цели и задачи, а также принципы целевого состояния процесса управления операционными рисками (а не наоборот, когда текущее неудовлетворительное состояние операционных рисков определяет политику). И именно она побудит подразделения банка начать осуществлять действия по приведению своих процессов к состоянию, намеченному политикой с учетом текущих возможностей и приоритетов банка (внедрение политики будет производиться в предельно щадящем режиме путем наименьших издержек).
По замечания 3-й группы («Это не реалистичные правила, они носят формальный характер и поэтому не нужны») можно выдвинуть следующие контраргументы.
Во-первых, принципы, изложенные в политике, сформированы с учетом требований Базельского комитета и Банка России. Во-вторых, все принципы носят прикладной характер и могут использоваться как прямое руководство к действиям.
По замечания 3-й группы («Это не реалистичные правила, они носят формальный характер и поэтому не нужны») можно выдвинуть следующие контраргументы.
Во-первых, принципы, изложенные в политике, сформированы с учетом требований Базельского комитета и Банка России. Во-вторых, все принципы носят прикладной характер и могут использоваться как прямое руководство к действиям.
По замечания 4-й группы («В проекте политики очень много деталей, их целесообразно перенести в подчиненные документы») можно выдвинуть следующие контраргументы.
Во-первых, подчиненные документы типа положения, регламента, методики и т. п. охватывают только отдельные группы процессов, продуктов и подразделений. А документы в виде Кодекс (например, Кодекс корпоративной этики) или политики затрагивают все процессы и продукты, или все подразделения, или вопросы особой важности. Все положения проекта политики как раз относятся к таковым – они касаются всех процессов и всех подразделений банка (все тезисы имеют уровень политики).
Во-вторых, все положения проекта политики обозначают только требования, оставляя за непосредственными исполнителями определённую свободу выбора способов их реализации. Например, принципы работы с инцидентами (раздел 6.1) обозначают лишь основные этапы работы с инцидентами (сохраняя за исполнителями возможность индивидуального выстраивания процессов с учетом специфики их деятельности), предоставляют свободу выбора системы работы с инцидентами и т. д.
Остальные замечания снимаются ссылкой на то, что эти нормативные документы составлены во исполнение требований регулятора и обещаниями, что внедрение будет производиться в предельно щадящем режиме путем наименьших издержек.
В тех случаях, когда отдельные замечания не снимаются, формируется таблица разногласий, которая подается Председателю правления банка или на коллегиальный орган для принятия окончательного решения. При этом многое зависит от оформления этой таблицы.
Пример оптимального оформления такой таблицы представлен ниже:
Столбец № 3: «Замечания». Оставшиеся неурегулированными замечания обычно – это либо очень краткие необоснованные оценки (например: «Это все формальность»), либо очень большие и пространные. И это делается намеренно: высшее руководство обычно не вчитывается в большие объемы текстов, поэтому такие замечания целесообразно разделять на строки, а также представлять их краткий смысл.
Столбец № 4: «Краткий смысл замечаний (в интерпретации рисков)» – самый важный в таблице столбец. Обычно за многословными и витиеватыми замечаниями кроется конкретный смысл «Это не наша функция, мы не хотим брать ответственность за риски своего подразделения» и т. п.
После составления такой таблицы проект нормативного документа с приложением указанной таблицы выносится на рассмотрение высшего руководства или коллегиального органа банка, где принимается окончательное решение.
Целесообразно отметить, что при взаимодействии с подразделениями, в т. ч. при согласовании документов, надо проявлять максимальную дружелюбность, встречаться, разъяснять, показывать презентации. Важно всегда озвучивать миссию: «Наша задача говорить подразделениям об их рисках, убытках и помогать закрывать их. Мы помогаем обеспечивать безопасность бизнеса, для того чтобы он мог уверенно зарабатывать деньги»[74].
7.3. Организация мер по минимизации рисков
7.3.1. Назначение ответственных за исполнение мер по минимизации рисков.
Практически во всех случаях назначения ответственных за минимизацию рисков они говорят: «Конечно эти меры нужны, вот вы их и делайте – вы же риски», или: «Пусть это делают методологи или ИТ-специалисты, там же нужно изменение регламента или доработка ИТ-системы» и т. п. Т. е. персонал не хочет выполнять излишнюю, по их мнению, работу и брать на себя обязанности, за неисполнение которых могут наказать.
Специально для таких ситуаций предусмотрены следующие правила назначения ответственных за исполнение мер по минимизации рисков (см п. 6.2.2.3 настоящих Рекомендаций).
Повторно приведем его:
«Ответственным за организацию исполнения рекомендации всегда обозначается одно лицо (во избежание перекладывания ответственности) – соответствующий руководитель департамента в чьем процессе обнаружен риск. В тех случаях, когда для исполнения рекомендации необходимы доработки информационно технологической структуры (далее ИТ), регламентов, оборудования или его закупки, проведение различных работ (в т. ч. рекламных кампаний, коррекции процессов, продуктов, систем мотивации и т. д.), указанный руководитель организует формирование необходимых требований на такие доработки, закупки, работы (при необходимости согласовывает их с риск-менеджерами) и контролирует их реализацию. При обнаружении некачественного исполнения таких требований ответственный эскалирует эту проблему до уровня риск-менеджера и комитета по рискам.
Ответственность за организацию исполнения рекомендации возлагается на нескольких ответственных только в тех случаях, когда не может возникнуть вероятность ситуации, в которой один ответственный может переложить часть ответственности за неисполнение рекомендации на другого ответственного. Например, рекомендация о представлении отчетов по единому формату может быть возложена на неограниченное число руководителей департаментов, так как каждый из них не сможет обосновать неисполнение рекомендации тем, что другой начальник не представил своего отчета».
7.3.2. Техника учета и контроля мер по минимизации рисков.
Количество рисков, мер по их минимизации со временем многократно увеличивается. И их контроль становится возможным только с использованием соответствующих ИТ-инструментов. Простейший пример такого инструмента приведен в Приложении 5 в виде excel-файла с раскрывающимися столбцами и возможностью фильтрации рисков и мер по суммам, датам, исполнителям, значимости и т. д.
7.4. Организация непрерывности деятельности (планов ОНиВД)
7.4.1. Техника учета и контроля планов ОНиВД.
Планы непрерывности деятельности изначально достаточно объемны, а при росте их количества обновление таких планов, и их использование при возникновении чрезвычайных происшествий становится затруднительным. Пример упрощения такой работы приведен ниже в виде пояснений к excel-файлу, в котором на одном листе ведутся все планы непрерывности деятельности (см. схему 7).
Обычно для организации работы участников обеспечения непрерывности деятельности создают сетевую папку, в которой размещают планы непрерывности деятельности, акты проверок и иную документацию.
Схема 7
7.5. Принципы подсчета размера операционного риска[75]
Этот процесс условно можно разделить на три основных этапа.
Этап 1. Подготовка данных. Он охватывает:
• фильтрацию инцидентов для включения их в расчет (по сумме, дате, потенциальным, внешним потерям и т. д.);
• распределение по бизнес-линии и по категории убытка;
• распределение по сумме убытка и частоте (см. схему 8).
Этап 2. Подборка модели распределения тяжести последствий, которая наиболее точно описывает распределение фактических потерь Банка (см. схему 9)
Обычно для подборки используют следующие распределения:
1. Распределение Бурра.
2. Экспоненциальное распределение.
3. Гамма-распределение.
4. Обратное гауссовское распределение.
5. Логарифмически нормальное распределение.
6. Комбинированное логарифмически нормальное гамма-распределение.
7. Комбинированное надежное логарифмически нормальное гамма-распределение.
8. Комбинированное логарифмически нормальное обобщенное распределение Парето с хвостом.
9. Логарифмически нормальное обобщенное Парето-Хилла.
10. Комбинированное х-логарифмически нормальное обобщенное распределение Парето с хвостом.
11. Распределение Парето.
12. Обобщенное распределение Парето.
13. Распределение Вейбулла.
14. Комбинированное распределение тяжести последствий с хвостом.
Этап 3. Масштабирование модели на убытки банка, вычисление границ доверительного интервала и установление суммы потерь соответствующей 99,9 % границе (см. схему 10).
В инструменте SAS OpRisk VaR результаты такого расчета графически будут выглядеть примерно так[76] (см. схему 11).
Схема 11