НБЖ: Расскажите, пожалуйста, что представляет собой компонентно-интегрированная архитектура приложений, и как в нее вписывается кредитный конвейер.

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

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

НБЖ: В этой связи возникают два вопроса: почему это должно быть отдельное приложение и почему собственная разработка?

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

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

НБЖ: Выделите основные критерии, руководствуясь которыми можно создать по-настоящему эффективный кредитный конвейер.

В. ФОКИН: Основываясь на опыте разработки и внедрения кредитных конвейеров, можно выделить два основных критерия, которые позволят создать функциональный, гибкий и удобный в сопровождении программный продукт.

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

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

НБЖ: Что представляет собой модульная архитектура приложения?

В. ФОКИН: Данный подход состоит в том, что вся большая система разделяется на множество мелких модулей со строго определенными межмодульными интерфейсами взаимодействия. Эта архитектурная концепция позволяет решить несколько важных задач. Во-первых, уйти от глобального характера изменений, осуществляемых в процессе доработок системы. Большинство изменений локализовано рамками отдельных модулей. Во-вторых, ограничить объем тестирования, необходимого после внесения в систему доработок. Наконец, подобная архитектура позволяет устанавливать новые версии отдельных модулей системы без полной остановки ее эксплуатации.

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

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

НБЖ: У компании «Синимекс» есть опыт реализации собственного решения «кредитный конвейер» в каком-либо банке?

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

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

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

НБЖ: Как вы считаете, на какой опыт необходимо опираться банку, принимающему решение «с нуля» внедрить кредитный конвейер?

В. ФОКИН: Для начала обязательно нужно понимать те рыночные ниши, в которых работает или собирается работать банк, то есть какие конкретно кредиты он выдает сейчас и планирует выдавать в дальнейшей перспективе. Далее уже смотреть, с какими технологическими платформами на текущий момент он работает. Ведь внедрить продукт не представляет сложности, гораздо проблематичнее интегрировать его внутрь уже имеющегося «зоопарка» приложений.

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

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

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

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

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

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