Автоматизированная рейтинговая системы в Газпромбанке

Дата публикации: 
22.01.2015

Газпромбанк

В феврале 2014 г. в Газпромбанке была запущена в опытную эксплуатацию автоматизированная рейтинговая система для корпоративных клиентов на платформе компании "Прогноз". Данное событие стало важной вехой в переходе банка с программного комплекса внутренней разработки на промышленное IT-решение. В статье освещен ценный опыт данного банка, что может помочь и другим банкам в реализации подобных проектов.

Перед рассмотрением самого проекта хотелось бы проанализировать причины его реализации и поставленные цели. В течение долгого времени в банке использовался программный комплекс "Внутренние рейтинги", разработанный на платформе Lotus Notes. Данное программное обеспечение было разработано и развивалось силами Департамента банковских рисков. Плюсы и минусы использования банками решений собственной разработки вместо промышленного программного обеспечения от внешних поставщиков являются предметом отдельного обсуждения, и мы не будем подробно касаться его в данной статье. В силу расширения бизнеса банка в сфере кредитования, а также по мере развития и усложнения функционала рассматриваемое программное обеспечение использовалось все большим количеством пользователей и содержало в себе все больший объем данных. По сути, эта база данных стала ключевым для блока риск-менеджмента местом хранения информации по внутренним рейтингам корпоративных клиентов банка, ставкам резервирования и категориям качества в разрезе сделок. При этом риск неспособности системы справляться с возрастающими нагрузками и объемом данных с течением времени увеличивался. Вполне естественно, что руководством блока риск-менеджмента банка было принято своевременное решение об открытии проекта по переходу на программное обеспечение промышленного типа.

С учетом вышесказанного цели проекта были сформулированы следующим образом: реализация текущего функционала in-house решения с использованием промышленного решения от внешнего подрядчика; обеспечение технического сопровождения системы со стороны IT-подразделений банка; обеспечение технической поддержки со стороны поставщика.

 

Масштаб проекта и функционал систем

 

Перед началом каждого проекта первым и закономерным шагом является планирование работ, которые должны быть выполнены в рамках реализации проекта. Именно поэтому первоочередной задачей проектной команды со стороны банка стало формирование бизнес-требований, то есть описание функционала, который должен быть воспроизведен в новой системе. Области применения рассматриваемого программного обеспечения можно охарактеризовать так:

- система используется сотрудниками бизнес-подразделений, а также сотрудниками других подразделений банка, задействованных в кредитном процессе, для присвоения внутреннего рейтинга действующим и потенциальным заемщикам банка, а также оценки их финансового положения в соответствии с внутренними документами банка и нормативными документами Банка России;

- система применяется для определения категории качества и ставки расчетного резерва согласно РПБУ по сделкам (как фактическим, так и планируемым). Результаты расчета, полученные в системе, являются входными данными, используемыми бэк-офисом для формирования фактических резервов. В рамках этого этапа в системе также осуществляется классификация обеспечения по категориям качества;

- система является источником статистических данных для комплекса SAS Credit Risk Management for Banking, который используется риск-менеджментом для расчета риск-взвешенных активов (RWA) в соответствии с требованиями Базеля II, а также для мониторинга рейтинговых моделей. К таким статистическим данным можно отнести в том числе историю рейтингов, статистику дефолтов, кредитную историю, watch-list;

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

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

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

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

 

Выбор решения

 

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

Именно поэтому основными критериями выбора поставщика стали возможности настройки системы (в т.ч. самостоятельно силами банка), масштабируемость, готовность поставщика к адаптации базового платформенного функционала под нужды заказчика. Выбор был сделан в пользу продуктов компании "Прогноз": "Кредитный риск" и "Управление кредитным портфелем". Дополнительным фактором при выборе послужили наличие наработок у поставщика и опыт успешно завершенных проектов, что стало гарантией возможности поставщика выполнить столь обширный объем работ в довольно сжатые сроки.

Еще один аргумент в пользу выбранного решения - наличие "тонкого клиента" у решения компании "Прогноз", поскольку одной из смежных задач проекта было установление возможности просмотра определенного набора данных, а именно отчетности и данных по показателям и рейтингам, из автоматизированной системы, используемой мидл-офисом. Не менее важным аспектом при выборе являлась возможность настройки в системе показателей и справочников через интерфейс. Выполнение этого условия - один из наиболее критичных факторов, поскольку количество, вес и формулы показателей могут варьироваться в случае корректировки и развития моделей и наборов данных, используемых для анализа деятельности заемщиков. Именно поэтому банку было важно получить не "черный ящик", выдающий некоторый рассчитанный результат, а "конструктор", допускающий видоизменение и развитие.

 

Основные этапы проекта

 

Для повышения эффективности проекта и покрытия необходимого функционала работы по внедрению были разделены на ключевые блоки:

- настройка рейтингового процесса;

- реализация модуля резервов.

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

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

Кроме того, в качестве отдельного этапа следует упомянуть миграцию данных из старой системы в новую. Этот этап не последний по значимости. Без этого технологического этапа пользователи могли столкнуться с "пустой" новой системой, в которой не было бы ни самих заемщиков, ни информации о них. Вариант подключения пользователей к "пустой" системе не рассматривался, поскольку к текущим задачам бизнеса добавилась бы трудоемкая задача "ручного" ввода информации из одной системы в другую, что оказало бы негативное влияние как на текущие бизнес-процессы банка, так и на восприятие новой системы пользователями. На первый взгляд задача миграции кажется несложной: перенести данные из исходной системы в новую, - но коварство такой задачи не стоит недооценивать. Структуры хранения данных Lotus Notes кардинально отличаются от структуры хранения как метаданных, используемых платформой новой системы, так и самих данных (в качестве СУБД в новой системе используется Oracle). Кроме того, не всегда тривиальной задачей является определение последовательности переноса данных. Это связано прежде всего с тем фактом, что сущности системы ссылаются друг на друга, а атрибуты ссылаются на справочники значений.

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

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

 

Дальнейшие планы

 

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

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

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

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

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

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

 

Выводы

 

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