Риски в узде

Многие ИТ или бизнес-руководители, знакомые с проектами внедрения ERP или CRM-систем, слышали, читали или были свидетелями  серьезных проблем или провалов этих проектов.  

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

Цели проекта и управление рисками

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

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

Риски неизбежны?

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

Дополним список рисками сопротивления изменениям. Люди не любят перемен как таковых, это общеизвестно, но если мы говорим о внедрении новых систем управления процессами предприятия, то следует принять в расчет еще один фактор. Представьте себе компьютерную систему (из одного или нескольких приложений), с которой пользователи из различных подразделений работают уже много лет на основании документированных (или сложившихся неписанных) процессов. Что происходит в данном случае? Пользователи изыскивают способы обходить систему. Не будем брать в расчет откровенно криминальные ситуации, но примерами могут стать нахождение лазеек в кредитной политике, предоставление клиенту нерегламентированной скидки, заказ товарно-материальных ценностей в обход действующих квот. Как сотрудники встретят новую, незнакомую им систему с учетом того, что при внедрении делается особый акцент на неукоснительное следование процессам и политикам?  Говоря тактично, перемен редко ждут с энтузиазмом, и это может вылиться в различные формы: от затягивания работ до саботажа.
А теперь ответим на вопрос:  какова вероятность того, что воплотится в жизнь хотя бы один из перечисленных выше рисков? 100%.

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

Выбор оружия

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

Взгляд за поворот

На основе опыта коллег и своего собственного предложу два принципа, следование которым помогает своевременно обнаруживать и предвидеть риски.
Первое. Создайте рабочую культуру, в которой неудобные вопросы не замалчиваются и не скрываются. О проблемах и рисках никогда не надо врать. Ни руководству, ни коллегам и сотрудникам, ни себе. Они все равно всплывут, но тогда, когда цена решения их станет много больше, чем могла бы быть при своевременном обнаружении. «Better worry then sorry», в русском переводе приблизительно соответствует «лучше перебдеть, чем недобдеть».
Второе и более сложное. Проанализируйте ваш проектный опыт, и вы обнаружите, что проектные риски обнаруживаются, как правило, своевременно. Иной вопрос — как происходит управление процессом их предотвращения. Первый вариант развития событий:  возникший риск неделю за неделей «кочует» от совещания к совещанию, пока не «покраснеет», то есть пока его ранг не станет настолько серьезным, что его начнут отображать красным в текущей проектной отчетности. Тогда руководство проекта и управляющий комитет просыпаются от спячки и набрасывается, но теперь уже не на снижение вероятности риска, а на ликвидацию его последствий. Второй и рекомендуемый способ действий: по факту появления нового риска (или изменения ранга существующего) на ближайшем же проектном совещании планируются немедленные действия по работе с ним. Отчет о результатах обязательно должен быть включен в повестку следующего проектного совещания, либо, в случае серьезного риска, даже в повестку внеочередного совещания. Поэтому контролируйте действия, намеченные для ликвидации обнаруженного риска. Контролируйте их с той же степенью серьезности, что и основную последовательность проектных работ.

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

Человеческий фактор

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

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

И последнее. Ни одна система на момент завершения проекта не будет готова на 100%. Это еще один риск, который невозможно отменить, но можно и нужно принять в расчет. Обязательно будут исправления и дополнения функциональности, корректировка справочников и данных, глубокое обучение пользователей, «шлифовка» процессов и регламентов.  Все это проводится уже после запуска системы, в первые недели и месяцы, в зависимости от масштабов проекта. А это и есть доведение системы до готовности. И грамотное управление начальным периодом использования системы определяет успешность минимизации риска неполной готовности, который неизбежно ожидает вас у финишной черты проекта.