Р. Бедрединов - Управление операционными рисками банка: практические рекомендации

Банк ведет соответствующую матрицу полномочий (таблицу), в которой каждая ИТ-система распределена на каждое ответственное подразделение.

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.

Менеджмент операционных рисков должен быть зрелым, системным и скоординированным. Это возможно при наличии план-графика (дорожной карты) как минимум на один год вперед. Руководитель подразделения по операционным рискам должен сформировать этот план-график и представить руководству (в рамках презентации) для его согласования и утверждения.

Желательно, чтобы такой график состоял из разделов, пунктов и подпунктов с указанием сроков (с диаграммой Ганта), ответственных, ресурсов и прочих характеристик. Есть множество программных инструментов такого планирования (например, MS Project), в т. ч. с удобной опцией «схлопывания» детализированной информации.

Такой план целесообразно представлять руководству банка в виде верхнеуровневого план-графика с диаграммой Ганта (с сохранением готовности «расхлопывать» те этапы, по которым могут возникнуть вопросы).

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

1. Первоочередные неотложные действия:– экспресс-аудит эффективности управления операционными рисками; – экспресс-аудит рисков наиболее значимых процессов и их устранение.

2. Запуск базовых механизмов управления операционными рисками (ОР):– общая отчетность для регулярной оценки ОР; – утверждение политики правления ОР.

3. Координация команды централизованного управления ОР:– Отдел координации инцидент менеджмента в подразделениях; – Отдел по выявлению и устранению рисков; – Отдел раннего предупреждения рисков.

4. Поэтапная легализация кураторов ОР в департаментах и регионах:– учет кураторов ОР;– обучение кураторов ОР; – организация рабочего взаимодействия с кураторами ОР.

5. Запуск всех компонентов управления ОР:– № 1. Эффективная работа с инцидентами. – № 2. Выявление рисков и их устранение. – № 3. Система раннего предупреждения рисков. – № 4. Обеспечение непрерывности деятельности. – № 5. Координация работы всех департаментов в управлении рисками. – № 6. Система отчетов и прогнозов, поддержание базы рисков. – № 7. Контроль соблюдения стандартов минимизации рисков.

6. Внедрение автоматизированной системы управления ОР:– проведение тендера; – формирование договора и приложений (бизнес-требований); – интеграция системы и наполнение ее справочниками; – тестирование и подписание актов; – подготовка инструкций и обучение персонала; – ступенчатый ввод в эксплуатацию (по регионам, по департаментам).

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

7.2.1.Ключевые препятствия.

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

Все согласующие делятся на три группы:

• первая группа согласовывает, читая поверхностно;

• вторая группа читает и согласовывает (если это заинтересованное подразделение, как, например, служба качества или служба внутреннего аудита);

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

Чаще всего руководители, которые не согласовывают политику, выдвигают следующие, вполне обоснованные, аргументы:

1. Эти рисковые функции являются для банка новыми, они вызывают много дополнительных операции и требуют набора новых сотрудников («давайте деньги»).

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

3. Это нереалистичные правила, они носят формальный характер и поэтому не нужны.

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

7.2.2.Способы преодоления препятствий.