Современная теория управления рисками описывает риск как вероятное будущее событие, которое может оказать влияние на цели проекта. Управление рисками, сконцентрированное на негативных событиях создает и соответствующий профессиональный имидж. Определение также включает в себя вероятные положительные события (возможности), которые также, как и отрицательные (угрозы), подлежат управлению и контролю. Управление рисками это постоянно действующий циклический процесс, поскольку состав неопределенностей и их характеристики подвержены изменениям в ходе проекта. Этот процесс является неотъемлемой частью мероприятий по управлению проектом с начала предпродажной подготовки до момента его завершения. Внедрение комплексных систем управления редко является независимым от организационных преобразований, обновлению ИТ инфраструктуры и других инициатив в организации. Поэтому имеет смысл ввести определение портфеля проектов и строить систему управления исходя из наличия иерархии целей и задач по выделенным направлениям. Иерархия целей позволяет определить, в том числе, уровень руководителя, ответственного за реализацию своей цели и таким образом максимально реализовать управленческий потенциал организации. Управление рисками на каждом уровне иерархии будет сконцентрировано на неопределенностях, влияющих на цели данного уровня.
Технология должна включать общую рисковую политику; перечень регламентов, определяющих функции бизнес-пользователей в таких процессах, как сбор информации о рисках, анализ ситуации, выработка и реализация антирисковых решений. Должен быть определен перечень рисков, оказывающих значительное влияние на результаты деятельности банка. При этом желательно учитывать не только существующие угрозы, но и те, что могут возникнуть в будущем. Например, если организация планирует открыть факторинговое направление через полгода-год, то соответствующие риски должны быть учтены уже сейчас - с тем, чтобы необходимые параметры были внесены в проект КСУР и работу не пришлось выполнять дважды.
Однако сказанное выше не означает, что вся технология риск-менеджмента должна быть сформулирована в деталях еще до начала внедрения ПО. Да это и невозможно - ин струментарий управления рисками постоянно эволюционирует. Действовать следует по принци пу «от стратегии к тактике». Для начального этапа вполне достаточно общего видения роли риск-менеджмента в текущей и перспективной деятельности банка.
С какими трудностями может столкнуться банк, собирающийся внедрить автоматизированную систему управления? Не важно, отвечает эта система за управление рисками или за взаимоотношения с клиентами (CRM-сис-темы). Главная трудность - низкая готовность банка к внедрению ИС. Распространенная ситуация: не готов ни персонал, ни руководство кредитной организации. Рядовые сотрудники не готовы выделять время для участия в проектной деятельности, поскольку не представляют, как это может повлиять на их непосредственную работу. Даже если руководство убедительно рассказывает про очередной этап развития компании, связанный с внедрением автоматизированной системы, сотрудники чаще всего воспринимают проект как очередной механизм усиления контроля. Чтобы не встретить сопротивление со стороны персонала, стоит выяснить, чего опасается будущий пользователь системы, какие проблемы он в настоящее время испытывает и каким образом планирует их решать.
Детальное описание всего спектра угроз, которым подвержены проекты по внедрению информационных систем, вряд ли оправданно, тем более что общая причина несоответствия результатов поставленным задачам - каким бы конкретным риском это ни было вызвано -сводится, как правило, к нарушению этапнос-ти внедрения. В качестве иллюстрации к этой распространенной ошибке приведем два примера. Московский банк (названия не указываем по очевидным причинам) находился на завершающем этапе внедрения КСУР, в задачи которой входил контроль лимитов на контрагентов. Процесс обкатки системы проходил успешно: алгоритмы расчета лимитов выверены, данные в систему введены и верифицированы. Однако начав процесс эксплуатации, риск-менеджеры заметили, что лимиты калькулируются без учета внебиржевых сделок репо.
Хорошо, что причина ошибки обнаружилась быстро. Как выяснилось, на момент старта проекта банк вообще не проводил таких сделок, и потому транзакции, отражающие репо, не были учтены ни при разработке ПО, ни при настройке системы. Пришлось сделать несколько шагов назад к началу проекта: перепрограммирование шлюза, перенастройка алгоритмов расчета лимитов, заведение дополнительных данных, тестирование алгоритмов и работы шлюза. На эти операции потребовались дополнительное время и деньги. Второго «фальстарта», к счастью, не произошло, система работает стабильно - как могла бы работать с самого начала, если бы был проработан этап сопоставления границ проекта с планами перспективного развития бизнеса банка.
