Михаил Мартынов, старший вице-президент, директор по информационным технологиям банка «Открытие», рассказывает об интеграции ИТ при объединении банков.

Intelligent Enterprise: В последние годы банк «Открытие» стремительно рос и развивался, в частности, за счет присоединения других банков. Какой подход при этом применялся к объединению ИТ?

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

Если говорить о банковских приложениях и конкретно о бэк-офисе, то в случае банка «Губернский» (Свердловского губернского банка — СГБ) выбор в пользу унификации был достаточно естественным, поскольку и головной офис, и СГБ применяли АБС одного и того же разработчика — компании ЦФТ. А вот банк «Петровский» использовал собственную АБС — сложную систему со множеством модулей и богатейшим функционалом. Можно было либо сохранить ее (и тогда Объединенному банку «Открытие» пришлось бы нести расходы по поддержке двух систем), либо выполнить масштабный проект по миграции. Взвесив все плюсы и минусы, мы остановились на втором варианте.

Проект по переходу завершился буквально на днях. Что конкретно дала унификация? Во-первых, она позволила расширить спектр услуг банка. Клиенты «Петровского» — а у него обширная клиентская база в Санкт-Петербурге и Северо-Западном регионе — благодаря замене АБС получили возможность подключиться к нашему интернет-банку. Сейчас это очень востребованный сервис, и думается, многие захотят им воспользоваться. Во-вторых, модули, созданные в процессе доработки, мы будем использовать не только в «Петровском», но и в головном офисе. И разумеется, поддерживать одну систему дешевле, чем две.

Похожая ситуация сложилась и с системами дистанционного банковского обслуживания (ДБО) юридических лиц. И в головном банке, и в «Губернском» клиенты работали с системой «ДБО BS-Client» компании BSS, так что ничего менять не потребовалось. Сегодня пользователям доступны оба варианта — и «толстый», и тонкий клиент, — хотя мы, конечно же, стараемся нацелить их на работу с тонким клиентом. Для обеспечения безопасности используется электронный идентификатор Rutoken.

Банк «Петровский», в свою очередь, предлагал клиентам систему ДБО собственной разработки. Мы довольно долго обсуждали и взвешивали, как будет лучше для нас и для клиентов — оставить все в прежнем виде или унифицировать. На данный момент решение принято в пользу унификации. В течение ближайшего года или полутора лет все клиенты банка «Петровский» из числа юридических лиц будут постепенно переведены на систему BSS. Клиентская база «Петровского» огромна, поэтому переход растянется на длительный срок, и мы не хотели начинать его до того, как завершим замену АБС.

А по какому принципу происходило объединение инфраструктуры — вы централизовали ее или оставили распределенной?

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

Объединив банки, мы проанализировали не только приложения, но и инфраструктуру и приняли решение вынести критически важные приложения в распределенный ЦОД на базе двух коммерческих центров обработки данных, построение которых мы отдали на аутсорсинг. Рассматривались разные варианты размещения ЦОД — обсуждались Москва, Санкт-Петербург и Екатеринбург. В итоге мы выбрали Москву. Сейчас один ЦОД уже работает, параллельно строится второй, который также станет рабочим. В перспективе своей задачей мы считаем организацию active/active кластеров для всех критичных систем банка, а для систем средней критичности и ниже — active/passive. Таким образом, мы получим распределенную отказоустойчивую инфраструктуру, как записано у нас в BCP (Business Continuity Plan — плане обеспечения непрерывности бизнеса) и DRP (Disaster Recovery Plan — плане восстановления после аварии).

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

А где находятся специалисты по поддержке?

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

Таким образом, географически распределенная служба технической поддержки у нас построена по классической модели ITIL, то есть состоит из трех линий. Первая линия — стол регистрации заявок от конечных пользователей (Service Desk) — физически находится в Саратове, в нашем контакт-центре. Исторически эта система была создана и использовалась в СГБ. Мы перевели ее в Саратов и распространили на весь объединенный банк «Открытие». Теперь она доступна во всех отделениях по единому внутреннему телефонному номеру. В настоящее время мы учимся измерять загруженность сотрудников — как в Service desk, так и в службе управления задачами развития.

Вторая линия обеспечивает техническую поддержку на местах. Основные системы у нас, как я говорил, установлены в Москве, но это не значит, что инженеры, которые ими управляют, тоже должны находиться в столице. Для управления используется удаленный доступ, а значит, расстояние не имеет значения, важно только, чтобы оборудование и терминал связывал достаточно быстрый и надежный канал связи. Так, терминальная ферма Citrix развернута в Москве, а служба по поддержке этой системы находится в Екатеринбурге. В СГБ изначально была очень сильная команда специалистов по Citrix. Мы ее сохранили, и сейчас она поддерживает Citrix по всем отделениям. Возможно, мы увеличим ее штат, потому что работы становится больше.

Поясню работу службы на примере. Допустим, у сотрудника в Уфе возникает вопрос о неработающем приложении. Он звонит по внутреннему телефону в службу технической поддержки, при этом, возможно, вовсе не зная, что позвонил в Саратов. Оператор регистрирует его заявку, заявка в соответствии со своей категорией поступает к инженеру в Екатеринбурге, а тот, используя удаленный доступ, заходит на терминальную ферму, находящуюся в Москве, и администрирует рабочее место сотрудника. Так с помощью управляемой распределенной системы обеспечивается качественный сервис. Конечному пользователю услуги предоставляются как бы из облака. А для нас это прозрачная структура с минимальной совокупной стоимостью владения и понятными зонами ответственности: все знают, куда звонить и кто какими вопросами занимается.

Третья линия — это разработчики и системные администраторы. Группы разработчиков у нас есть в Санкт-Петербурге, Екатеринбурге, Саратове и Москве.

На каких принципах базируется взаимодействие бизнеса и ИТ?

Я приверженец классики — открытость, партнерство, проектный подход. Уверен, что это правильный путь. Мы используем стандартные системы управления ИТ — Service Desk, управление потоком задач развития, — а также регулярные еженедельные встречи с представителями бизнеса. На этих встречах мы выслушиваем бизнес и, в свою очередь, сами информируем его о своих проблемах, успехах и планах. Важно, что бизнес видит всю статистику — по работе и неисправностям банкоматов, по ошибкам в приложениях, по простоям. Мы должны показывать и плюсы, и минусы: не показав минусы, мы не сможем определить, прогрессируем мы или нет.

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

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

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

И последний вопрос — что в работе у проектного офиса, какие новые услуги обсуждаются?

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