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

УРОК 1: СТРАТЕГИЧЕСКАЯ РОЛЬ IT

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

Иначе вероятны такие проблемы, как:

• подчинение изменений в IT сиюминутным потребностям бизнеса, нагромождение мелких, малоэффективных, тяжелых в поддержке системных модулей;
• недостаточное понимание развития IT-платформы банка на уровне топ-менеджмента и как следствие - неэффективное использование одних возможностей и предъявление неадекватных требований к другим; недостаточное обеспечение ресурсами;
• взгляд на IT исключительно как на фактор затрат, а не двигатель конкурентных преимуществ банка и его роста.

УРОК 2: ЧИСТО ТЕХНОЛОГИЧЕСКИХ ПРОЕКТОВ НЕ СУЩЕСТВУЕТ

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

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

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

УРОК 3: УПРАВЛЯТЬ ПОРТФЕЛЕМ ЗАДАЧ

Для того чтобы иметь возможность выполнять значительные проекты, банк должен аккуратно и последовательно управлять соотношением объема стоящих задач и своими «мощностями» по их реализации. Подобное управление включает в себя регулярный пересмотр и уточнение задач из портфеля текущих и планируемых проектов, а также неизбежно возникающего массива запросов на доработку существующих функций. Результатом такого пересмотра должно быть принятие решений - оправдывает ли критичность задачи и соотношение затраты/выгоды ее реализацию? Сохраняется ли актуальность задачи? Не целесообразно ли изменение ее содержания, перенос выполнения или даже отмена задачи? Конечно, в таких решениях неизбежно столкновение интересов, поэтому к обсуждению должны привлекаться по возможности все заинтересованные стороны - бизнес, IТ, операционные службы, поставщики решений и услуг.

УРОК 4: «ПЛЯСАТЬ» ОТ БИЗНЕСА

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

• как соотносится проект со стратегией банка: создаются новые продукты, услуги, каналы обслуживания? повышается производительность? снижаются операционные затраты?
• что говорит анализ бизнес-процессов: какие процессы необходимо внедрить/изменить (напомним, нет проектов чисто IТ)? а нужно ли вообще изменение IТ-платформы, или цели проекта можно достичь другими средствами?
• каковы оцениваемые затраты в сравнении с ожидаемыми выгодами от внедрения проекта?

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

УРОК 5: СЛЕДИТЬ ЗА ЗОНАМИ РИСКА

Есть несколько областей, которым часто уделяется недостаточное внимание и которые поэтому становятся источником повышенной опасности для успеха проекта. Вот некоторые из них:

• зачастую недооценивается роль и необходимые трудозатраты бизнес-пользователей, несмотря на то что их участие критично в целом ряде проектных фаз - от формулирования требований до приемки и запуска в эксплуатацию. Бизнеспользователи основательно загружены текущими задачами, поэтому важно с самого начала договориться об объеме их вовлечения в проект;
• для контролируемого и управляемого проекта важно как можно раньше зафиксировать бизнес-требования (как часть бизнес- и операционной модели внедрения). Неизбежные корректировки должны проходить по четко соблюдаемой процедуре управления изменениями. Особенно важно иметь документированные требования во время приемочного тестирования, поскольку именно тогда пользователи обычно впервые видят результаты проекта, и нередко возникают конфликты из-за несоответствия ожиданий;
• покупая серьезную программную систему, банк изначально находится в неравноправном по отношению к производителю системы положении. Действительно, вендор системы знает о ее особенностях заведомо больше, нежели самые опытные специалисты банка. Поэтому при изучении и выборе систем, определении необходимой конфигурации важно детально документировать утверждения и обязательства вендоров систем. В интересах банка заложить в лицензионный контракт положения, обуславливающие его действие в зависимости от соответствия системы этим документам.

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