Вице-президент, главный исполнительный директор информационных технологий ОАО «УРАЛСИБ» Игорь МУШАКОВ рассказал в интервью NBJ о том, как выстраивается взаимодействие в банке между ИТ- и бизнес-подразделениями, о задачах CIO банка, о своем видении плюсов и минусов использования облачных технологий и о том, почему ИТ-аутсорсинг в России остается исключительно инструментом решения локальных ИТ-задач.

NBJ: Игорь, расскажите, пожалуйста, какие ИТ-проекты реализует сейчас банк «УРАЛСИБ»?

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

NBJ: Не могли бы Вы указать, какие ИТ-решения используете для реализации всех перечисленных задач?

И. МУШАКОВ: Если говорить об автоматизации CRM для розничного и корпоративного бизнеса, то здесь мы находимся на стадии анализа и выбора решений. Что касается автоматизированной банковской системы (АБС), то в качестве целевого решения и для создания будущей архитектуры мы планируем использовать Finacle от компании Infosys. Пока у нас сохраняется несколько АБС как собственной разработки, так и созданных внешними интеграторами, в числе которых ЦФТ и БИС. Для хранилища данных мы также рассматриваем различные варианты решений, пока же в его основе лежит собственная разработка банка.

СОПРОВОЖДЕНИЕ КАК КРИТЕРИЙ ВЫБОРА

NBJ: На какие критерии Вы в первую очередь обращаете внимание при выборе решения внешнего интегратора?

И. МУШАКОВ: Здесь многое зависит от того, с какой точки зрения смотреть на то или иное решение. Если с точки зрения банкира, то система должна соответствовать требованиям бизнеса по функциональности, а с позиции ИТ-менеджера – быть хорошо масштабируемой и производительной. И что принципиально важно, не должно возникать проблем с ее поддержкой после внедрения.

NBJ: Сотрудниками банка или специалистами компании-интегратора?

И. МУШАКОВ: Это неважно. Проблемы с поддержкой могут возникнуть по разным причинам: из-за недостатка опыта работы с данной системой у сотрудников банка, из-за отсутствия должной экспертизы у компании-разработчика, из-за неких особенностей построения архитектуры, которую достаточно сложно сопровождать и поддерживать.

NBJ: А можно ли еще на стадии выбора решения понять, что с данной системой могут возникнуть те сложности, которые Вы перечислили?

И. МУШАКОВ: Конечно. Это становится ясным по поведению компании-поставщика, по тому, какую документацию она предоставляет. Чаще всего интегратор, который не собирается в дальнейшем сопровождать свое решение, сконцентрирован на продаже лицензии, а не на сервисе. Соответственно, вопросы поддержки такая компания стремится оставить на потом или «замылить». Это плохой знак, который должен насторожить потенциального покупателя.

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

И. МУШАКОВ: В принципе, так оно и есть, другой вопрос - что под сопровождением и поддержкой покупатели и продавцы решений могут подразумевать разные вещи. Например, мы собираемся приобрести конкретную разработку и задаем интегратору вполне логичный вопрос: как и какими силами будет осуществляться ее поддержка. В ответ на это слышим: у нас есть три человека в России, вам достаточно будет позвонить на горячую линию нашей компании и связаться с одним из них. Хорошо, но мы планируем, что данная система будет работать 24 часа 7 дней в неделю. И что делать, если она даст сбой в тот момент, когда сотрудники компании по объективным причинам будут отсутствовать в офисе? Ну тогда вы доплатите, отвечают нам интеграторы, и мы прикрепим к вам специалистов по принципу «в любое время суток».

Это первый и достаточно часто встречающийся вариант такого рода обсуждений. Второй вариант - компания-разработчик говорит: у нас есть проработанный SLA (service level agreement), вот команда, которая будет прикреплена к вашему банку для поддержки нашего решения. Только обычно та же команда прикреплена и к другим заказчикам. Хорошо, если проблемы у всех пользователей возникают не единовременно, а если нет...

NBJ: То приходится становиться в очередь к этой команде?

И. МУШАКОВ: Конечно. И тогда хорошо, если топ-менеджмент компании готов заниматься вашим банком, а если нет? Решать нестандартные проблемы на уровне исполнителей по моей практике - не слишком хорошая перспектива для обеспечения бесперебойного функционирования ИТ-сервисов.

NBJ: Критерии, перечисленные Вами, -масштабируемость системы, ее поддержка и сопровождение - важны для Вас с точки зрения ИТ-менеджера. Я так понимаю, у Вас есть еще одна ипостась, которая заставляет Вас обращать внимание и на другие критерии?

И. МУШАКОВ: Да. Я, как банкир, смотрю на соотношение цены и качества или, точнее, цены и функциональности. Естественно, если есть возможность получить тот же самый объем функционала при меньших расходах, то выбор очевиден. Или, например, мне предлагают отличное решение, но для его использования требуется внедрение новых технологий, хотя старые вполне эффективно работают в банке. И здесь я уже начинаю рассуждать как стратег: зачем нам две шины, или два портала от двух производителей, или еще два дублирующих друг друга решения? Создавать «зоопарк» как-то не хочется.

КАК ИЗБЕГАТЬ СИТУАЦИИ, КОГДА ИТ-СПЕЦИАЛИСТЫ НЕ СЛЫШАТ БИЗНЕС, А БИЗНЕС НЕ СЛЫШИТ ИТ?

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

И. МУШАКОВ: Есть английская «айтишная» шутка, которую мне рассказал один знакомый: «Time to market makes time to zoo-parking». В переводе она означает: чем больше вы заинтересованы в быстром выводе продуктов на рынок, тем легче вы соглашаетесь с любыми архитектурными расхождениями. Ну а коль скоро в быстром выводе продуктов заинтересованы бизнес-подразделения, то банковские ИТ-специалисты призваны быть их партнерами. Представьте себе ситуацию: вы решили совершить туристическую поездку в Мексику, прибыли в эту страну и заказали индивидуальную экскурсию по местным достопримечательностям, расположенным в диких лесах. Естественно, вам предоставят гида. Он не будет принимать за вас решения, куда пойти и что посмотреть, но он будет предостерегать вас от шагов, которые могут оказаться опасными для вашей жизни и здоровья. ИТ-менеджеры выполняют функцию такого гида. Поэтому моя задача, как CIO банка, в том, чтобы показать, какие нежелательные последствия и риски могут возникнуть из-за внедрения того или иного решения без учета специфики бизнес-процессов в нашей кредитной организации, его масштаба, вопросов сопровождения и так далее. Тем более что в банке «УРАЛСИБ» исторически ряд ИТ-функций находится внутри бизнес-подразделений. Например, процессингом и его сопровождением занимается розничный бизнес. То же самое наблюдается и по другим направлениям бизнеса. При таком раскладе необходимо управлять всем циклом так, чтобы не происходило дублирования компетенций. Это возможно только в том случае, если сквозной процесс оказания ИТ-сервисов будет централизован, при этом его этапы могут быть закреплены за различными административными подразделениями. Уверен, что будущее за матричными методами управления ИТ-функциями. Именно они позволяют одновременно настраивать бизнес-фокус и сохранять процессы стандартными и эффективными.

NBJ: Многие риски, насколько я знаю, так или иначе имеют отношение к информационной безопасности. Ваша дирекция занимается вопросами, связанными с ИБ?

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

СПАСАЕТ ЛИ ИТ-АУТСОРСИНГ ОТ КАДРОВОГО ГОЛОДА?

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

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

NBJ: И здесь на помощь приходит ИТ-аутсорсинг?

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

NBJ: Именно с HR?

И. МУШАКОВ: Да, потому что иначе вам, как ИТ-директору, придется выпол­нять функции HR-менеджера. А это уже совсем иные компетенции.

NBJ: Часто можно услышать, что ИТ-аутсорсинг способен  на большее, но в России он недостаточно развит, потому что нет практики составления, подписания и выполнения SLA. Вы согласны с этой точкой зрения?

И. МУШАКОВ: Может, я бы с ней и согласился, если бы мне указали ту страну, где ИТ-аутсорсинг хорошо развивается. При каких условиях можно положиться на ИТ-аутсорсера? Во-первых, если уверен, что внешний подрядчик не будет «выкручивать руки», во-вторых, если компания предсказуема и, в-третьих, если есть основания полагать, что в ней работает стабильная команда. С чем чаще всего приходится сталкиваться на практике? Начнем с команды: очень велик риск, что вы выберете себе одну команду специалистов, а работать вам в итоге придется с другой.

NBJ: А в SLA, насколько я понимаю, прописывается, что услуги по ИТ-аутсорсингу будет оказывать компания, а не конкретные люди - Иванов, Петров, Сидоров?

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

NBJ: Ну такое желание точно может быть нейтрализовано соответствующим пунктом в SLA.

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

NBJ: Наверное, этого можно избежать, заключив SLA с одной из крупных западных компаний.

И. МУШАКОВ: Здесь те же самые вопросы, только решаются еще дольше. Ведь компаниям нужно согласовать договоренности с их иностранным головным офисом. А там люди зачастую весьма далеки от России. Кроме этого, они практически не оказывают подобных услуг в РФ, а если и предлагают, то через своих российских партнеров. Ну а с этими партнерами возникают те самые проблемы, которые я перечислил выше.

БАЗЕЛЬ И ОБЛАЧНЫЕ ТЕХНОЛОГИИ - КТО КОГО?

NBJ: В начале нашей беседы Вы сказали, что в банке «УРАЛСИБ» есть так называемые информационные системы собственной разработки. Почему возникает необходимость в их сохранении? Они лучше адаптированы под специфику бизнес-процессов банка?

И. МУШАКОВ: Этому есть объяснение. Бизнес-процессы встроены в собственные системы. Конечно, можно волевым решением поменять собственные разработки на новые продукты внешних подрядчиков. Но когда рассматриваешь такую перспективу, то понимаешь: для того чтобы сделать это, надо полностью изменить бизнес-процессы и, что не менее важно, просчитать экономическую целесообразность таких действий.

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

И. МУШАКОВ: Знаете, хотелось бы понять, что вкладывается в данное понятие, потому что точно и исчерпывающе этого никто объяснить не может. Но чтобы не углубляться в обсуждение, давайте просто констатируем: есть так называемые частные и публичные «облака». Предположим, банк захотел купить Software as a Service(SaaS) CRM. При этом хотелось бы сначала видеть ответственного, который данную услугу продаст, чтобы знать, к кому в случае чего обращаться за помощью и на кого, если обязательства не будут исполнены, подавать иск в суд. Плюс к этому банк не имеет возможности полностью контролировать операционные риски и утечку информации. Здесь, как вы понимаете, возникают вопросы информационной безопасности, которые в случае использования «облака» практически невозможно решить.

NBJ: Но все, что Вы говорите, справедливо, если речь идет о публичном «облаке».

И. МУШАКОВ: Давайте поговорим тогда о частном «облаке». Зачем его покупать у внешнего подрядчика, если в банке есть сервис, который предлагает внутри организации в режиме терминального доступа или через обычные сетевые протоколы, можно сказать, то же самое «облако». В чем разница?

NBJ: То есть, с Вашей точки зрения, облачные технологии - это скорее удачный маркетинговый ход, чем востребованный банками сервис?

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

Ладно, когда речь идет о небанковских организациях, но в случае с банками возникает вопрос: как то или иное публичное «облако» в качестве сервиса может сочетаться с требованиями Базеля II по управлению операционными рисками? Ответ пока очевиден: никак. Банк обязан обеспечивать непрерывность своей деятельности, а как это можно сделать в условиях, когда, например, 80% операционной деятельности находится в «облаке», которое не контролируется? Даже подписанный c провайдером SLA не гарантирует снятия операционного риска. Так что пока Базель жив, публичные «облака» обречены. А Базель не только жив, но и продолжает развиваться.