Чтение онлайн

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 настоящего пункта).

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

7.8.1. Важность аллокации и инструменты.

Аллокация инцидентов [83] (по исполнителям, подразделениям, покрывающим убытки, и иным признакам) в рамках их учета является важным моментом, обеспечивающим работоспособность всей системы управления операционным риском. Ниже приводятся примеры наиболее важных аллокаций и раскрываются причины их важности.

1. Аллокация инцидента по типу (виду) инцидентов.

Если инциденты будут аллоцироваться не на те типы инцидентов, к которым они относятся то и направляться для обработки они будут не на те маршруты и не к тем экспертам (их обработки либо вовсе не будет, либо она будет некомпетентной). В этих условиях вся работа с инцидентами будет неэффективной.

2. Аллокация инцидента по виду бизнеса.

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