Сфера финансовых услуг сильно изменилась за прошедший кризисный год и продолжает меняться. Как это отражается на банковских ИТ? Об опыте «Ренессанс Кредит» рассказывает старший вице-президент, директор по операционной деятельности и информационным технологиям банка Жанна Щенникова.
Intelligent Enterprise: Изменилась ли в результате кризиса ИТ‑стратегия банка?
Жанна Щенникова: Окончание нашей предыдущей ИТ‑стратегии совпало с серединой 2009г., и мы разработали новую не только потому, что изменились внешние условия, а поскольку нужно было писать следующую. Основные ее цели таковы: увеличение скорости вывода на рынок новых продуктов, повышение операционной эффективности, концентрация на ключевых для ИТ компетенциях, снижение общей стоимости владения ИТ‑системами.
Новая стратегия качественно отличается от предыдущей, ведь качественно изменился сам бизнес. Если раньше банк позиционировался только как кредитная организация, то теперь мы становимся универсальным ритейловым банком с полной линейкой продуктов: и кредитов, и депозитов, и комиссионных продуктов. Добавилась новая бизнес-линейка. Поэтому основное положение новой ИТ‑стратегии заключается в том, чтобы, не потеряв ни одного достижения в создании ИТ‑систем, сделанных для кредитной организации, создать новые платформы для новых направлений бизнеса.
Что вы понимаете под ключевыми компетенциями, на которых только ИТ‑служба должна концентрироваться?
Мы считаем, что ИТ в финансовом секторе — не софтверная компания, и наличие собственных программистов не является конкурентным преимуществом. Мы намерены развивать те компетенции, которые повышают конкурентоспособность банка как организации. Все сервисы, которые можно купить на рынке и которые конкурентоспособность не повышают, собираемся отдавать (и отдаем) на аутсорсинг.
Нет смысла иметь собственную первую линию поддержки пользователей. Таких предложений на рынке уже много, сервис можно купить, не раздувая собственный штат и не переплачивая. В конце 2009г. мы отдали на аутсорсинг первую линию поддержки. И, по нашим оценкам, в трехлетней перспективе такой аутсорсинг весьма выгоден.
Что есть ключевая компетенция? Безусловно, знание технологий продуктов относится к таковым и поэтому должно оставаться внутри ИТ. Но все то, что связано с развитием систем, кодированием, тестированием, нужно покупать на рынке. Это дает возможность иметь оптимальный штат и не зависеть от отдельных разработчиков. Все работы мы документируем и требуем того же от подрядчиков, поэтому сменить исполнителя можем без особых сложностей.
При работе с внешними исполнителями нужно смотреть на скорость, качество и легкость управления. На рынке труда мы конкурируем с софтверными компаниями, а зачем нам это делать, если можно не накручивать зарплаты, не придумывать сложные схемы мотивации, а просто купить у них сервис, и пусть они сами держат у себя команду?
Знаю, что те банки, которые исторически имеют в штате большие команды разработчиков для поддержки in house решений, в кризис испытывали серьезные трудности, так как вынуждены были держать много ничем не занятых людей, которых выгнать и жаль, и не хочется. Поэтому они активно предлагали рынку свои команды как сервис разработки.
Кризис нас научил тому, что ИТ должны уметь быстро «сжиматься» и быстро «расширяться», а это возможно, только если вы передаете часть сервисов на аутсорсинг. Если работать с поставщиками по схеме «Time & Materials», предусмотрев масштабирование, то значительно проще оценивать заказ бизнеса, поскольку в таком случае точно известно, сколько времени уйдет на подготовку ТЗ, когда будут предоставлены услуги программистов и тому подобное. Со своими сотрудниками такая формализация дается значительно сложней и оказывается менее предсказуемой.
В кризис у нас не разрабатывалось никаких новых продуктов, кроме депозитов. Мы занимались в основном усовершенствованием имеющихся систем. Теперь число заказов от бизнеса растет, и нужно расширяться. Но так как разработка отдана на аутсорсинг, нам больше не нужно проводить эту долгую и трудную работу: сначала увольнять людей, потом набирать, обучать. Думаю, что при правильном подходе внешняя разработка не менее гибка в управлении, чем внутренняя. Сейчас мы оставили двух разработчиков и пять тестировщиков.
Собираетесь ли вы менять сложившийся ИТ-ландшафт, и если да, то как?
В стратегии заложена оптимизация ИТ-ландшафта. У нас исторически сложился большой набор приложений, некоторые банковские продукты поддерживает несколько пакетов. Поэтому перед нами поставлена задача сделать за следующие три года архитектуру простой и легко управляемой, а также избавиться от некоторых приложений.
Принятый ранее общий архитектурный подход — сервисно ориентированный — мы будем продолжать. Но сейчас у нас два интеграционных решения: для бэк-офисных приложений и для фронт-офисных. Мы будем их объединять.
Так как шина — решение дорогое и во внедрении, и в эксплуатации, прежде всего нужно определять требования к сервисам. Если сервис нужен 24×7 в режиме онлайн, то да, скорей всего его нужно реализовывать через шину. А если он нужен один раз в сутки, то смысла нет, это получается неоправданно дорого. Это мое личное мнение. Хочется, конечно, в полном объеме пользоваться преимуществами SOA, но если это делать для каждого сервиса, то стоимость внедрения и эксплуатации «съедает» все преимущества. К интеграции нужно подходить очень выборочно. Универсальность вещь хорошая, с точки зрения ИТ — очень удобная, но иногда неоправданно дорогая. Транзакция через WebSphere — это очень дорогое удовольствие, хотя точно считать, сколько это стоит, мы еще не научились. Но чем больше вы даете нагрузку, тем существенней нужно расширять платформу, а WebSphere лучше всего действует на оборудовании IBM, не самом дешевом. Она работает с одной из самых дорогих баз — Oracle, которая лицензируется по числу занятых процессоров. Не надо забывать, что SOA могут себе позволить только компании, зарабатывающие не менее миллиона долларов в год чистой прибыли.
Еще один новый шаг был сделан при разработке новой стратегии: мы четко сформулировали, что такое бэк-офисное приложение, что такое — фронт-офисное, что такое главная книга, исходя из того уровня сервиса, который необходим по данному приложению. Речь идет и об уровне доступности, и об уровне участия приложения в критичных для бизнеса процессах. Это не новость в отрасли, но в нашем банке так было сделано впервые. И теперь, когда мы интегрируем новое приложение в нашу архитектуру или вносим в него изменения, мы сразу относим его к определенному классу, и это задает требования к нему. Если это «фронт», то оно точно должно общаться с другими приложениями через шину, и доступность у него должна быть 7×24.
Так как раньше мы развивались быстро, то не уделяли первостепенного значения системности. Были случаи, когда со стороны бизнес-подразделений возникал вопрос — почему приложение «висит»? А оказывается, оно считалось бэк-офисным, и плановое время восстановления по нему — четыре часа. Теперь, когда бизнес принимает участие в дифференциации приложений, определяет, какая доступность нужна, какой уровень сервиса, такие ситуации не возникают, нам с бизнесом намного легче понимать друг друга. Становится намного проще, в том числе и с точки зрения стоимости сервиса. Ведь при таком подходе логично спрашивать: коллеги, а вы уверены, что такая надежность и такая доступность вам действительно нужны для данного приложения, при такой стоимости реализации? Можно открыть финансовую модель и посмотреть, эффективно ли это будет.
А как вы оцениваете стоимость тех или иных решений? Учитываете ли, сколько ИТ-услуг потребило определенное подразделение?
При оценке стоимости важна прежде всего методология, а не то, какие приложения для этого используются. Не так важно, считается стоимость вручную или автоматически, важно знать, как это сделать. А если методологии нет, то никакой инструмент вам не поможет. Мы только в прошлом году развернули такую активность. У нас построение бюджета централизованное, и все ИТ-приложения в любых подразделениях включаются в наш бюджет, вне зависимости от того, кто и сколько их использует. Так же как и телеком-услуги: все они в бюджете ИТ, вне зависимости от того, внешние они или внутренние.
Надо сказать, что нашим бизнес-подразделениям очень понравилось, как мы научились экономить деньги в кризис, и они сказали: давайте мы эту практику сохраним и в дальнейшем. Но в кризис было относительно легко экономить, поскольку бизнес не развивался. Сохранить такие же темпы экономии при развивающемся бизнесе для ИТ очень сложно. И я не вижу никакого другого способа добиваться этого, кроме как выставлять бизнесу цены на услуги. Плюс обратная связь и анализ.
Скажем, при старте проекта мы предполагали, что новое приложение начнет приносить доход с определенного момента, и доход этот будет, например, миллион долларов в год. Через три месяца после запуска мы делаем предварительный анализ и информируем проектный комитет, что не то что миллиона, но и 10% от ожидаемого пока не заработали. Вопрос: что неверно? Модель оценки? Завышенные ожидания? Явно нужно корректировать ситуацию, и нужно решать, как именно.
Чаще всего бизнесу не нравится переход на сервисный подход, и внедряется он с трудом.
По-моему, банковские ИТ‑службы всегда более зрелые, чем бизнес, в том числе с точки зрения организационного построения и системности. У ИТ есть масса методик, ITIL, ITSM и другие. А бизнес — ребята творческие и не всегда системные. Разумеется, задача ИТ — в первую очередь поддерживать бизнес, но в определенном смысле ИТ может дисциплинировать его. Если бизнес говорит исключительно на языке денег, значит, и ИТ‑служба должна перейти на этот язык. Мы делаем это прозрачно: показываем, сколько человеко-часов занимает та или иная задача. Нам самим это тоже позволяет работать более эффективно, точнее учитывать загрузку, особенно на дорогих и ценных сотрудников, аналитиков.
Такой поход внедряется мягко — через встречи, постоянные коммуникации. Новые правила игры вводятся так, чтобы это не было шоком.
Первым шагом был отказ принимать задания на внесение изменений в ИТ‑системы без визы члена правления — куратора бизнес-направления. Ведь сотрудники стремятся по максимуму все автоматизировать, и в результате такой «хаотичной» автоматизации не все работает так, как бы хотелось. Но не для кого не секрет, что у руководства размеры ИТ-бюджетов могут вызывать вопросы. Поэтому когда просишь визу члена правления, то он понимает, что за любой автоматизацией стоят деньги, и начинает значительно критичней оценивать необходимость тех или иных разработок.
Я не только курирую ИТ, но и отвечаю за операционную деятельность, где велика востребованность ИТ. Здесь важно не раздувать штат, а делать его более эффективным за счет автоматизации. Как куратор направления, именно так я и поступаю: все проверяю и оцениваю необходимость внедрения разработок.
Второй шаг — мы начали фиксировать все свои затраты. Речь идет об отдельных задачах, поскольку проекты идут самостоятельным бюджетом и жестко контролируются. В мелких задачах, которых очень много, также требуется и ТЗ, и тестирование, и человеческие ресурсы. Здесь приходится бороться с общей банковской, да и, наверно, не только банковской, болезнью: пользователи склонны заказывать, например, новые отчеты, вместо того чтобы поискать среди существующих подходящий. При этом запросы разных подразделений часто дублируются.
Помимо этого, подобный контроль затрат помогает мне лично понять, чем же занимаются мои талантливые сотрудники большую часть времени. И, к моему большому удивлению, первые результаты показали, что хорошо оплачиваемые и редкие специалисты большую часть своего времени, примерно 80%, заняты поддержкой пользователей, сопровождением систем, а не их развитием, оптимизацией и изменениями, необходимыми для проектов. При этом у нас есть отдельное подразделение ИТ-операций, которое должно заниматься исключительно поддержкой пользователей.
Поэтому меры, повышающие дисциплину заказчиков, помогают и мне разгрузить людей и перенаправить их усилия на развитие систем. Это один из путей снижения ТСО, которое запланировано в рамках нашей стратегии.
Какие еще меры для снижения ТСО вы намерены реализовать?
Мы предполагаем использовать решения с открытым кодом для некритичных приложений. Что касается самих приложений, их структуры и интерфейсов, то практически все, что можно было оптимизировать, мы уже оптимизировали в прошлом году. С технологической точки зрения к той же цели ведет консолидация и виртуализация. В прошлом году мы приняли стратегическое инфраструктурное решение: уходить с хай-энд на оборудование среднего класса, поскольку по обслуживанию оборудование хай-энд все же слишком дорогое. У нас достаточно эффективные ИТ по сравнению с другими банками. Сам банк очень молодой — существует всего пять лет, а наши старшие коллеги уже все свои ошибки сделали, поэтому мы находимся в более выгодном положении. И за эти пять лет все наши хай-эндовые решения уже устарели и требуют апгрейда. Именно сейчас мы должны определить, как двигаться дальше.
Мы решили, что для снижения стоимости обслуживания необходимо переходить на серверные платформы среднего класса и применять новые технологии, в том числе виртуализацию. Тут возникают интересные ситуации, связанные с доступностью. Уже сейчас виртуализация части приложений позволила нам поднять их доступность до 99,99%, что раньше было совершенно нереально.
Еще один важный шаг сделан в сторону снижения ТСО и оптимизации процессов. В нем никакого открытия нет, но для нашего банка он был новым: я имею в виду стандартизацию оборудования. Раньше закупки велись не системно. Мы эту практику изменили и внедрили централизованный подход. Кроме того, сейчас очень подходящий момент переходить на «тонкий клиент». В нашем бизнесе это очень удобно, так как мы используем интернет‑каналы, вся обработка информации из регионов происходит в центре, и все основные системы централизованы. В нашей модели бизнеса «тонкий клиент» — это та технология, от которой мы получаем реальную выгоду. Уже идет опытная эксплуатация таких устройств на некоторых рабочих местах контакт-центра. У нас, как у ритейлового банка, многие операции по продаже и поддержке услуг идут по телефону. В такой структуре тонкие клиенты дают весьма значительный результат с точки зрения стоимости услуг. Кроме этого, по истечении пяти лет нужно обновлять парк рабочих станций. И вместо того чтобы делать апгрейды, выгодней старый парк заменить новыми устройствами.
Какие изменения вы считаете наиболее принципиальными, существенными в применении ИТ в банках?
Хотим мы того или нет, но кризис заставил нас работать по‑новому. Старые методы продаж, как и прежние методы повышения эффективности в ИТ, больше не работают, и нужны новые.
Имеются в виду не инновационные, никогда не существовавшие, а новые для данной организации. Возможно, это подходы, которые другие применяют давно, но мы еще ни разу не использовали. Когда я провожу совещания со своими менеджерами, я им постоянно говорю: коллеги, мы должны научиться думать на другом уровне, иначе нам не добиться нужной эффективности. Время сверхмаржи для банков закончилось, и если мы вместе с бизнесом не научимся считать деньги и выбирать оптимальные решения, мы проиграем эту игру. ИТ‑сотрудники должны ясно понимать свою ответственность за конечный результат.
А для ИТ жить по‑новому — это в первую очередь менять менталитет. Не бизнес для ИТ, а ИТ для бизнеса. Для многих это, может быть, давно уже известная истина, но не для нас. Как бы было хорошо, если бы мед был, а пчел не было! Это прелестную поговорку по‑прежнему лелеют в душе многие айтишники, имея в виду под медом — интересные задачи, удовлетворенность их решением и компенсацию за это, а под пчелами — пользователей, которые ставят эти задачи. Именно этот подход необходимо менять.
Что еще можно сделать, чтобы снизить TCO и поднять эффективность?
Дмитрий Яковлев,
руководитель направления автоматизированных банковских систем компании КРОКСегодня в числе задач каждого банка — сокращение затрат, повышение эффективности ИТ‑службы, предложение инструментов для бизнеса. При этом современная ИТ‑служба должна оперативно реагировать на все изменения. Благодаря кризису многие компании стали внимательнее относиться к затратам и поняли, что экономить можно, применяя современные технологии. Например, виртуализация, сжатие трафика, аутсорсинг, использование свободного ПО. Наведение порядка нужно для повышения эффективности: сокращение количества систем, внедрение систем интеграции с использованием принципов SOA, стандартизация оборудования, переход на «тонкие клиенты».
Однако сокращение затрат не гарантирует одновременного роста эффективности. Не секрет, что многие банки до сих пор «незнакомы» со своими клиентами, единицы могут сделать оптимальное предложение, оценить эффект от маркетинговой компании. Это недостаточная эффективность маркетинга и продаж. А операционисты, общаясь с клиентами, вынуждены работать одновременно в нескольких системах — это существенные операционные расходы. Изменить ситуацию в лучшую сторону могут ИТ. Например, существуют специализированные инструменты для создания единого профиля клиента, системы клиентской аналитики для проведения целевого маркетинга, сегментации клиентской базы, построения прогнозных моделей. Последние позволяют прогнозировать вероятность отклика клиентов на то или иное продуктовое предложение, оценить чувствительность клиентов к параметрам продуктов, склонность к взаимодействию с банком по различным каналам коммуникации. Мы ведем несколько подобных проектов.
Существенно повысить эффективность позволяют системы для автоматизации сбора просроченной задолженности (collection). Благодаря им появляется возможность существенно повысить операционную эффективность и сократить количество операторов колл-центра. За счет бесшовной интеграции с системами телефонии, использования предиктивного набора можно увеличить количество ссуд, обрабатываемых в течение дня. Применение аналитических инструментов позволяет улучшить показатели возврата просроченной задолженности.
Несмотря на то что интеграция приложений требует существенных инвестиций, это базис для дальнейшего построения единого фронт-офиса банка, последующего снижения операционных расходов, повышения эффективности продаж и лояльности клиентов. В целом, для повышения эффективности бизнеса недостаточно только экономить, необходимо разумно инвестировать в свое развитие, чтобы завтра быть в лидерах рынка.