Стандарты на управление проектами и программами для ведения сложных и длительных проектов используются уже давно. Проекты по внедрению или модернизации банковских систем как раз можно причислить к длинным и сложным, часто приводящих к технологической модернизации всего банка. Статистика из разных источников показывает, что число проектов, закончившихся неуспешно, значительно превышает 50%. Согласно исследованиям издания IBS Intelligence за 2012/2013 гг., около 25% проектов по внедрению новой банковской системы закончились безрезультатно. В то время как по 50% таких проектов бюджет и сроки были сорваны, хотя проекты и были завершены.

Основные причины проблем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проблемы, вызванные ИТ

Напоследок мы хотели бы обратить внимание на причины проблем в проектах, вызванные ИТ-составляющей.

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

Вторая причина – это недооценка «сопутствующих» проектов по изменению интеграции, отчетности, унификации и трансформации данных, модернизации ИТ-инфраструктуры и т.д. «Сопутствующие» проекты могут составить от 40% до 60% временных (денежных) затрат на их реализации от основного проекта. Это приводит к большим многомесячным временным издержкам на придумывание «обходных» вариантов, либо реализации требуемого функционала.

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