Структура риска - Risk breakdown structure

Иерархическая структура рисков (RBS) - А иерархически организованное изображение выявленных проект риски по категориям.[1][2]

Введение в иерархическую структуру рисков

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

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

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

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

В настоящее время Институт управления проектами (PMIр) имеет команду малых и средних предприятий, работающих над Стандартом практики управления рисками. Эта команда определила один очень хороший инструмент: Иерархическая структура рисков (RBS). RBS помогает руководителю проекта, риск-менеджеру и почти всем акционер понимать и, следовательно, уметь идентифицировать и оценивать риск.

Что такое «иерархическая структура рисков»?

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

Следуя концепции Иерархическая структура работ (WBS) Иерархическая структура рисков предоставляет менеджерам проекта и менеджерам по рискам средства для структурирования рассматриваемых или отслеживаемых рисков. Так же, как PMI определяет Иерархическая структура работ как «группу элементов проекта, ориентированную на конечный результат, которая организует и определяет общий объем работ по проекту ...» RBS можно рассматривать как «иерархически организованное изображение выявленных рисков проекта, упорядоченных по категориям рисков».

Говоря языком управления проектами, риски включают в себя все незапланированные и непредвиденные обстоятельства, которые могут отрицательно повлиять на стоимость, сроки или качество проекта. [Это не соответствует взгляду на риски ISO 31000] Хороший менеджер проекта должен уметь эффективно управлять рисками и вести проект в нужное русло.

Многие менеджеры проектов и менеджеры по рискам в настоящее время используют собственные методы для составления списков, выявления, оценки и отслеживания рисков в своих проектах. Эти методы включают: электронные таблицы, листинг, общий риск таксономия, основанный в некоторой степени на различных стандартах и ​​рекомендациях.[3][4][5]

Подход, при котором риски просто помещаются в список, простую таблицу или даже в базу данных, не дает возможности использовать структурированный, организованный метод, аналогичный иерархической структуре работ. Чтобы полностью понять риски и лучше идентифицировать и оценивать риск, может потребоваться «глубокое погружение» в каждый риск, регистрируя столько уровней идентификации, сколько необходимо. Ценность проекта размещения рисков в такой структуре заключается в способности менеджера проекта и менеджера рисков затем быстро и легко идентифицировать и оценивать риск, определять потенциальные триггеры риска и разрабатывать дополнительные крепкий план реагирования на риски.[6] Если все риски размещены в иерархической структуре по мере их идентификации, и структура организована по источникам, общая подверженность риску проекта станет более понятной, а планирование рисков будет более простым.

Шаблоны для создания иерархической структуры рисков

Концепция RBS нова. PMBoK (2004) почти не упоминает о его использовании; однако команда стандартов PMI включила RBS в Стандарт практики управления рисками (проект выпуска в 2009 г.). PMBoK предоставляет пример изображения RBS в главе 11, рисунок 11.4. В этом справочнике представлены основные темы: техническое, внешнее, организационное и управление проектами. Другой источник [7] содержит следующие основные темы: Технический, Менеджмент, Организационный, Внешний и Управление проектами. Д-р Дэвид Хиллсон, в трудах Ежегодных семинаров и симпозиумов Института управления проектами 3-10 октября 2002 г.[8] предоставил несколько различных примеров структуры RBS с темами, аналогичными тем, которые уже были показаны. Доктор Хиллсон привел два разных примера: RBS для Разработка программного обеспечения, который был посвящен следующим основным темам: Разработка продукта, Среда разработки, Программные ограничения; и RBS для строительного проектирования, в котором есть следующие основные темы: окружающая среда, промышленность, заказчик, проект.

Каждое удаленное хранилище больших двоичных объектов разбито на «уровни», каждый из которых обеспечивает более глубокое «представление» о выявленном риске. Например, при создании удаленного хранилища больших двоичных объектов для разработки программного обеспечения уровень 1 удаленного хранилища больших двоичных объектов может быть техническим, за которым следует уровень 2, требования, за которым следует уровень 3, Функциональные требования, Информационные требования, Нефункциональные требования и т. д. При желании Уровень 3 может быть дополнительно доработан с помощью Уровня 4, Стабильности, Полноты, Функциональности, Интерфейсов, Тестируемости и т. д., Уровня 5 и т. д.

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

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

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

Создание индивидуальных структур разбивки рисков

Пример разработанной индивидуальной иерархической структуры рисков с результатами многоцелевого анализа рисков [9]

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

Д-р Расул Мехдизаде разработал методологию динамического, многомасштабного и многопрофильного управления рисками строительных проектов.[9] Этот метод основан на применении специализированных структур разбивки рисков (RBS), которые хорошо адаптированы к: (1) стадии и степени развития проекта, (2) конкретным требованиям и целям заинтересованных сторон проекта и (3) требуемый уровень детализации. Используя этот метод, каждый из участников проекта на каждом этапе проекта, учитывая его / ее особый взгляд на риски проекта, может построить свое собственное конкретное RBS. Более того, RBS также может быть адаптирован для совместной поддержки всех заинтересованных сторон проекта, чтобы облегчить понимание и обсуждение рисков проекта. Используя эти специализированные RBS, которые генерируются с использованием уникальной базы данных процедур и знаний, каждый из заинтересованных сторон проекта может идентифицировать, анализировать и представлять риски проекта в отношении своей точки зрения и требований. Метод обеспечивает согласованность всех этих точек зрения.

Использование иерархической иерархической структуры рисков

RBS служит больше, чем просто «базой данных» для определения рисков для проекта. После создания RBS предоставляет средство для анализа рисков и отчетности, а также сравнения рисков по проектам. Самое главное, RBS - это «инструмент» для выявления рисков.[10][11]

Идентификация и классификация рисков

Выявление рисков будет первым шагом в определении того, какие риски могут повлиять на проект. Идентификация также обеспечивает документирование характеристик риска. Первый уровень (Уровень 1) RBS может использоваться как санитарная проверка чтобы убедиться, что все темы, которые могут включать риски, охвачены в процессе идентификации рисков. Используя RBS, можно инициировать итеративный процесс, который будет сохраняться на протяжении всего жизненного цикла проекта. Частота и применимость этого итеративного процесса будут разными на каждой фазе жизненного цикла.[12]

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

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

Анализ риска

Качественный анализ рисков

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

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

  • Тип подверженности риску
  • Зависимости между рисками
  • Корневая причинность рисков
  • Наиболее значимые и наименее значимые риски
  • Корреляции между рисками [13]

Еще одно преимущество RBS - это способность фокусировать ответные меры на риски с высокой вероятностью, высоким воздействием и высоким приоритетом, используя тематические группировки рисков.[14]

Д-р Мехдизаде разработал особый метод для: (1) расчета значений риска событий риска относительно различных целей проекта, (2) агрегирования значений риска через ветви RBS, а также (3) расчета глобальной оценки риска проекта. .[9] Метод последовательно сочетает в себе количественный и качественный подходы, позволяя пользователю выбрать лучший для оценки риска на любом уровне на основе доступной информации и требуемой точности. В этом методе на первом этапе количественно или качественно оцениваются вероятность и факторы воздействия событий риска. Используются две сопутствующие шкалы: непрерывная кардинальная шкала и дискретная порядковая шкала в диапазоне от 1 до 5. Каждая шкала имеет свои преимущества. Непрерывная шкала ближе к физической реальности и имеет более конкретное значение, в то время как дискретная шкала имеет сильное символическое значение. Оценки, основанные на каждой из этих шкал, могут быть преобразованы в другую в соответствии с определенным процессом. На втором этапе рассчитываются значения риска событий риска, которые затем агрегируются через филиалы RBS для расчета значений риска категорий риска. Наконец, применение многокритериального метода принятия решений позволяет рассчитать глобальную оценку риска для каждой категории. Этот метод обеспечивает более последовательный подход для получения более реалистичных результатов, не страдая от обычных недостатков доступных методов, цитируемых в литературе.

Резюме

Эффективный Управление рисками требует, чтобы руководитель проекта и менеджер риска полностью понимали риски проекта. Успешный процесс управления рисками также потребует хорошего знания и понимания бизнес-целей проекта. При идентификации рисков можно выявить большой объем рисков. Простое перечисление этих рисков или их занесение в электронную таблицу или базу данных не дает глубокого понимания выявленных рисков, необходимого для решения задачи надежного планирования реагирования на риски. RBS предоставляет инструмент, необходимый для помощи в выявлении рисков, их анализе и создании успешного плана реагирования на риски, а также предоставляет средство для «глубокого погружения» в сложность риска. Использование иерархического RBS, аналогичного по своей структуре WBS, дает менеджерам проектов и риск-менеджерам возможность тщательно выровнять риски по надлежащим категориям, используя настолько глубокий анализ, насколько позволяют время и ресурсы.[15]

Смотрите также

Рекомендации

  1. ^ PMBoK-Книга знаний по управлению проектами
  2. ^ PMI Стандарт практики управления рисками - в настоящее время в разработке
  3. ^ NIST Руководство по управлению рисками для систем информационных технологий http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf
  4. ^ Процедурные требования НАСА 8000.4: Процедурные требования управления рисками http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=8000&s=4
  5. ^ PMI PMBOKр Глава 11, Управление рисками «Архивная копия». Архивировано из оригинал на 2008-11-04. Получено 2008-11-12.CS1 maint: заархивированная копия как заголовок (связь)
  6. ^ МЭК 62198: 2001 Управление рисками проекта - Руководство по применению Международная электротехническая связь, Женева, Швейцария
  7. ^ http://certifedpmp.wordpress.com/2008/10/11/risk-breakdown-structure-rbs/
  8. ^ http://www.risk-doctor.com/pdf-files/rbs1002.pdf
  9. ^ а б c Динамическое и многопрофильное управление рисками строительных проектов с использованием индивидуальных структур риска http://ori-oai.u-bordeaux1.fr/pdf/2012/MEHDIZADEH_RASOOL_2012.pdf
  10. ^ Лев Вирин и Майкл Трампер. Решения по проекту: искусство и наука. (2007). Концепции управления. Вена. VA
  11. ^ Питер Саймон и Дэвид Хиллсон, Практическое управление рисками: Методология ATOM (2012). Концепции управления. Вена, VA.
  12. ^ Руководство по непрерывному управлению рисками, Ричард Л. Мерфи, и другие., SIE / Carnegie-Mellon University Press.
  13. ^ op cit Хиллсон,
  14. ^ Вирин Л. и Трампер М. Анализ рисков проекта стал до смешного простым. Мировое научное издательство. 2017 г.
  15. ^ Институт управления проектами, Специальная группа по управлению рисками (SIG), http://www.risksig.com/