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

По факту, любой IT-проект сегодня в банке в той или иной степени можно назвать интеграционным. На практике почти невозможно встретить ситуацию, когда один поставщик комплексом своих решений закрывает потребности клиента по принципу «все под ключ». Главный вопрос состоит в достижении правильного сочетания суммы бизнес-процессов, сервисов, закрываемых отдельными продуктами, и поставщиков решений. А это уже искусство и профессионализм CIO, который должен подобрать оптимальное соотношение различных продуктов так, чтобы полученная архитектура соответствовала поставленным целям бизнеса. Задача эта очень и очень сложная. Можно выбрать разную стратегию, но важно помнить одно — в подобных проектах проигрывают тогда, когда выстраиваемый банком ландшафт оказывается одновременно дорогим, но при этом негибким и неуправляемым. Правда, не меньше проигрывают и те, кто когда то сделал выбор в пользу интегрированной системы от одного поставщика, но на практике переработал эту систему под себя — иначе говоря, сделал ее настолько кастомизированной, что назвать ее чужой стало сложно. В результате и поставщик не может эффективно сопровождать подобный вариант системы, ведь фактически он не владеет тем, что в итоге получилось, и у самого банка ресурсов недостаточно, чтобы обеспечить управляемость и гибкость, так как системой в целом банк не владеет.

На мой взгляд, сегодня использование SOA-архитектуры в банках из модного тренда переходит в состояние тренда осмысленного и нацеленного на результат. Уверен, что SOA-проекты будут более эффективно работать и стоимость владения будет значительно меньше, если составляющие ее компоненты будут закрывать не по одному бизнес-процессу, а целые блоки. Например: «централизованная интегрированная АБС банка + система ДБО+ процессинг + информационно-аналитическое хранилище данных» и т.д. Иначе, к сожалению, провозглашенная ради гибкости, экономии и качества независимость рискует превратить ситуацию в прямо противоположную — с постоянными миллионными вливаниями, потерей темпа развития и эффективности работы персонала.

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

Финансовая отрасль, как и любая исторически IT-емкая отрасль, достаточно долго предпочитала обходиться собственными IT-кадрами, относя аутсорсинговые IT-услуги к высокорисковым. Можно утверждать, что сегодня мы имеем распространение скорее такого явления, как Multisourcing (выборочный аутсорсинг). В настоящее время среди видов деятельности, которые банки уже отдают на аутсорсинг, можно назвать техобслуживание компьютерной и оргтехники, поддержка и обеспечение линий связи, сети телекоммуникаций банка, техобслуживание СУБД, заказное программирование, аутстаффинг для разовых ручных работ и т.д.

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

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

Конечно, при подобной форме сотрудничества важно иметь возможность в случае необходимости отказаться от услуг компании-аутсорсера. Для этого используемая банком система как минимум должна иметь открытый код и специальный интрументарий разработки приложений. Только эти два фактора обеспечивают действительную независимость банка от компании-аутсорсера и защиту его инвестиций. Другой важный момент — это контракт, в котором должны быть оговорены критические для банка вопросы безопасности. При использовании аутсорсинга важно иметь возможность проводить все работы внешними специалистами на тестовом сервере банка (сервере разработки), где все реальные данные банка должны быть специальным образом искажены. Необходимо вести журналирование всех действий внешних специалистов (пользователей, администраторов) на уровне СУБД и при помощи специальных средств, которые должны быть предусмотрены в АБС. Все действия/настройки, произведенные специалистами компании-аутсорсера, должны проходить проверку в службе ИБ банка. Возможно также использование специальных внешних по отношению к АБС банка средств контроля. Для контроля конфигураций системного ПО возможно, например, использование Symantec ESM или Tripwire, а для контроля действий пользователей и администраторов — SpectorSoft, всего существует более десятка ГОСТов так или иначе контролирующих данные вопросы, и они должны быть учтены при разработке политики ИБ банка.

 Мнение эксперта 

Валерий Кирилов, начальник управления риск-менеджмента «ТехноСерв А/С»

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

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