Людмила Васильевна Кулагина, выпускница МГУ, начинала свою карьеру как «эникейщик», долгое время работала, как CIO, в настоящий момент — заместитель Председателя Правления КБ «СИБЭС». За время работы она побывала по обе стороны баррикады — и на стороне ИТ, и на стороне бизнеса. В предлагаемой статье Людмила Васильевна рассказывает, чем и как CIO может помочь банку, особенно в сегодняшние непростые времена. «Возможно, подобные замечания уже были высказаны, и даже не раз: их оригинальность меня интересует меньше, чем истинность». Х.Л. Борхес Кулагина Людмила Васильевна Заместитель Председателя Правления КБ «СИБЭС»

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

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

Оптимизация нон-стоп или борьба с очередью

Основная сфера ответственности CIO — оптимизация. Хороший CIO периодически просматривает любой процесс на предмет — как его можно упростить и облегчить, нет ли здесь лишних звеньев? Когда бизнес приходит к CIO с просьбой «сделайте же что-нибудь, неудобно работать», CIO должен сделать харакири.

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

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

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

Для преодоления возникшей ситуации ИТ предприняло следующие шаги:

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

2. Были запрещены любые нецентрализованные списки. На базе АБС за 1 рабочий день был реализован функционал заявки на досрочное закрытие вкладов — «Журнал уведомления вкладчиков», что сразу выправило весь процесс. Заявка работает следующим образом: контакт-центр принимает заявку, создавая ее в АБС практически одним движением, (т.к. все вкладчики уже заведены в АБС, надо только поставить отметку), а казначейство в онлайн-режиме видит потребности в подкреплении кассы и своевременно обеспечивает необходимое количество наличности.

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

Мы рассчитали максимально возможную нагрузку офисов. Дабы не завышать ожидания вкладчика и сформировать запас по времени для тех, кто приходит в офис без звонка, мы приняли за длительность обслуживания одного клиента 15 минут. Офис работает с 9:00 утра до 20:00, в офисе, в зависимости от времени дня, одновременно работает от 1 до 3 операторов — на основе этой информации мы создали квазиэлектронную очередь, аналог талончиков в районной поликлинике, где номер талончика — это время гарантированного обслуживания клиента.
Исходя из рассчитанной нагрузки, мы дополнили возможности контакт-центра, и, например, сразу предлагали выбрать клиенту удобное для него время. Важно то, что мы, действительно, обслуживали клиента в это время.

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

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

«Настоящий CIO» должен сочетать три качества:

1. Во-первых, он должен быть в курсе бизнес-стратегии своего банка, знать задачи, решаемые бизнес-подразделениями.
2. Точно так же ему необходимо знать уже существующие процессы банка, т.к. это основное место приложения усилий — любые новые продукты и каналы продаж когда-то становятся процессами банка.
3. Ну и то, что отличает CIO от всех остальных: он обязан следить за новейшими технологиями, более того, он обязан помнить и все, что было придумано ранее. Порой новое — это хорошо забытое старое и помочь может что-то совсем простое. В описанном выше примере созданная нами электронная очередь — это прямой аналог журнала записи к врачу (к определенному времени), но несколько переосмысленный.

Выбор решения

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

Для выбора оптимального решения считаю наилучшим использовать классическую технологию RFP (Request For Proposal). Основные принципы такого подхода:

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

Для выбора оптимального решения считаю наилучшим
использовать классическую технологию RFP
(Request For Proposal).

Рассмотрим пару примеров использования технологии RFP в моей практике.
Несколько лет назад мы решали задачу внедрения абсолютно нового направления.
Под это был дан карт-бланш: за ценой не постоим. При этом у всех участников процесса уже были априори предпочтения того или иного продукта. Задача RFP свести субъективные ощущения к объективному выбору. В итоге победила банковская система «Гефест» компании «ПрограмБанк». На «ПрограмБанковское» решение изначально никто «не ставил», просто оно наиболее удовлетворяло всем поставленным критериям 1) быстрое внедрение, 2) масштабируемость, 3) производительность, 4) оперативная гибкая настройка, 5) стоимость внедрения, 6) стоимость владения.

Это глобальный пример, а вот — относительно небольшой. Недавно мы внедряли СЭД. Руководство уже видело полезность СЭД, его не надо было убеждать. Более того, руководство имело опыт работы с дорогим решением и готово было потратиться. Однако мы еще раз провели анализ рынка, составили RFP и приобрели решение, закрывающее все потребности, но сэкономили 400 000 рублей в год.

Внутреннее RFP

Подход RFP применим и для внутренних процессов — той самой оптимизации, за которую отвечает CIO. То есть, используемые технологии стоит мониторить и оценивать: нельзя ли получить лучшее за те же деньги или то же самое — за меньшие. Например:

• Серверы можно покупать не IBM, а SuperMicro, при сравнимых характеристиках экономится не менее 30 %.
• Вместо Windows server можно устанавливать OmniOS или CentOS, они бесплатны для бизнеса, а в некоторых задачах (например, файловый сервис или сервер Oracle) лучше.
• На рабочие места сотрудников, связанных с распечаткой клиентам выгружаемых из основной АБС документов, можно ставить Apache OpenOffice, он также бесплатен для бизнеса.
• Значительные возможности экономии на серверных мощностях связаны с использованием виртуальных машин, в частности OmniOS позволяет, практически без влияния на хост-систему, выполнять несколько тысяч машин, при этом, управляя их ресурсами и т.д.
  
  
  

Подводя итоги

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