Резерв на риск (Solution Contingency) — значимая статья проектного бюджета. Слишком большой резерв делает проект коммерчески неконкурентным. Недостаточный — может привести к снижению прибыльности или к невозможности завершения работ в рамках ожидаемых сроков, бюджета и уровня качества.

Резерв на риск отдельной строкой входит в себестоимость проекта и для проектов бизнес-трансформации варьируется в диапазоне от 5 до 30% от общего бюджета.

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

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

Группы риска

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

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

Рассмотрим подробнее каждую из них.

Ожидания заказчика

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

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

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

Также потребуется обеспечить отслеживание соблюдения процедуры.

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

В личные КПЭ участников проекта со стороны бизнеса следует включить целевые показатели по успешному выполнению задач в заданные сроки

Контрактные обязательства

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

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

Далее — заручитесь поддержкой вендора внедряемого решения для приоритетной обработки возможных инцидентов. Необходимо также предусмотреть экспертные ресурсы для оперативного реагирования и выработки временных решений на период обработки инцидентов со стороны вендора.

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

Подход к реализации проекта и доступные ресурсы

Здесь главные риски заключаются в опасности расхождения по срокам запуска и готовности доработок в части интеграции с параллельными проектами. Нередко можно встретить и недостаточную скорость и/или разрывы в мобилизации необходимой команды, а также привлечение новых субподрядчиков, рекомендованных со стороны заказчика.

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

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

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

Разработайте детальный, пообъектный план выгрузки, трансформации и загрузки данных с запланированными средствами автоматизации миграции данных.

Калькуляция резерва на риски

Мы сформулировали ключевые риски, которые могут возникнуть в ходе проекта бизнес трансформации, а также практические методы по превентивному управлению рисками.

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

Рассчитанный до старта проекта резерв на риск имеет свой жизненный цикл. При планировании проекта резерв декомпозируется по ключевым проектным рискам и в соответствии с ними распределяется во времени.

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

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

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

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

Ключевые риски и оценка их вероятности и влияния на проект может выглядеть следующим образом:

#

Группа риска

Риск

Вероятность

Влияние

1

Ожидания заказчика

Отсутствие единого спонсора. Согласование документов и решений более 5 дней с неопределённым количеством согласующих

Высокая

Среднее

2

Ожидания заказчика

Сопротивление новым унифицированным процессам со стороны дочерних обществ. Отсутствие органа для централизованного принятия решений

Высокая

Среднее

3

Контрактные обязательства

Фиксированная стоимость с размытыми требованиями по количеству и сложности доработок, новый клиент без опыта проектов бизнес-трансформации

Высокая

Высокое

4

Контрактные обязательства

Зависимость от смежных проектов внедрения MES- и WMS-систем, единый старт

Высокая

Среднее

5

Контрактные обязательства

Новое для рынка решение, первое внедрение: риск значительного количества ошибок в стандартном функционале

Средняя

Среднее

6

Подход к реализации проекта и доступные ресурсы

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

Средняя

Среднее

Виталий Новак, директор практики технологии Accenture в России