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

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

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

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

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

Первый случай - когда задача ИТ-проекта конкретна: например, запуск розничного бизнеса, переход на централизованную АБС и др. При таком раскладе лучше всего разделить запуск решения и его развитие/оптимизацию. Тогда начать эксплуатацию ИТ-решения можно очень быстро: например, недавний перевод банка «Церих» на ИБС «Гефест» занял всего три недели, а автоматизация НКЦ - расчетного банка ММВБ - была выполнена за 1,5 месяца.

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

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

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

Приведенные выше примеры показывают, что для «быстрого старта» банку нужно быть уверенным в гибкости решения. Хорошим примером является упомянутая выше автоматизация расчетного центра ММВБ на базе АБС «Центавр Омега». С запуска проекта в 2007 году он активно развивается одновременно в разных направлениях: меняется сама структура группы ММВБ, меняется архитектура биржевых торгов, идет  развитие  собственных  бизнесов НКЦ в различных сегментах рынка ценных бумаг (не говоря уже об объемах -миллионы операций в день на фондовом рынке). Тут гибкость была обеспечена как современными ВРМ-технологиями, так и максимально широким спектром технологий интеграции в рамках «Омеги». Это позволяло всегда настроить требуемый бизнес-процесс и одновременно предложить заказчику технологию роста и улучшения.

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

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