8.5.Процедура управления рисками в проекте внедрения ERP-системы

Рассмотрим в заключение главы конкретный перечень шагов, используемых для управления рисками на проектах внедрения ERP-системы.

Еще раз кратко повторим важность управления рисками в простом списке ответов на вопрос: «Что будет, если про риски не думать в начале проекта?»:

• Все хорошо (повезло).
• Все плохо (начали срабатывать риски).
• Все очень плохо (сработавшие риски никак не решались).

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

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

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

2.Анализ риска. Руководители проекта со стороны заказчика и исполнителя анализируют данный риск и определяют дальнейшие действия по нему:

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

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

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

5.Принятие решения. Принятое решение фиксируется в протоколе заседания управляющего комитета и является обязательным для исполнения. Данное решение регистрируется руководителем проекта со стороны исполнителя в «Отчете о состоянии проекта».

6.Периодический анализ рисков проекта. Руководители проекта со стороны заказчика и исполнителя проводят периодический контроль (например, 1 раз в 2 недели) активных рисков проекта и процедур по их устранению (в рамках периодических совещаний по состоянию проекта).

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

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

Отправить