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

Родился в 1961 году. В 1984-м окончил Московский авиационный институт, после чего девять лет работал в НИИ «Квант».
Карьеру на поприще финансов начинал в 1994 году в Мосуралбанке с позиции начальника отдела разработки.
С 1995-го работает в иностранных банках, сначала — заместителем начальника ИT-отдела Bank Austria AG Moscow Branch.
В 2001-м отвечал за ИТ-поддержку при слиянии Международного московского банка с банком «Австрия-Кредитанштальт» со стороны последнего. После слияния в должности заместителя начальника ИТ-отдела ММБ занимался разработкой и внедрением новых систем и бизнес-функциональности.
В начале 2003 года перешел из ИТ-отдела в управление банковских технологий ММБ и до конца 2005-го вёл проекты розничного и корпоративного бизнеса, отвечал за ИТ- и бизнес-архитектуру, был руководителем проекта по выбору новой банковской системы и возглавлял одно из направлений в проекте по её внедрению.
В конце 2005 года перешел на работу в банк «Уралсиб», где возглавил дирекцию администрирования корпоративных проектов.
В 2006-м перешел в «Райффайзенбанк-Австрия» менеджером по ИТ-направлению проекта объединения Импэксбанка и Райффайзенбанка.
С марта 2008 года является начальником управления информационных технологий ЗАО «Райффайзенбанк».
Женат, имеет дочь.

Intelligent Enterprise: Давайте начнем разговор с одной из самых сложных задач ИТ-директора — выработки и модификации ИТ-стратегии. Сегодня под ИТ-стратегией понимаются весьма разные документы — различного объема, структуры, детализации и горизонта планирования. Каков ваш взгляд на это?

Сергей Енютин: Наша ИТ-стратегия формируется на базе бизнес-стратегии, причем не только в рамках ЗАО «Райффайзенбанк», но и в рамках всей международной группы Raiffeisen. Разработка ИТ-стратегии, обновление ее статуса, актуализация являются регулярной деятельностью в группе. Текущий горизонт планирования — конец 2011 года, а пересмотр стратегии проводится каждый год.

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

В какой мере для вас обязательны стандарты и правила международной группы? И как вы поступаете, если международные стандарты расходятся с локальными?

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

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

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

Мы не собираемся из западных систем делать российские, поскольку, во-первых, чаще всего это означает превращение системы продукториентированной в бухгалтерскую, что влечёт за собой серьезные изменения на уровне ядра, влияющие на надежность и производительность. А во-вторых, мы обязаны готовить отчетность в том числе и по международным стандартам. Не хотелось бы сначала менять международный стандарт на российский в рамках проекта внедрения системы, а затем делать обратную конвертацию для получения отчетности по МСФО. Поэтому мы стараемся всю локализацию выполнять в отдельных системах, интегрируя их с основной, причем так, чтобы при внесении изменений в законодательство менять что-либо приходилось в одном, а не во многих приложениях или системах.

Но тогда увеличивается «лоскутность» вашей ИС?

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

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

Какова целевая архитектура информационной системы банка? Какие ключевые изменения в ней вы планируете провести?

При разработке архитектуры мы отталкиваемся от географической экспансии, продуктовой линейки и операционной модели, от тех объемов, которые у нас есть сейчас и которые мы намереваемся иметь в будущем, от пропускной способности систем, какая есть сейчас и какая будет нам необходима через 3 — 5 лет.

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

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

Известно, что все иностранные банки ведут проекты по соответствию требованиям «Базель II», и Райффайзенбанк не является исключением. В этом стандарте качество данных — один из краеугольных камней, и его повышение является в первую очередь бизнес-проектом. Есть такое заблуждение, что ИТ-подразделение может решить проблему качества данных самостоятельно: подготовит какие-либо отчеты, и на их основе данные будут приведены в идеальное состояние автоматически. Это далеко не так. ИТ-отдел может по определенным критериям проанализировать качество данных, может выявить поля, заполненные с нарушением стандарта, но если для повышения качества нужны дополнительные действия, такие как сопоставление значения поля с документами клиента, например, проверка паспортных данных, то средствами ИТ этого сделать нельзя.

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

Расскажите, как проходил проект объединения «Райффайзенбанк-Австрия» и Импэксбанка со стороны ИТ.

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

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

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

Этот проект еще не завершен. Мы продолжаем работу над технологической интеграцией систем и функциональности. Сейчас для нас наиболее актуальны производительность и надежность.

Причем это не чисто технологический вопрос. Чтобы их обеспечить, нам приходится менять и сами ИТ-решения.

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

Ввиду всех этих изменений вы, видимо, и организационную структуру ИТ-службы намерены менять?

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

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

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

Что же до тендеров по выбору ИТ-решений, то для этого совместно с бизнесом готовится список вопросов и требований, составляется длинный, а затем ещё и короткий список вендоров, поставляющих необходимые нам решения, формируется группа, которая будет вести тендер с точки зрения бизнес-функциональности, технологий; но переговоров по ценам все равно данная группа не ведет. Эти функции разнесены: есть специальное подразделение, профессионально занимающееся организацией и проведением тендеров. Им нужны требования, спецификации, а дальше они всё организуют самостоятельно, привлекая ИТ-специалистов только в качестве экспертов. Таким образом, в банке мы стараемся добиться непредвзятости при выборе решений и в получении максимальных скидок. И эта методика используется во всех банках группы «Райффайзен».

Какова ваша технология взаимодействия с бизнесом? Оно также цент­рализовано?

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

Зачастую очень тяжело выделить отдельных сотрудников в ИТ-отделе, которые должны заниматься, например, только розничным бизнесом. Как поделить зоны ответственности по платежам, по различным видам отчетности, по управлению рисками? Они же пронизывают и процессы, и системы всех или нескольких бизнес-подразделений. В банке довольно много областей, в которых необходима скоординированная и согласованная деятельность нескольких направлений бизнеса и нескольких ИТ-специалистов. Деление в таких случаях иногда идёт по признаку «кто инициировал проект» или по тому подразделению, чья доля в данном проекте наиболее значима.

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

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

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

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

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

Этот подход пропогандируется многими специалистами. Однако нередко ИТ-директора говорят и о серьезных проблемах…

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

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

Насколько далеко вы продвинулись в реализации сервисного подхода в ИТ?

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

Однако нельзя сказать, что на эти рельсы мы перешли по всем направлениям бизнеса и ИТ-услуг. SLA по службе ИТ-поддержки мы планируем разработать до конца этого года. Вряд ли это удастся выполнить полностью, но по наиболее критичным сервисам и по тем, где возможно четко измерить KPI, мы на эту схему перейдем. Другое направление — поддержка приложений. По ним мы тоже можем определить KPI и переходить на сервисное обслуживание. Разумеется, сначала мы сами должны эти сервисы подробно описать.

Пока процесс разработки и согласования KPI еще далек от завершения, он имеет итерационный характер. Скажем, определенные требования бизнеса мы можем обеспечить, но потребуется увеличить штатное расписание. На первый взгляд это лишь вопрос бюджета, но здесь задействованы не только ИТ- и административные службы. Даже если бизнес такие расходы одобрит, всё равно возникает вопрос, куда этих новых сотрудников разместить, когда можно будет организовать для них рабочие места. Новые сотрудники предоставляют сервис бизнес-подразделениям, но и сами являются потребителями другого типа сервисов, которые также нужно развивать. Поэтому к высоким KPI, которые можно обеспечить привлечением новых сотрудников, мы относимся очень настороженно. Здесь мы стараемся использовать более сбалансированный подход между увеличением численности ИТ-сотрудников, автоматизацией, аутсорсингом и самими значениями KPI.