Проектный менеджмент руководство по применению менеджмента риска при проектировании

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫМ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ПРОЕКТНЫЙ МЕНЕДЖМЕНТ

Руководство по применению менеджмента риска при проектировании

IEC 62198:2013 Managing risk in projects —Application guidelines (IDT)

Издание официальное

Москва

Стандартинформ

2016

Предисловие

1    ПОДГОТОВЛЕН Открытым акционерным обществом «Научно-исследовательский центр контроля и диагностики технических систем» (АО НИЦ КД) на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 10 «Менеджмент риска»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 20 ноября 2015 г. № 1910-ст

4    Настоящий стандарт является идентичным международному стандарту МЭК 62198:2013 «Управление риском в проектах. Указания по применению» (IEC 62198:2013 «Managing risk in projects — Application guidelines», IDT)

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (подраздел 3.5).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА

5    ВЗАМЕН ГОСТ Р 51901.4-2005 (МЭК 62198:2001)

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2016

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

ГОСТ Р МЭК 62198-2015

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

6.2 Полномочия и обязательства

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

a)    определять и поддерживать общую политику менеджмента риска, относящегося к проекту;

b)    гарантировать согласованность культуры организаций-участников и политики менеджмента риска проекта в максимально возможной степени;

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

d)    определять показатели результативности функционирования менеджмента риска проекта и согласовать их с показателями результативности выполнения проекта и организаций-участников;

e)    обеспечивать соответствие правовым и обязательным требованиям;

f)    установить ответственность и полномочия на соответствующих уровнях организации и в организации в целом;

д) обеспечивать распределение необходимых ресурсов для менеджмента риска проекта;

h) обеспечивать наличие системы поставки ресурсов в нужное место в нужное время;

7

i)    обеспечивать обмен информацией заинтересованными сторонами о выгодах менеджмента риска;

j)    обеспечивать постоянное соответствие структуры менеджмента риска при разработке проекта на всех стадиях жизненного цикла.

В некоторых случаях требования к менеджменту риска могут быть включены в контракт.

6.3 Разработка структуры менеджмента риска

6.3.1    Понимание проекта и его области применения

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

Анализ внешней области применения проекта может включать, но не ограничиваться этим:

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

b)    основные движущие силы и направления, воздействующие на цели организации или выполнение проекта;

c)    взаимосвязи с внешними заинтересованными сторонами, их ценностями и восприятием, включая все организации, связанные с проектом (см. рисунок 1).

Анализ внутренней области применения проекта может включать, но не ограничиваться этим:

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

e)    управление, организационную структуру, функции и обязанности для выполнения проекта;

f)    политику, цели и стратегии, необходимые для достижения этих целей,

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

h)    информационные системы, потоки информации и процессы принятия решений (как формальные так и неформальные), и особенно информационные системы, используемые для поддержки менеджмента проекта, его контроля и разработки отчетов;

i)    взаимосвязи с внутренними заинтересованными сторонами, их ценностями и восприятием;

j)    стандарты, руководства и модели, принятые организацией для выполнения проекта;

k)    форму и содержание контрактных отношений между партнерами.

6.3.2    Установление политики менеджмента риска проекта

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

a)    обоснование потребности организации в менеджменте риска;

b)    взаимосвязь целей и политики организации с политикой менеджмента риска проекта;

c)    обязательства и ответственность в отношении менеджмента риска проекта для всех вовлеченных организаций;

d)    способы разрешения конфликтов интересов;

е)    обязательства по обеспечению доступности необходимых ресурсов для подотчетных и ответственных за менеджмент риска;

f) способы определения значений параметров, которыми будут измерять и отчитываться об эффективности функционирования менеджмента риска проекта и его связь с выполнением проекта в целом, а также соответствующей отчетности;

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

Политика в области менеджмента риска должна быть правильно донесена до заинтересованных сторон.

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

6.3.3    Ответственность

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

ГОСТ Р МЭК 62198-2015

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

Этому может способствовать:

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

b)    определение лиц, ответственных за разработку, внедрение и поддержание структуры менеджмента риска;

c)    установление других видов ответственности работников на всех уровнях организации за процесс менеджмента риска;

d)    установление критериев функционирования работы внешней и внутренней отчетности и их распространение на риски всех проектов.

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

1)    определение обязанностей в области менеджмента риска, связанных с деятельностью по выполнению проекта;

2)    создание механизмов обмена информацией внутри проекта и координирование информации о менеджменте риска при выполнении проекта;

3)    определение области применения процесса менеджмента риска проекта;

4)    управление действиями по оценке риска и разработка соответствующих отчетов;

5)    рекомендация, инициализация, распределение ответственности по мониторингу эффективного выполнения деятельности по обработке риска;

6)    поиск руководством решений противоречивых задач менеджмента риска;

7)    обмен информацией обо всех проблемах в области менеджмента риска надлежащим и своевременным образом на протяжении всего периода выполнения проекта;

   обеспечение планами действий в нештатных ситуациях;

9)    идентификация и регистрация всех проблем в области менеджмента риска;

10)    мониторинг процесса менеджмента риска и осуществление корректирующих действий при необходимости;

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

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

6.3.4    Интеграция в процесс менеджмента проекта

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

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

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

6.3.5    Ресурсы

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

Следует определить:

a)    персонал, его навыки, опыт и компетентность;

b)    ресурсы, необходимые на каждом этапе процесса менеджмента риска проекта;

c)    процессы, методы и поддерживающие системы, используемые в менеджменте риска проекта;

d)    документированные процессы и процедуры менеджмента проекта;

e)    системы управления информацией и знаниями;

f)    программы обучения;

д) определенное в договоре распределение риска между организациями — участниками проекта.

9

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

6.3.6    Установление методов обмена информацией и отчетности проекта внутри организации

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

a)    надлежащее представление информации о ключевых элементах структуры менеджмента риска и всех последующих ее модификациях;

b)    наличие соответствующей внутренней отчетности о структуре, ее эффективности и выходах;

c)    доступность информации, полученной в результате применения менеджмента риска проекта, на соответствующих уровнях и в нужное время для всех участвующих организаций, в том числе на всех стадиях разработки проекта;

d)    использование процессов консультирования с внутренними заинтересованными сторонами.

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

6.3.7    Установление методов обмена информацией и отчетности о выполнении проекта с внешними заинтересованными сторонами

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

Такой план должен включать:

a)    взаимодействие с соответствующими внешними заинтересованными сторонами и обеспечение обмена информацией с ними о проекте;

b)    внешнюю отчетность о соответствии правовым, обязательным и другим требованиям;

c)    обратную связь и отчетность об обмене информацией и консультациях;

d)    обмен информацией для обеспечения доверия к организациям- участникам;

e)    обмен информацией с заинтересованными сторонами в критической ситуации или непредвиденных условиях.

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

6.4 Внедрение менеджмента риска проекта

6.4.1    Внедрение структуры менеджмента риска проекта

При внедрении структуры менеджмента риска проекта, организации, вовлеченные в выполнение проекта, должны:

a)    определить соответствующие сроки и стратегию применения структуры менеджмента риска в проекте, применяя по возможности совместную разработку политики и процессов менеджмента риска с владельцами риска каждой организации;

b)    объединить политику и процесс менеджмента риска проекта с процессами менеджмента проекта;

c)    обеспечить соответствие правовым и другим обязательным требованиям;

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

e)    проводить информационные и обучающие сессии;

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

6.4.2    Внедрение процесса менеджмента риска проекта

Внедрение менеджмента риска проекта должно быть основано на выполнении процесса менеджмента риска (см. раздел 7) в соответствии с планом менеджмента риска (см. 7.7.2) на всех уровнях организаций-участников как часть их деятельности и процессов менеджмента риска проекта.

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

ю

ГОСТ Р МЭК 62198-2015

6.5    Мониторинг и анализ структуры менеджмента риска проекта

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

a)    периодически анализировать критерии функционирования проекта на их приемлемость и соответствие критериям выполнения проекта;

b)    периодически определять выполнение плана менеджмента риска проекта и определять отклонения от него;

c)    периодически анализировать структуру, политику и план менеджмента риска проекта на их адекватность в соответствии с внутренней и внешней областью применения и продвижение разработки проекта;

d)    предоставлять информацию о риске проекта, продвижении выполнения плана менеджмента риска проекта, выполнении политики менеджмента риска проекта, являющейся частью отчетности организации;

e)    анализировать эффективность структуры менеджмента риска проекта.

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

–    показатели успешности выполнения проекта, характеризующие степень достижения цели;

–    показатели, характеризующие степень выполнения менеджмента риска процесса;

–    показатели, характеризующие результативность обработки риска.

6.6    Постоянное улучшение структуры менеджмента риска

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

7 Процесс менеджмента риска проекта

7.1 Общие положения

Процесс менеджмента риска проекта должен быть:

–    неотъемлемой частью менеджмента проекта;

–    частью деятельности организаций, участвующих в выполнении проекта;

–    согласованным и интегрированным с бизнес-процессами и процессами менеджмента проекта организаций — участников проекта.

Процесс менеджмента риска проекта включает деятельность, описанную в 7.2—7.7. Схема процесса менеджмента риска проекта приведена на рисунке 3.

11

7.2    Обмен информацией и консультации

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

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

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

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

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

Подход на основе создания консультативной группы может:

a)    помочь в установлении области применения;

b)    гарантировать, что интересы заинтересованных сторон поняты и рассмотрены;

c)    помочь в обеспечении адекватной идентификации рисков;

d)    объединять различные области экспертизы для анализа рисков;

e)    гарантировать рассмотрение различных точек зрения при определении критериев риска и количественной оценке риска;

f)    обеспечивать одобрение и поддержку плана обработки риска;

д) совершенствовать соответствующее управление изменениями проекта в процессе менеджмента риска;

h) разрабатывать соответствующий план внешнего и внутреннего обмена информацией и консультаций.

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

1)    проектирование и разработка;

2)    функции управления проектом и коммерцией;

3)    управление конфигурацией;

4)    качество и надежность;

5)    постпроектная поддержка, включая поддержку пользователя и техническое обслуживание продукции.

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

7.3    Установление области применения

7.3.1 Общие положения

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

Поскольку многие параметры аналогичны параметрам, рассматриваемым при разработке структуры менеджмента риска (см. 6.3), в этом случае при установлении области применения процесса ме-

12

ГОСТ Р МЭК 62198-2015

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

7.3.2    Установление внешней области применения

Внешняя ситуация (контекст) — внешняя среда, в которой будет выполнен проект.

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

Внешняя область применения включает (но может быть дополнена):

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

b)    основные источники и направления воздействия организации;

c)    зависимость от восприятия и значимости внешних заинтересованных сторон.

7.3.3    Установление внутренней области применения

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

–    менеджмент риска проекта влияет на цели, установленные организациями для выполнения проекта;

–    процесс менеджмента риска проекта должен быть согласован с культурой, процессами, структурой и стратегиями организации;

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

Внутренняя область применения включает (перечень может быть дополнен):

a)    управление, организационную структуру, распределение обязанностей и полномочий;

b)    политику, цели и стратегии, необходимые для достижения этих целей;

c)    потенциальные возможности в виде ресурсов и знаний (например, капитал, время, персонал, процессы, системы и технологии);

d)    зависимость от восприятия и значимости внутренних заинтересованных сторон;

e)    информационные системы, информационные потоки и процессы принятия решений (как формализованные, так и неформализованные);

f)    стандарты, руководства и модели, принятые организацией;

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

7.3.4    Установление области применения процесса менеджмента риска

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

Область применения менеджмента риска зависит от потребностей проекта. Она может включать (перечень может быть дополнен):

a)    определение проекта сточки зрения необходимых действий и процессов, активов, изготовляемой продукции, оказываемых услуг, затрат времени и расположения;

b)    определение решений, которые должны быть приняты;

c)    определение области применения, а также глубины и объема деятельности в области менеджмента риска проекта, которую необходимо выполнить, включая дополнения и исключения там, где это возможно, виды риска, которые будут подвергнуты обработке;

d)    определение взаимосвязи между конкретным проектом, процессом или деятельностью и другими проектами, процессами или видами деятельности вовлеченных организаций;

е)    определение задач и целей деятельности в области менеджмента риска проекта;

f) определение ответственностей за процесс менеджмента риска проекта, в том числе внутри процесса;

13

д)    идентификацию направлений и объема необходимого обучения, его целей и ресурсов, необходимых для такого обучения;

h)    определение методологии оценки риска проекта;

i)    определение методов количественной оценки функционирования и результативности менеджмента риска проекта.

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

7.3.5    Определение критериев риска

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

При определении критериев риска необходимо рассмотреть:

a)    природу и типы причин или источников риска и вероятность их реализации;

b)    природу типа возможных последствий, которые могут возникать и способ определения их величины;

c)    границы интервала времени, в пределах которых возможно появление последствий;

d)    как должен быть определен уровень риска;

е)    уровень приемлемого или допустимого риска;

f) необходимость учета множественных рисков и (если да) виды и способ комбинаций, которые следует рассмотреть.

При разработке критериев риска следует учитывать мнения заинтересованных сторон.

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

1)    коммерческих и бизнес-целей организаций, участвующих в выполнении проекта;

2)    выполнение целей проекта по затратам и выполнению графика работ;

3)    качества, надежности и результативности активов, продукции или услуг, создаваемых проектом;

4)    здоровья и безопасности заинтересованных сторон, проекта;

5)    защиты окружающей среды и ее повышения;

6)    соответствия законодательным и обязательным требованиям.

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

7.3.6    Ключевые элементы

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

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

a)    работ проекта (WBS), общей структуры риска, выполняемых функций, поставок или затрат;

b)    деления по стадиям жизненного цикла проекта;

c)    основных разделов информации о проекте, которая обеспечивает принятие решения о переходе на следующую стадию выполнения;

d)    компонентов активов, продукции или услуг, создаваемых проектом;

e)    мест реализации проекта;

f)    контрактов и субподрядных договоров или разделов контракта;

д) элементов организационной структуры.

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

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

14

ГОСТ Р МЭК 62198-2015

7.4 Оценка риска

7.4.1    Общие положения

Оценка риска охватывает весь процесс идентификации анализа и количественной оценки риска.

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

7.4.2    Идентификация риска

Цель идентификации риска состоит в выявлении, перечислении и описании всех видов риска, которые могут повлиять на выполнение проекта в целом (в положительном или отрицательном смысле).

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

При идентификации рисков следует рассмотреть обработку рисков на все цели проекта.

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

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

a)    мозговой штурм в пределах структуры ключевых элементов;

b)    экспертные оценки;

c)    интервью и анкетирование;

d)    контрольные листы;

e)    хронологические данные;

f)    предыдущий опыт участников и данные других проектов;

д) данные испытаний и моделирования;

h) формальные методы, такие как анализ видов и последствий отказов (FMEA) или метод анализа опасностей и работоспособности (HAZOP).

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

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

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

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

Все виды риска должны быть зарегистрированы. Обычно их заносят в реестр риска проекта (см. 7.7.4).

15

7.4.3    Анализ риска

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

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

Риск может иметь множественные последствия, которые связаны с несколькими целями проекта.

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

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

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

Анализ может быть качественным или количественным или их комбинацией в зависимости от обстоятельств.

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

7.4.4    Сравнительная оценка риска

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

Сравнительная оценка может включать сбалансированное ранжирование различных видов рисков (с положительными и с отрицательными последствиями) для принятия решения о возможности продолжения работы над проектом или о способах выполнения проекта.

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

7.5 Обработка риска

7.5.1 Общие положения

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

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

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

16

ГОСТ Р МЭК 62198-2015

Содержание

1    Область применения…………………………………………………………1

2    Нормативные ссылки…………………………………………………………1

3    Термины и определения………………………………………………………1

4    Менеджмент риска при проектировании…………………………………………..3

5    Принципы…………………………………………………………………5

6    Структура…………………………………………………………………6

7    Процесс менеджмента риска проекта……………………………………………11

Приложение А (справочное) Примеры…………………………………………….21

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

национальным стандартам Российской Федерации………………………32

Библиография………………………………………………………………33

ГОСТ Р МЭК 62198-2015

Обработка риска включает циклический процесс: после начальной обработки риск переоценивают для определения допустимости остаточного риска. В противном случае выполняют другую обработку риска.

7.5.2    Выбор вариантов обработки риска

Варианты обработки риска могут включать:

a)    установление риска с отрицательными последствиями с устранением источника риска или в случае решения не начинать или не продолжать деятельность, в результате которой возникает риск (или прервать выполнение проекта);

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

c)    выполнение действий, изменяющих вероятность возникновения риска (повышающих вероятность положительных последствий или снижающих вероятность отрицательных последствий);

d)    выполнение действий, изменяющих последствия риска (повышающих положительные последствия и снижающих отрицательные последствия);

e)    разделение риска с другой стороной или сторонами (в том числе контрактов путем заключения страхования или субсидирование риска);

f)    поддержание риска путем принятия обоснованных решений.

Решения об обработке риска основаны на простой логике:

1)    если последствия риска не соответствуют законодательным или обязательным требованиям, необходимо проведение обработки риска;

2)    если последствия риска не соответствуют политике организации или критериям риска, установленным при разработке области применения, как правило, необходима обработка риска;

3)    если последствия риска оказывают неблагоприятное влияние на здоровье и безопасность людей, то обработка риска должна быть проведена, а критерием приемлемости: «риск должен быть настолько низким насколько это целесообразно» (ALARP);

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

Варианты обработки риска не обязательно являются взаимоисключающими и не всегда воздействуют только на один риск. Могут быть рассмотрены и применены различные варианты обработки отдельного риска или комбинации вариантов. Часто удобнее использовать комбинацию вариантов обработки риска.

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

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

7.5.3    Планы обработки риска

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

a)    обоснование выбора вариантов обработки риска, включая ожидаемые выгоды;

b)    перечень ответственных за утверждение плана и ответственных за выполнение плана;

c)    предлагаемые действия и приоритетность их выполнения;

d)    требования к ресурсам, включая возможные непредвиденные обстоятельства;

e)    измерения и ограничения показателей функционирования;

f)    требования к отчетности и мониторингу;

д) сроки и график выполнения.

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

1)    специалист, ответственный за деятельность, вызывающую риск;

2)    специалист, контролирующий вероятность появления риска;

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

17

Введение

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

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

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

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

Требования, установленные в настоящем стандарте, не предполагают отмены действующих стандартов.

IV

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ПРОЕКТНЫЙ МЕНЕДЖМЕНТ Руководство по применению менеджмента риска при проектировании

Project management. Guidance on the application of risk management in the design

Дата введения 2016—07—01

1    Область применения

В настоящем стандарте установлены принципы и рекомендации в области менеджмента риска. В частности стандарт устанавливает подход к менеджменту риска проекта, на основе требований ИСОЗЮОО.

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

Стандарт не предназначен для целей сертификации.

2    Нормативные ссылки

В настоящем стандарте использована ссылка на следующий стандарт:

ИСО 31000 Менеджмент риска. Принципы и руководство (ISO 31000 Risk management — Principles and guidelines)

3    Термины и определения

В настоящем стандарте применены термины по ИСО 10006 и Руководству ИСО 73, а также следующие термины с соответствующими определениями:

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

Примечание 1 — Конкретный проект может быть частью более крупного проекта.

Примечание 2 — В некоторых проектах по мере их развития совершенствуются цели проекта и характеристики продукции.

Примечание 3 — Продукцию проекта определяют в общем случае в области применения проекта. Это могут быть одна или несколько единиц продукции. Продукция проекта может быть материальной или не материальной.

Примечание 4 — Проектная организация обычно является временной — создаваемой на время выполнения проекта.

Примечание 5 — Сложность взаимодействий между различными видами проектной деятельности не обязательно связана с объемом проекта.

[ИСО 10006:2003, 3.5] (см.[1])

3.2    менеджмент проекта (project management): Планирование, организация, мониторинг, контроль и регистрация всех аспектов проекта и поощрение всех участников для достижения целей проекта.

[ИСО 10006:2003, 3.6]

Издание официальное

3.3    план менеджмента проекта (project management plan): Документ, устанавливающий меры, необходимые для достижения целей проекта.

Примечание 1 — План менеджмента проекта должен включать в себя план качества (3.8) проекта или ссылаться на него.

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

[ИСО 10006:2003, 3.7]

3.4    риск (risk): Следствие влияния неопределенности на достижение поставленных целей¹).

Примечание 1 — Под следствием влияния неопределенности необходимо понимать отклонение от ожидаемого результата или события (позитивное и/или негативное).

Примечание 2 — Цели могут быть различными по содержанию (в области экономики, здоровья, экологии и т.п.) и назначению (стратегические, общеорганизационные, относящиеся к разработке проекта, конкретной продукции и процессу).

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

Примечание 4 — Риск часто представляют в виде последствий возможного события (включая изменения обстоятельств) и соответствующей вероятности.

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

[Руководство ИСО 73:2009, 1.1] (см.[2])

3.5    менеджмент риска (risk management): Скоординированные действия по руководству и управлению организацией в области риска.

[Руководство ИСО 73:2009, 2.1]

3.6    структура менеджмента риска (risk management framework): Взаимосвязанные элементы, которые обеспечивают реализацию принципов и организационные меры, применяемые при проектировании, разработке, внедрении, мониторинге, анализе и постоянном улучшении менеджмента риска организации.

Примечание 1 — Принципы отражают политику, цели, полномочия и обязательства в области менеджмента риска (3.5).

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

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

[Руководство ИСО 73:2009, 2.1.1]

3.7    политика в области менеджмента риска (risk management policy): Заявление высшего руководства об общих намерениях, руководящих принципах и направлениях деятельности организации в области менеджмента риска.

[Руководство ИСО 73:2009, 2.1.2]

3.8    план менеджмента риска (risk management plan): Краткое, схематичное описание деятельности и мероприятий в пределах структуры менеджмента риска, устанавливающих подход, элементы менеджмента и ресурсы, применяемые для менеджмента риска.

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

Примечание 2 — План менеджмента риска может быть применен к конкретной продукции, процессу и проекту, к части или всей организации.

[Руководство ИСО 73:2009, 2.1.3]

¹¹ В соответствие с ФЗ «О техническом регулировании» от 27.12.2002 № 184-ФЗ «риск — это вероятность причинения вреда жизни или здоровью граждан, имуществу физических или юридических лиц, государственному или муниципальному имуществу, окружающей среде, жизни или здоровью животных и растений с учетом тяжести этого вреда».

2

ГОСТ Р МЭК 62198-2015

3.9    процесс менеджмента риска (risk management process): Взаимосвязанные действия по обмену информацией, консультациям, установлению целей, области применения, идентификации, исследованию, оценке, обработке, мониторингу и анализу риска, выполняемые в соответствии с политикой, процедурами и методами менеджмента организации.

[Руководство ИСО 73:2009, 3.1]

3.10    обработка риска (risk treatment): Процесс модификации риска.

Примечание 1 — Обработка риска может включать в себя:

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

–    принятие или повышение риска для обеспечения более широких возможностей;

–    устранение источников риска;

–    изменение правдоподобности/вероятности опасного события;

–    изменение последствий опасного события;

–    разделение риска с другой стороной или сторонами (путем включения в контракты или финансирования обработки риска);

–    обоснованное решение о сохранении риска.

Примечание 2 — Меры по обработке риска могут включать в себя устранение, предотвращение или снижение риска.

Примечание 3 — При обработке риска могут возникнуть новые риски и могут измениться существующие риски.

[Руководство ИСО 73:2009, 3.8.1]

4 Менеджмент риска при проектировании

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

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

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

Стадии проекта и их особенности приведены в таблице 1.

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

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

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

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

3

ГОСТ Р МЭК 62198-2015

ГОСТ Р МЭК 62198-2015

b)    членами группы проектирования, ответственными за важные участки проекта, мероприятия или комплексы работ;

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

d)    руководителями, утверждающими результаты выполненных работ по проекту в каждой ключевой точке, и расходы, связанные со следующим этапом проекта;

e)    экспертами, обеспечивающими руководителям уверенность в том, что информация, на основании которой они принимают официальные решения, является полной, точной и достоверной;

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

д) финансистами и страховщиками, финансирующими и поддерживающими проект;

h)    проверяющими, связанными с проектом действий или активов, продукции или услуг, создаваемых проектом;

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

5 Принципы

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

a)    Менеджмент риска должен создать и защитить ценности организации

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

b)    Менеджмент риска должен быть неотъемлемой частью всех процессов организации, связанных с проектом

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

c)    Менеджмент риска должен быть частью процесса принятия решений

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

d)    Менеджмент риска должен учитывать неопределенность имеющейся информации

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

5

e)    Менеджмент риска должен быть систематическим, структурированным и своевременным

Систематический, регулярный и структурированный подход к менеджменту риска способствует

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

f)    Менеджмент риска должен быть основан на наилучшей доступной информации

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

д) Менеджмент риска должен быть адаптируемым

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

h)    Менеджмент риска должен учитывать человеческие и культурные факторы

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

i)    Менеджмент риска должен быть прозрачным и учитывать интересы заинтересованных сторон

Соответствующее и своевременное вовлечение заинтересованных сторон и лиц, принимающих

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

j)    Менеджмент риска должен быть динамичным, итеративным и реагирующим на изменения

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

k)    Менеджмент риска должен способствовать постоянному улучшению деятельности организации

Организация должна разрабатывать и применять стратегии повышения зрелости менеджмента

риска проекта одновременно с другими аспектами процессов организации.

6 Структура

6.1 Общие положения

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

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

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

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

ГОСТ Р 51901.4-2005

ОКС 03.120.30

Дата введения 2006-02-01

1 ПОДГОТОВЛЕН Открытым акционерным обществом «Научно-исследовательский центр контроля и диагностики технических систем» (ОАО «НИЦ КД») на основе собственного аутентичного перевода стандарта, указанного в пункте 4

2 ВНЕСЕН Управлением развития, информационного обеспечения и аккредитации Федерального агентства по техническому регулированию и метрологии

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 6 сентября 2005 г. N 220-ст

Введение

Рисунок 1 — Примеры факторов риска, воздействующих на проект

Рисунок 1 — Примеры факторов риска, воздействующих на проект

1 Область применения

2 Нормативные ссылки

3 Термины и определения

В настоящем стандарте применены термины по ГОСТ Р ИСО 10006, а также следующие термины с соответствующими определениями:

3.1 продукция (product): Результат действий или процесса. Продукцией могут быть: услуги, технические средства, обработанные материалы, программное обеспечение или их комбинация.

3.3 процесс (process): Набор находящихся во взаимосвязи ресурсов и действий, которые преобразовывают входы в выходы.

3.4 проектный риск (project risk): Сочетание вероятности появления опасного события и его последствий для целей проекта.

3.5 менеджмент риска (risk management): Систематическое приложение политики, процедур и методов управления к задачам определения ситуации, идентификации, анализа, оценки, обработки, мониторинга риска и обмена информацией по вопросам риска.

4 Краткий обзор менеджмента риска при проектировании

4.1 Роль менеджмента риска при проектировании

4.2 Общая схема процесса

Рисунок 2 — Концепция менеджмента риска проекта

Рисунок 2 — Концепция менеджмента риска проекта

5 Организационные проблемы

5.1 Ответственность руководства

5.2 Ресурсы

5.3 Обмен информацией

5.4 Документация

6 Процессы менеджмента риска при проектировании

6.1 Определение ситуации

6.2 Идентификация риска

6.3 Оценка риска

Рисунок 3 — Диаграмма риска

Рисунок 3 — Диаграмма риска

Рисунок 4 — Матрица риска

Рисунок 4 — Матрица риска

6.4 Обработка риска

Рисунок 5 — Процесс обработки риска

Рисунок 5 — Процесс обработки риска

6.5 Исследование и мониторинг риска

Приложение А (справочное). Схема процесса менеджмента риска при проектировании

Приложение А
(справочное)

Рисунок А.1

Чтобы грамотно управлять угрозами для бизнеса, мы решили использовать метод фреймворка PMBoK от PMI. Разработчики предлагают поделить процесс управления на 6 этапов:

1. Планирование управления
2. Идентификация факторов
3. Качественная оценка
4. Количественная оценка
5. Планирование реакции
6. Мониторинг и контроль

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

Такую схему из 6 этапов предлагает PMBoK.

Планирование управления

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

Вот такую проектную схему предлагают разработчики PMBoK.

Диаграмма потоков данных планирования управления рисками в PMBoK.

3 главных аспекта правильного планирования:

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

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

Обычно в плане управления указывают:

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

Идентификация

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

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

Классификация рисковых событий по степени их контролируемости.

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

Пример классификации рисковых событий в зависимости от их источника.

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

Фрагмент реестра рисковых ситуаций.

Анализ и оценка рисков проекта

Здесь мы совмещаем качественную и количественную оценку.

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

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

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

Матрица вероятности/воздействия угроз и благоприятных возможностей из PMBoK.

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

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

Чем выше вероятность реализации и существенней влияние на проектов, тем выше степень рисковой угрозы.

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

Количественная оценка помогает проанализировать:

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

Обычно для количественного анализа используют такие методологии:

Вероятностный анализ — оценка на основе статистики по прошлым проекта с учетом вероятностной погрешности.

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

Имитационное моделирование — оценка, сделанная на основе многократных опытов с моделью.

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

Планирование реакции

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

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

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

2. Передача. Перекладываем ответственность за негатив на третью сторону. Например, заключаем договор страхования, берем предоплату, предусматриваем в договоре с заказчиком неустойку. Иногда на это потребуются дополнительные деньги.

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

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

На основании выбранного варианта реагирования предпринимаются дальнейшие действия. Например, в PMBoK рекомендуют вносить изменения в документацию или план проекта.

Диаграмма потоков данных планирования реакции на угрозы из PMBoK.

Мониторинг и управление

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

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

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

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

Научитесь: Профессия Менеджер проектов
Узнать больше