Характер, цели и эффективность применения в банковском бизнесе информационных технологий существенно зависят от масштабов организации. Об особенностях автоматизации в банках среднего размера рассказывает Константин Борозинец, заместитель председателя правления КБ «Агропромкредит».

Intelligent Enterprise: Все чаще российские ИТ-директора создают профессиональные сообщества. Многие из них территориальные, объединяющие ИТ-руководителей одного города или региона. Есть и отраслевые клубы CIO, но обычно их создают вендоры. В прошлом году было создано независимое сообщество ИТ-директоров финансового сектора CIOBANK Club, и вы стали его членом. Что вы планируете почерпнуть из такого общения?

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

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

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

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

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

Банки первой сотни значительное внимание уделяют построению системы управления ИТ и взаимоотношениями с бизнесом. Общепринятой здесь остается модель ITSM — управления сервисами, и в этом направлении уже достигнуты заметные успехи. Это еще одна особенность, которая объединяет нас в клубе. У банков же второй сотни обычно нет такой необходимости из‑за небольшой численности штата, да и ресурсов выполнять подобные мероприятия, как правило, не хватает. В том числе поэтому было принято решение ограничить участие в клубе первой сотней банков.

Важным стало и отраслевое объединение. За 20 лет существования российской банковской системы банки первой сотни достаточно сблизились по применяемой архитектуре приложений, есть явные лидеры среди поставщиков решений и технологий именно для банков. Это делает наши проблемы сходными, а найденные кем‑то подходы к их решению — интересными для остальных членов сообщества.

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

Какова ИТ‑стратегия вашей организации? Существует ли она как формальный документ и насколько часто меняется?

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

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

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

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

Какие принципиальные задачи своей предыдущей стратегии вы решили за прошедшие пять лет, в какой мере удалось ее реализовать?

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

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

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

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

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

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

Еще один важный проект, предусмотренный «Концепцией развития ИТ», — внедрение интеграционной платформы на основе IBM WebSphere.

Оба проекта мы реализуем с помощью внешних подрядчиков. Мы вместе с бизнесом определяем требования, вместе с подрядчиком разрабатываем техническое задание, они у себя создают решение, мы внедряем и используем его. В разработке хранилища основная часть — 80% — это ETL, она целиком отдана подрядчику. А меньшую — отчетность — мы уже разрабатываем сами. Это соответствует нашей стратегии: отчеты часто меняются, поэтому они создают для моих сотрудников постоянную загрузку.

Но ведь интеграционная платформа — это дорого? Каким образом вы расставляете приоритеты?

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

Мы проводили выбор между WebSphere, WebLogic и решением Oracle Fusion Middleware. Решение было принято в пользу WebSphere, потому что мы, когда возможно, стараемся ориентироваться на лидеров. В первой полусотне ведущих банков используется главным образом WebSphere, и отзывы о ней положительные. Нам важно было обеспечить целостность транзакций — средствами самой WebSphere или каких‑то механизмов, созданных на ее основе.

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

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

Каковы будут новые акценты, определенные требованиями нынешней ситуации?

Один из них задан извне: защита персональных данных, а другой — использование свободного ПО. Мы уже применяем его для нужд ИТ: у нас внедрены системы Help Desk — Request Tracker — и CMDB (Configuration Management Data Base), система управления конфигурациями инфраструктурного оборудования — OneCMDB. Пришла пора внедрять подобные решения и в другие подразделения. Многие банки первой сотни занимаются сегментированием клиентских рабочих мест, чтобы понять, кому можно установить свободно распространяемое офисное ПО — чаще всего Open Office, чтобы сэкономить на лицензиях Microsoft Office. Это можно определить, начав с исключений. Например, известно, что бухгалтеров нельзя лишать Excel — по многим причинам.

А вот у операционистов бэк-офиса особых проблем с Open Office быть не должно, потому что они не создают сами шаблоны документов, а пользуются готовыми. Если эти шаблоны заранее отладить, они, скорее всего, будут успешно работать с теми данными, которые в них будут загружаться. А если что‑то случится, всегда можно запустить Microsoft Word и исправить проблему. Простой миграция не будет. Один из моих знакомых директоров по ИТ банка, среднего по размеру активов, рассказывал, как сотрудникам потребовалось доработать свою основную АБС, чтобы она поддерживала Open Office. Так что иллюзий в этой области у нас нет, но тем не менее перспектива выглядит весьма привлекательной.

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

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

Какие основные проблемы сейчас стоят перед ИТ-подразделениями банков первой сотни? Проблемы, характерные для большинства, — может быть, еще никем не решенные, но уже осознанные?

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

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

Редакция благодарит CIOBANK Club за помощь в организации интервью.