С какими трудностями может столкнуться банк, собирающийся внедрить автоматизированную систему управления? Не важно, отвечает эта система за управление рисками или за взаимоотношения с клиентами (CRM-сис-темы). Главная трудность - низкая готовность банка к внедрению ИС. Распространенная ситуация: не готов ни персонал, ни руководство кредитной организации. Рядовые сотрудники не готовы выделять время для участия в проектной деятельности, поскольку не представляют, как это может повлиять на их непосредственную работу. Даже если руководство убедительно рассказывает про очередной этап развития компании, связанный с внедрением автоматизированной системы, сотрудники чаще всего воспринимают проект как очередной механизм усиления контроля. Чтобы не встретить сопротивление со стороны персонала, стоит выяснить, чего опасается будущий пользователь системы, какие проблемы он в настоящее время испытывает и каким образом планирует их решать.
Детальное описание всего спектра угроз, которым подвержены проекты по внедрению информационных систем, вряд ли оправданно, тем более что общая причина несоответствия результатов поставленным задачам - каким бы конкретным риском это ни было вызвано -сводится, как правило, к нарушению этапнос-ти внедрения. В качестве иллюстрации к этой распространенной ошибке приведем два примера. Московский банк (названия не указываем по очевидным причинам) находился на завершающем этапе внедрения КСУР, в задачи которой входил контроль лимитов на контрагентов. Процесс обкатки системы проходил успешно: алгоритмы расчета лимитов выверены, данные в систему введены и верифицированы. Однако начав процесс эксплуатации, риск-менеджеры заметили, что лимиты калькулируются без учета внебиржевых сделок репо.
Хорошо, что причина ошибки обнаружилась быстро. Как выяснилось, на момент старта проекта банк вообще не проводил таких сделок, и потому транзакции, отражающие репо, не были учтены ни при разработке ПО, ни при настройке системы. Пришлось сделать несколько шагов назад к началу проекта: перепрограммирование шлюза, перенастройка алгоритмов расчета лимитов, заведение дополнительных данных, тестирование алгоритмов и работы шлюза. На эти операции потребовались дополнительное время и деньги. Второго «фальстарта», к счастью, не произошло, система работает стабильно - как могла бы работать с самого начала, если бы был проработан этап сопоставления границ проекта с планами перспективного развития бизнеса банка.
Для проекта автоматизации расчетно-кассового обслуживания риск организационной неготовности вряд ли будет существенным, поскольку базовые процессы кредитной организации подробно и жестко прописаны в регламентирующих документах. Кроме того, эта сфера работы банка относится к привычной рутине: накопленный опыт огромен, а неприятные сюрпризы маловероятны. А вот процессы управления рисками, напротив, гораздо менее регламентированы, не говоря уже о том, что практика применения риск-менеджмента в российских банках невелика – это молодое и не всегда гладко развивающееся направление деятельности. Отсюда высокая вероятность рискового события, связанного именно с организационной неготовностью.
Большое значение для успеха имеют полномочия спонсора проекта и качество связей между проектной группой банка и его подразделениями. Перед тем как войти в «чужой монастырь» (отдел), риск-менеджерам следует получить соответствующие административные полномочия от высшего руководства банка, иначе работа риск-команды будет восприниматься персоналом как попытка недружественного вторжения.
Постановочные риски (риски инициации проекта)
1.1. Ошибки определения стратегии и требуемой в перспективе функциональности ПО.
1.2. Риск несоответствия функций ПО бизнес-требованиям.
1.3. Риск недооценки масштаба работ по проекту.
1.4. Ошибки определения структуры проектной команды.
Стратегические риски
2.1. Риск изменения полномочий спонсора проекта.
2.2. Риск изменения стратегии организации и утраты интереса к внедряемой функциональности за время реализации проекта.
Технологические риски
3.1. Некорректность входных данных.
3.2. Ошибки миграции данных.
3.3. Ошибки и неэффективная настройка ПО.
3.4. Несоответствие процессов организации возможностям ПО.
