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

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

Соответственно, чем больше становится спектр задач, тем большая доля затрат банка тратится на IT-решения, тем важнее экономически эффективное использование IT – чтобы автоматизация приносила прибыль. Например, за полтора года, прошедших с перевода головного банка КБ «Транснациональный банк» на ИБС «Центавр Омега» произошли серьезные изменения.

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

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

Тем ценнее опыт нашего клиента Юг-Инвестбанка, CIO которого, Алексей Савенец, более 8 лет назад, выбирая IT-решение, исходил именно из критериев его экономической эффективности и сумел ее обеспечить. Это касается и спектра решаемых задач (от поддержки территориальной экспансии банка до повышения качества обслуживания клиентов), и сроков запуска новых бизнес-решений (от 1 до 3 месяцев), и снижения стоимости владения системой (IT-служба из 8 человек на 22 точки присутствия банка и 230 сотрудников).

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

а) расходы на персонал;

б) платежи разработчикам;

в) расходы на IT-инфраструктуру (локальные сети, Интернет-трафик, компьютеры и т.д.);

г) амортизация капитальных затрат.

К сожалению, не часто встречается понимание, что есть еще

д) риски, связанные с функционированием программного обеспечения

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

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

Выбор стратегии

Самая серьезная стратегическая «развилка» при этом — выбор компромисса между двумя «чистыми» стратегиями: опора на собственные силы и максимальный аутсорсинг.

Чем меньше банк, тем менее оправдано разнообразие поставщиков программных решений

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

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

Целостность IT-платформы

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

Здесь действует пара простых правил:

• чем меньше банк, тем менее экономически оправдано разнообразие поставщиков программных решений;

• для успешной эксплуатации спектра различных решений крайне критичны эффективные и адекватные механизмы интеграции.

Мы успешно работаем с разными банками, кроме этого, прекрасно понимаем, что небольшой банк может вырасти, и в IT-решение должен быть заложен запас прочности минимум на 7–10 лет. Поэтому мы накопили успешный опыт различных практик интеграции в сложные IT-ландшафты. Для ВТБ это — интеграция в IT-ландшафт на основе профессиональной интеграционной шины. Для ММВБ — использование различных механизмов интеграции для поддержки потоков данных между различными биржевыми системами, SWIFT, БЭСП, нефинансовыми системами группы ММВБ и.т.д. Для АСВ — двухсторонний интеграционный бизнес-процесс с бухгалтерской системой и т.д.

Самая серьезная стратегическая «развилка» — выбор компромисса между двумя «чистыми» стратегиями: опора на собственные силы и максимальный аутсорсинг

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

Стоимостные критерии выбора

И, наконец, о критериях выбора самих программных решений, как факторе, влияющем на размеры IT-расходов.

Цена приобретения. Входит в IT-расходы в форме амортизации, зависящей, кстати, и от периода эффективного использования. Соответственно, самым сложным является оценить срок эффективной эксплуатации IT-решения. Это вопрос настолько обширный, что заслуживает отдельной статьи (которую мы планируем разместить на нашем сайте). На уровне тезисного перечисления «срок жизни» решения зависит от ответа на следующие вопросы:

• Насколько современна приобретаемая разработка, не является ли она, например, новой визуальной оболочкой, натянутой на старый механизм транзакций?

• Какова позиция разработчика (а главное, история этой позиции) по поддержке и развитию своих решений?

• Насколько гибко решение? Как совместить реализацию своих технологий и поддержку от разработчика?

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

Наш опыт показывает, что общую стоимость внедрения можно снизить в разы — за счет быстрого запуска (с резким упрощением обследования), минимизации нагрузки на персонал банка (в проекте Транснационального банка это было одно из ключевых требований бизнеса), внедрения в удаленном режиме (в этом году мы так за 2 месяца провели внедрение в иркутском банке «Радиан»).

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

Правильнее все-таки оптимизировать, учитывая не только сами затраты, но и риски, связанные с качеством работы IT-инфра­структуры банка

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

Для управления «ценой поддержки в банке» (и удовлетворенностью клиентов) мы считаем важным проведение аудитов у наших клиентов — это одновременно выявление и анализ проблем, решение наиболее острых, а, главное, совместная корректировка IT-стратегии банка. В ряде случаев с таких аудитов начинаются масштабные проекты, как тот, который мы сейчас ведем в Коммерческом банке развития. А бывает иначе, как в КБ «Церих», где IT-служба, обновив свою «удочку», самостоятельно обеспечивает развитие и удовлетворенность клиентов

Здесь также важна вариативность предложения поставщика, а не конкретная номинальная величина.

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

Репутация поставщика программного решения. Этот «мнимый» (состоящий, на самом деле, из мнений участников рынка) фактор крайне трудно оценивать, поскольку мнения далеко не всегда объективны и обоснованы. Тем не менее, отсутствие значимых провалов в истории поставщика, да и сам факт длительности этой истории, снижает вероятность провала для банка, выбирающего решение. Здесь существенны именно не «истории побед», часто имеющие чисто маркетинговое происхождение, а «истории поражений», говорящие о менталитете менеджмента поставщика гораздо больше.

Вместо послесловия

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