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

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

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

«Принимая во внимание, что:

• Системы от поставщика 1 и поставщика 4 обладают наибольшими функциональными возможностями.

• Стоимость решения поставщика 4 дешевле решения поставщика 1 на 30 % (…млн руб. против… млн руб.), стоимость ежегодного обеспечения и сроки внедрения поставщика 1 и поставщика 4 являются приемлемыми.

• Банки, установившие системы от поставщика 1 с наибольшей вероятностью получат разрешения от ЦБ считать капитал под операционный риск самостоятельно.

• У решения от поставщика 1 отсутствуют риски прекращения обслуживания.

Рабочая группа рекомендует покупку системы поставщика 1».

Немаловажным фактором является цена, поэтому для ее снижения поставщиков необходимо постоянно держать в курсе всех снижений цены конкурентов или изменений критериев с вопросом: «Конкурент снизил цену, Вы готовы дать такую же скидку?».

7.7.3. Структурирование сделки по закупке системы.

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

Ниже приводятся некоторые из таких условий:

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

2. Истребование наилучших условий оплаты: – оплата лицензии после внедрения (trial версия на период внедрения); – оплата внедрения частями (какая то часть после внедрения); – штрафные санкции за просрочку внедрения; – фиксация размера ежегодных платежей на конкретный период; – включение работ по обслуживанию и технической поддержке в сумму лицензионных платежей.

3. Квалифицированное составление документов: – условия расторжения договора; – приоритетный язык договора; – место разрешения споров.

4. Квалифицированное оформление и подписание документов – очередность подписание договоров (сначала контрагентами, потом на своей стороне одновременно договоров внедрения и лицензии); – сшив договоров.

7.7.4. Интеграция системы.

Интеграция системы может состоять из следующих этапов:

1. Кастомизация системы (корректировка пользовательских форм, справочников).

2. Интеграция системы с данными банка (со справочниками и иными данными).

3. Настройка резервирования и механизмов восстановления системы (SLA).

4. Настройка механизмов ежедневных выгрузок в хранилище данных.

5. Настройка отчетов и средств доступа к ним.

6. Загрузка исторических данных.

7. Формирование регламента работы с системой, формирование пользовательских инструкций.

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

Этап 1. Кастомизация системы (корректировка пользовательских форм, справочников).

Кастомизация системы – это этап, на котором типовой «коробочный» продукт настраивается под индивидуальные особенности конкретного банка.

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

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

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

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

Этап 2. Интеграция системы с данными банка (со справочниками и иными данными).

Систему целесообразно интегрировать как минимум с двумя справочниками: со справочником «Сотрудники и подразделения» и со справочником «Продукты банка». Такая интеграция означает, что в случае изменений, например, в составе сотрудников банка (в кадровой системе) такие изменения автоматически произойдут и в базе операционных рисков. Если такой интеграции не делать, то на поддержание списка сотрудников в актуальном состоянии в базе рисков будет уходить очень много ручного труда.

Иногда производят интеграцию с другими справочниками, например, курсов валют, списками счетов, каталогами Active Directory (для возможности авторизации пользователей по своим учётным записям) и т. п.

Базу рисков интегрируют также с источниками данных об однотиповых множественных инцидентах (например, фактами осуществления исправительных проводок или излишками / недостачами в банкоматах).

Базу рисков интегрируют и с данными для расчета ключевых индикаторов рисков и т. д.

Этап 5. Настройка отчетов, настройка средств доступа к ним.

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

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