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

I. Определите круг участников проекта внедрения

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

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

II. Согласовывайте единое видение результата со всеми участниками проекта внедрения

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

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

III. Детально изучите возможности внедряемого решения

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

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

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

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

IV. Хорошо продумайте все нюансы организации проекта

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

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

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

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

V. Настройтесь на открытое взаимодействие с поставщиком решения

Внедрение проекта может проходить по нескольким сценариям.

  • Сценарий 1. Заказчик самостоятельно определяет все условия проекта, подрядчик действует в строго определенных для него рамках. Многолетний опыт реализации проектов разного уровня сложности показывает, что такой подход далек от идеала. Заказчик не может знать всех особенностей поставляемого решения и не облада ет опытом его внедрения. Если следовать данному сценарию, то в результате можно получить крайне неэффективно работающее решение, поскольку не будет учтен ни опыт, ни знания поставщика.
  • Сценарий 2. Поставщик, основываясь на собственном опыте, навязывает свое видение конечного результата проекта и подхода к его достижению. Даже при наличии у поставщика огромного опыта и искреннего желания помочь заказчику в достижении его целей, процесс может оказаться крайне неэффективным из-за отсутствия у компании разработчика решения информации обо всех особенностях бизнеса заказчика.
  • Сценарий 3. Тесное взаимодействие заказчика и поставщика решения. Предполагает не только совместное определение цели проекта, но и совместный выбор подхода к ее достижению. Заказчик и поставщик готовы прислушиваться друг к другу и при необходимости менять свои установки с целью достижения оптимального результата. Такой подход следует признать наиболее разумным и эффективным при реализации любого проекта.

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

Заключение

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

Автор статьи — директор по управлению проектами компании Experian.