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