Интервью с руководителем службы ИТ-архитектуры прикладных систем «Лето Банка» Сергеем Чиковым

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

У нас такой ситуации не было. Когда в 2012 году на базе Бежица-Банка зарождался «Лето Банк», мы строили всю ИТ-инфраструктуру и архитектуру с нуля, т.к. у нас была лицензия на осуществление банковских операций, не обремененная пластом ИТ-систем.

Удалось полностью построить аппаратную и телекоммуникационную инфраструктуру и развернуть достаточно большую региональную федеральную сеть – 450 клиентских центров, тысячи POS-точек, где присутствуют сотрудники «Лето Банка», 350 стоек продаж в торговых центрах и большую сеть POS-точек, где нет наших сотрудников, но используется наше программное обеспечение (ПО) и есть возможность оформить кредит «Лето Банка».

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

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

Так случилось, что в определенный момент у нас появился все-таки небольшой центр компетенции именно по разработке. Там присутствуют 4 человека – это продуктовый бэк-офис.

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

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

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

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

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

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

Сейчас у нас порядка 25–30% продаж кредитных продуктов приходится на канал cross-sale. Соответственно, все процессы, связанные с cross-sale, у нас выполняет именно аналитический CRM.

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

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

К примеру, все, что касается карточного процессинга, все сервисы мы берем у компании «Мультикарта», которая тоже является членом группы ВТБ. Мы друг для друга являемся абсолютно коммерческими структурами с рыночными договорными отношениями. Информация по картам в нашем центре обработки данных (ЦОД) отсутствует как класс, она вся хранится в «облаке» у «Мультикарты».

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

Российским компаниям отказаться от решений иностранных вендоров, на базе которых построены какие-то прикладные, инфраструктурные вещи, в ближайшей перспективе не представляется возможным. Возьмем хотя бы системы управления базами данных. В мире есть несколько лидеров-производителей платформ управления базами данных – 
Oracle, Microsoft, IBM; все они принадлежат американским вендорам. 99% прикладных систем российских компаний строятся именно на этих платформах. Это касается и офисного ПО, и операционных систем – аналоги и альтернативы есть, но с точки зрения функциональности они сильно уступают лидерам.

Так что реальной замены иностранному ПО сейчас в России нет, а чтобы ее создать, требуется много времени, ресурсов и желания это делать, в первую очередь, на государственном уровне.

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

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