Один раз и надолго

Если сформулировать этот выбор на профессиональном языке, то он может прозвучать следующим образом: Single Source или Best of Breed? Single Source в данном случае — набор интегрированных систем от одного поставщика, а Best of Breed — лучшие в своей области специализированные прикладные системы. Достоинства подхода Single Source очевидны. Прежде всего, мы получаем единую интегрированную систему, в которой изначально налажены сквозные процессы. В этой системе проще достичь работы систем в режиме on-line. А такой режим сейчас очень востребован на рынке — для эффективного развития розничного бизнеса быстродействие системы имеет принципиальное значение. Например, в идеале единая система позволила бы без проблем отладить работу фронт-офисов, которые через единую «точку входа» имели бы доступ ко всей базе данных по клиентам. Дополнительные модули в таком случае органично присоединяются к АБС и «говорят» с ней на одном языке. Подобный подход — работу с одним «брэндом» — пропагандируют несколько российских компаний, в том числе и лидеры рынка, например «Диасофт» и R-Style Softlab. В «арсенале» этих компаний есть и АБС, и специализированные продуктовые модули по самым разным бизнес-направлениям банка. И как заявляет директор управления маркетинга и внешних связей компании R-Style Softlab Алексей Антонов: «Работа централизованной АБС строится на основе взаимодействия с единой базой данных в режиме реального времени, поэтому уже сама эта схема по определению может устранить многие организационные ограничения, в частности, получение упрощенного доступа к любой актуальной информации о клиенте. Несомненным достоинством централизированной АБС является возможность создания единой клиентской базы банка, за счет чего решается проблема дублирования информации и обеспечивается сопоставление сведений об операциях, проводимых клиентом в разных филиалах». С другой стороны, подобные системы всегда ставят проблему длительного внедрения и последующей окупаемости. Банк в этом случае делает выбор один раз и весьма на долгий срок, лишь по истечении которого можно будет со всей определенностью сделать вывод о том, насколько данная система отвечает требованиям конкретного банка. Более того, установка таких систем предполагает единовременное выделение по строке «автоматизация» весьма крупных сумм, трата которых в конечном итоге может быть не оправдана. Эти ограничения выливаются в то, что на практике российские разработчики не могут похвастаться большим количеством промышленных внедрений полностью развернутых информационных систем. Как следствие, такие системы не отличаются необходимой универсальностью и проработанностью. «Полновесная» же установка локализованных западных систем в российских банках невозможна в первую очередь из-за особенностей отечественного бухучета и отчетности ЦБ РФ. Таким образом, по мнению главного конструктора компании «ОТР» Дмитрия Гусева, в российских банках и на российском рынке отсутствуют промышленные системы Single Source, способные полностью удовлетворить всем потребностям автоматизации банка.

Выбор бизнес-отделов

И с этим соглашаются банковские специалисты. Как говорит заместитель главного системного архитектора Альфа-Банка Фарид Сулейманов, на практике подавляющее большинство банков использует весьма разнородные продукты различных производителей: «Готового интегрированного решения, способного единовременно покрыть все направления банковской деятельности, либо пока нет, либо его внедрение стоит столь дорого и требует столь больших организационных перестановок, к которым бизнес пока не готов. К тому же, постоянно меняющиеся функциональные требования, диктуемые логикой развития рынка банковских услуг, быстро обесценивают всякое готовое решение». С точки зрения директора по развитию бизнеса компании IBank Марины Тулеевой, имеет значение и «возраст» банка. Если банк находится в стадии становления, то он может вполне обойтись одной АБС с минимальным набором дополнительных продуктовых модулей. Для такого банка Single Source — самый оптимальный и эффективный путь. Но со временем «внешних вызовов» становится больше: увеличивается поток клиентов, происходит все большая специализация отделов банка, каждый из которых имеет собственные потребности, которые один продукт, одно решение удовлетворить не в состоянии. И тогда волей-неволей в пору зрелости банк приходит к Best of Breed. К достоинствам подхода Best of Breed можно отнести более глубокую специализированную функциональность отдельных продуктовых модулей. Именно поэтому такие решения выбирают бизнес-отделы банков. Для них важен функционал, то есть полезность, эффективность того или иного инструментария с точки зрения отдельного бизнес-направления. Вполне понятно, что лидерами в этой сфере будут разработчики, предлагающие специализированные решения. Имеет значение и то, что рынок может предложить достаточно широкий (по крайней мере, по сравнению с АБС) выбор специализированных направлений в той или иной области. Здесь банк может выбрать решение, наиболее походящее для него и с технической точки зрения. С позиции бизнеса финансовая отдача такого подхода более прозрачна и прогнозируема. И сроки внедрения подобных систем гораздо меньше. Кроме того, Best of Breed позволяет сохранить инвестиции в уже установленное и работающее ПО.

Проблемы интеграции

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

Информационные пакеты — в очередь

В качестве основного инструмента интеграции большинство банков используют системы, позволяющие налаживать обмен на уровне первичных данных, пакетов данных. Подобные интеграторы приложений чаще всего классифицируют как MiddleWare. Подобные программы на рынке предлагают разработчики хранилищ данных, которым надо бороться с разнородной и слабоструктурированной информацией и переводить ее в формат очищенных данных. Как уверяют специалисты, тиражных продуктов класса MiddleWare очень и очень мало. Такие продукты предоставляют гарантию хранения и доставки специализированных сообщений по всей системе. Чаще всего это текстовая информация. С помощью MiddleWare прописываются так называемые очереди, по которым следуют пакеты, блоки информации в общей системе. Это позволяет объединять самые разнородные системы. В результате такие системы позволяют снимать проблему взаимодействия в режиме on-line различных блоков, которые работают в рамках одного продукта, например ДБО. Основной недостаток интеграции на уровне «технического» MiddleWare, по словам Фарида Сулейманова (Альфа-Банк), состоит в том, что вся бизнес-логика интеграции в таком случае строится над этим продуктом в виде специализированных приложений и программных библиотек, которые необходимо разрабатывать и поддерживать. При интенсивном развитии по этому пути система интеграции получается непрозрачной, трудоемкой по сопровождению, снижается общая отказоустойчивость и производительность всей информационной системы. В последнее время становятся популярными интеграционные сервера. В отличие от MiddleWare они представляют собой среду, которая уже содержит инструментарий, позволяющий выдавать информацию конечному получателю в соответствии с заданными настройками. Ставка в таких системах делается на уже существующие блоки, которые объединяются в единую информационную среду и каждый новый может быть подключен к «ядру». Но установка таких систем требует не только значительных финансовых затрат, но и изменения системного подхода к построению банковского бизнеса, выведение на одно из первых мест ИТ-структуры.