|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
|
|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Microsoft Solutions Framework Дисциплина управления рисками MSF вер. 1.1Стр 1 из 13Следующая ⇒
Microsoft Solutions Framework Дисциплина управления рисками MSF вер. 1.1 Содержание АННОТАЦИЯ......................................................................................................................................................................... 2 ВВЕДЕНИЕ............................................................................................................................................................................. 3 ОСНОВНЫЕ СВЕДЕНИЯ О РИСКАХ.......................................................................................................................... 4 БАЗОВЫЕ ПРИНЦИПЫ.................................................................................................................................................... 4 КЛЮЧЕВЫЕ КОНЦЕПЦИИ............................................................................................................................................ 6 ПЛАНИРОВАНИЕ УПРАВЛЕНИЯ РИСКАМИ........................................................................................................ 9 ПРОЦЕСС УПРАВЛЕНИЯ РИСКАМИ...................................................................................................................... 10 ВЫЯВЛЕНИЕ РИСКОВ................................................................................................................................................... 12 АНАЛИЗ И ПРИОРИТЕЗАЦИЯ РИСКОВ................................................................................................................. 19 ПЛАНИРОВАНИЕ РИСКОВ.......................................................................................................................................... 28 МОНИТОРИНГ РИСКОВ................................................................................................................................................ 33 КОРРЕКТИРОВАНИЕ СИТУАЦИИ........................................................................................................................... 36 ИЗВЛЕЧЕНИЕ УРОКОВ ИЗ РИСКОВ....................................................................................................................... 37 УПРАВЛЕНИЕ РИСКАМИ КАК СОСТАВНАЯ ЧАСТЬ ЖИЗНЕННОГО ЦИКЛА ПРОЕКТА.............. 42 УПРАВЛЕНИЕ РИСКАМИ НА ПРЕДПРИЯТИИ................................................................................................... 43 УПРАВЛЕНИЕ ПОРТФЕЛЕМ ПРОЕКТОВ............................................................................................................ 44 ЗАКЛЮЧЕНИЕ................................................................................................................................................................... 45 Microsoft Solutions Framework ”Белая книга” (white paper) Опубликовано: июнь 2002г. Для получения дальнейшей информации по MSF, см. http: //www.microsoft.com/msf
Составители Allison Robin, директор, Microsoft Solutions Framework David Preedy, менеджер программы, Microsoft Solutions Framework Derick Campbell, менеджер продукта, Microsoft Solutions Framework Enzo Paschino, менеджер программы, Microsoft Solutions Framework Laura Hargrave, технический редактор, Microsoft Frameworks Marijke Born, выпускающий менеджер, Microsoft Frameworks Nancy Huber, технический редактор, Microsoft Frameworks Paul Haynes, менеджер программы, Microsoft Solutions Framework Pervez Kazmi, менеджер программы, Microsoft Solutions Framework Rob Oikawa, менеджер программы, Microsoft Solutions Framework Scott Getchell, менеджер программы, Microsoft Solutions Framework Рецензенты Brian Carter, консультант, MCS National Practices Brian Willson, консультант по стратегиям в автомобильной промышленности, MCS Great Lakes David Millet, ведущий консультант, MCS NorCal Dolph Santello, ведущий консультант, MCS Northeast Francis Delgado Millan, менеджер-методист, Microsoft Enterprise Services Joseph Lopesilvero, главный менеджер проекта, Microsoft Project Management Office Paulo Henrique Leocadio, старший ведущий консультант, MCS Brazil Paulo Rocha, ведущий консультант, MCS New Zealand Rick Varvel, ведущий консультант, MCS PacWest Ron Stutz, управляющий консультант, MCS Rocky Mountain Paulo Rocha, Microsoft Consulting Services, New Zealand Anthony Saxby, Microsoft Consulting Services, UK Ralph Schimpl, Microsoft Consulting Services, Austria Ron Stutz, Microsoft Consulting Services, US Brian Willson, Microsoft Consulting Services, US Andres Vinet, Microsoft Consulting Services, Chile Перевод на русский язык Станислав Бусыгин, научный консультант, eLine Software, Inc., Украина/США Ольга Палий, консультант, eLine Software, Inc., Украина/США Редактор русского перевода Владимир Павлов, технический директор, eLine Software, Inc., Украина/США
Рецензенты русского перевода Андрей А. Терехов, исполнительный директор ЗАО ЛАНИТ-ТЕРКОМ, Россия Иля Фортунов, старший архитектурный консультант, Microsoft Enterprise Services, UK Виталий Шорин, преподаватель, УЦ ИТ, Академия Народного Хозяйства при Правительстве РФ, Россия
Аннотация Управление рисками (risk management) – это одна из ключевых дисциплин Microsoft Solutions Framework ® (MSF). MSF видит в изменениях и возникающей из-за них неопределенности неотъемлемые части жизненного цикла информационных технологий. Дисциплина управления рисками в MSF (MSF risk management discipline) отстаивает превентивный подход к работе с рисками в условиях такой неопределенности, непрерывное оценивание рисков и использование информации о рисках в рамках процесса принятия решений на протяжении всего жизненного цикла проекта. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием шестишагового процесса для успешного активного управления рисками. Этот процесс включает в себя выявление и анализ рисков; планирование и реализацию стратегий по их профилактике и смягчению возможных последствий; отслеживание состояния рисков и извлечение уроков из обретенного опыта.
Введение MSF описывает процесс непрерывного выявления и оценки рисков, их приоритезации и реализации стратегий по превентивному управлению рисками на протяжении всех фаз жизненного цикла проекта, описываемого моделью процесса MSF (MSF process model).1 В данном документе представлены основные концепции дисциплины управления рисками MSF. Эта дисциплина предлагает принципы, идеи и методики успешного управления рисками IT-проектов, формализованные в виде шестишагового процесса. После прочтения данного документа проектная группа, имеющая опыт применения MSF, должна быть способна превентивно управлять рисками IT-проектов. Тем же, кто не знаком с процессом управления рисками в IT-проектах, этот документ дает базовое понимание концепций, терминологии и принципов, необходимое для внесения собственного вклада в управление рисками во всем жизненный цикле IT-проектов. Дисциплина управления рисками MSF заимствует хорошо известную модель процесса непрерывного управления рисками, разработанную Software Engineering Institute (SEI)2, 3. При этом интерпретация этой модели дается в контексте обширного опыта Microsoft, Microsoft Consulting Services (MCS) и партнеров Microsoft в разработке программных продуктов и внедрению IT-проектов. Дисциплина управления рисками MSF возводит процесс управления рисками проектов в ранг стратегической задачи IT- предприятия, затрагивающей все фазы проектов. При этом уделяется особое внимание извлечению уроков из опыта предыдущих проектов. В рамках MSF управление рисками – это процесс выявления, анализа и превентивной работы над рисками в целях избежания их превращения в проблемы, приносящие ущерб или иной вред. Дисциплина управления рисками MSF имеет нижеследующие определяющие характеристики: · Она всеобъемлюща и принимает во внимание все составляющие проектов: людей, бизнес-процессы и технологические элементы. · Она включает в себя пошаговый, систематический и воспроизводимый процесс управления рисками проекта. · Ее использование непрерывно на протяжении всего жизненного цикла проекта. · Она превентивна и не исходит из идеологии действия по факту случившегося. · Она вовлекает как отдельных работников, так и предприятие в целом, в непрерывное извлечение уроков из полученного опыта. · Она обладает достаточной гибкостью и способна интегрировать в себя множество различных методологий качественного и количественного анализа рисков.
Основные сведения о рисках Управление рисками, присущими проектам, является существенной составляющей управления проектами в целом. Большинство людей увязывает понятие риска с потенциальным ущербом в ценности, управляемости, функциональности, качестве или же своевременности завершения проекта. Кроме того, итогом проекта может быть недополучение той прибыли, возможность получить которую имелась изначально. При этом неопределенности, повлиявшие на принятие решений, явившихся причиной таких результатов, также могут быть отнесены к элементам риска. В MSF риск проекта (project risk) понимается широко – как всякое событие или условие, которое может оказать позитивное либо негативное влияние на итоги проекта. Такое расширенное понимание спекулятивного риска (speculative risk) присутствует в финансовой индустрии, где решения в условиях неопределенности могут привести к получению прибыли точно так же, как и к убыткам. Это противоположно понятию чистого риска (pure risk) в индустрии страхования, где неопределенности связываются только лишь с потенциальными убытками в будущем.4 Риски отличаются от проблем и трудностей, так как они имеют отношение к будущим, потенциально возможным негативным результатам и убыткам. Проблемы же и трудности представляют собой нечто, имеющее место в настоящее время. Риски могут стать проблемами, если ими эффективно не управлять. В рамках MSF управление рисками рассматривается как процесс их выявления, анализа и эффективной превентивной работы над ними. Цель управления рисками – максимизировать положительное их влияние (открывающиеся возможности), но при этом минимизировать связанные с ними негативные факторы (убытки). Эффективный процесс выявления и управления рисками помогает достичь разумных компромиссов между упомянутыми опасностями и открывающимися возможностями. Проекты в области информационных технологий (IT) обладают специфическими характеристиками, в силу которых эффективное управление рисками становится жизненно важным для их успеха. Рыночная конкуренция, эволюция технических стандартов, равно как и другие факторы, могут заставить работающую над проектом группу модифицировать принятые планы и решения в середине проекта. Изменяющиеся требования пользователей, новый инструментарий и новые технологии, растущие угрозы для информационной безопасности, текучесть кадров – все это дополнительные факторы, способные повлечь за собой изменения в IT-проекте и заставить проектную группу принимать решения в условиях неопределенности (риска). Jim McCarthy писал: “Практически на каждой стадии даже самых успешных проектов по разработке программного обеспечения существует большое количество важнейших вещей, о которых ничего не известно” (из книги “Динамика разработки программного обеспечения”, 1995, стр. 99) 5. Базовые принципы Дисциплина управления рисками в MSF основана на убеждении, что такое управление должно производиться превентивно; это часть формального и систематического процесса, трактующего усилия, затрачиваемые на управление рисками, с позитивной точки зрения. В основе этой дисциплины лежат все центральные для MSF принципы, идеи и методики, вносящие свой вклад в эффективное управление рисками проектов.6 Тем не менее нижеследующие принципы MSF особенно важны для дисциплины управления рисками.
Проявляйте гибкость – будьте готовы к переменам Постоянная возможность изменений – это один из главных источников неопределенности, с которой приходится иметь дело проектной группе. Меры по управлению рисками не должны ограничиваться какой-либо одной фазой жизненного цикла проекта. Зачастую группа начинает работу с твердым намерением систематически осуществлять управление рисками от начала и до конца проекта, но под прессингом временных ограничений оказывается не в состоянии это сделать. “Гибкость” (agility) требует от проектной группы постоянной оценки и превентивного управления рисками на всех фазах жизненного цикла проекта, так как непрерывные изменения во всех аспектах проекта влекут за собой непрерывные изменения в его рисках. Превентивный подход позволяет команде воспользоваться изменениями и превратить их в новые возможности, не допуская негативных, разрушительных последствий, к которым эти изменения могли бы привести в противном случае.
Поощряйте свободное общение MSF предполагает открытость в обсуждении рисков как внутри проектной группы, так и с ключевыми заинтересованными лицами (stakeholders), находящимися вне ее. Все члены проектной команды должны участвовать в обнаружении и анализе рисков. Для стимулирования такого всеобщего участия руководство всех уровней должно способствовать установлению позитивной и доброжелательной атмосферы. Открытое, честное обсуждение связанных с проектом рисков ведет к более точной оценке состояния проекта и более обоснованному принятию решений, как в рамках проектной группы, так и со стороны руководства и спонсоров.
Извлекайте из всего уроки MSF исходит из того, что, концентрируя внимание на непрерывном самосовершенствовании и извлечении уроков из накопленного опыта, можно достичь большего успеха. Знания, полученные в рамках одного проекта, могут помочь при принятии решений в условиях недостатка информации в другом проекте, для чего эти знания должны быть доступны всем сотрудникам предприятия. MSF подчеркивает важность извлечения организацией уроков из каждого проекта путем интеграции соответствующих мероприятий в процесс управления рисками. Фокусирование внимания на опыте завершившихся проектов стимулирует взаимообучение путем открытого обмена накопленных знаний между проектными группами.
Ключевые концепции В этом разделе мы рассмотрим понятия риска и управления риском, являющиеся ключевыми для понимания дисциплины управления рисками MSF.
Риск - неотъемлемая часть всякого проекта или процесса Несмотря на то, что различные проекты могут быть связаны с большим или меньшим числом рисков, не существует ни одного проекта, полностью свободного от них. Проекты инициируются для того, чтобы организация могла получить некоторый результат, вносящий вклад в достижение цели ее существования. При этом всегда существуют неопределенности, связанные как с природой проекта, так и с внешними условиями, оказывающими влияние на успешное достижение искомого результата. Всегда помня о невозможности полностью избежать рисков, профессионалы MSF постоянно ищут пути разумных компромиссов между рисками и потенциальными возможностями и не становятся на путь абсолютной минимизации риска ценой исключения всего остального.
Постоянная оценка Многие профессионалы в области IT воспринимают управление рисками в лучшем случае как необходимую, но тягостную задачу, которую нужно решать только на начальном этапе работы над проектом или при возникновении новых условий ведения бизнеса. Непрерывные изменения в проекте и окружающих обстоятельствах требуют от проектной группы регулярной переоценки известных рисков и модификации планов по профилактике и смягчению последствий возникновения проблем, связанных с этими рисками. Проектные группы также должны постоянно следить за появлением новых рисков. Управление рисками должно быть интегрировано в общий жизненный цикл проекта. При этом должна существовать возможность внесения необходимых изменений в планы и действия по управлению рисками без создания отдельной системы мониторинга и отчетности.
Планирование управления рисками Во время проектных фаз выработки концепции (envisioning) и планирования (planning) коллектив должен разработать формальный документ, описывающий управление рисками данного проекта. В нем необходимо дать ответы на следующие вопросы: · В рамках каких допущений и ограничений производится управление рисками? · Как будет реализовываться процесс управления рисками? · Из каких шагов состоит этот процесс? · Какие именно действия, роли участников и их обязанности, результаты характеризуют каждый шаг? · Кто будет осуществлять действия по управлению рисками? · Какие для этого требуются навыки/квалификация? · Требуется ли дополнительное обучение? · Как управление рисками данного конкретного проекта соотносится с действиями, производимыми на уровне всего предприятия? · Какой инструментарий и какие методики будут применены? · Какой терминологический аппарат будет использован для классификации и оценки рисков? · Какова процедура приоритезации рисков? · Как будут строиться планы управления рисками и планы мероприятий по смягчению возможных негативных последствий (contingency plans)? · Как деятельность по управлению рисками будет интегрирована в общий план проекта? · Какие действия будут предпринимать отдельные члены проектной группы для управления рисками? · Как информация о положении дел будет распространяться внутри проектной группы? Среди заинтересованных в проекте сторон (stakeholders)? Каков механизм отчетности? · Как будет производиться мониторинг прогресса? · Какая инфраструктура (базы данных, программные инструменты, хранилища информации) будет использована для обеспечения процесса управления рисками? · Каковы риски процесса управления рисками? · Какие ресурсы доступны для управления рисками? · Каковы временные ограничения в мероприятиях, связанных с управлением рисками? · Кто является спонсором, и какие присутствуют заинтересованные стороны? Планирование управления рисками не должно рассматриваться в отрыве от процесса планирования всего проекта, и деятельность по управлению рисками не должна восприниматься как “дополнительная” нагрузка к той “основной” работе, которую выполняют члены проектной группы. Поскольку риски являются неотъемлемой частью всех фаз всех проектов от начала и до конца, должны быть изначально выделены и должным образом распределены ресурсы, необходимые для эффективного управления рисками. Планирование управления рисками осуществляется проектной группой во время фаз выработки концепции и планирования (в рамках модели процесса MSF8), и результирующий план управления рисками должен определять конкретные действия (задачи), ответственность за которые возложена на определенных членов проектной группы. Эти задачи должны быть интегрированы в сводный план проекта (master project plan) и в сводный календарный график проекта (master project schedule). Процесс управления рисками Общее представление Дисциплина управления рисками MSF отстаивает превентивное управление рисками, непрерывную оценку имеющихся рисков и интеграцию этих процессов в общую деятельность по принятию решений на протяжении всего жизненного цикла проекта или бизнес-процесса. Над риском ведется непрерывная и активная работа до тех пор, пока он либо исчезает, либо превращается в проблему, с которой необходимо справиться. Процесс управления рисками MSF, представленный на рис. 1, определяет шесть логических шагов, посредством которых проектная группа управляет текущими рисками, разрабатывает и исполняет стратегии управления рисками и извлекает уроки из своего опыта для использования на уровне всего предприятия. Шесть этапов процесса управления рисками MSF – это · Выявление · Анализ и приоритезация · Планирование · Мониторинг · Корректирование · Извлечение уроков. Выявление рисков (risk identification) – это фаза, позволяющая членам проектной группы вынести на обсуждение всей команды факты наличия рисков. Выявление рисков является начальной стадией процесса управления ими. Оно должно быть
осуществлено как можно раньше, и к нему необходимо постоянно возвращаться на протяжении всего жизненного цикла проекта. Рисунок 1. Процесс управления рисками MSF Анализ рисков (risk analysis) – это фаза преобразования накопленных во время предыдущего шага оценок и данных в форму, позволяющую осуществить приоритезацию рисков. Приоритезация рисков (risk prioritization) позволяет проектной группе производить управление наиболее важными из них, выделяя для этого необходимые ресурсы. Планирование рисков (risk planning) производится исходя из информации, полученной на этапе их анализа, и имеет своей целью выработку стратегий, планов и конкретных шагов. Календарное планирование рисков (risk scheduling) интегрирует эти планы в повседневный процесс управления проектом, обеспечивая непрерывность управления рисками. Эта стадия напрямую увязывает планирование рисков с планированием проекта в целом. Мониторинг рисков (risk tracking) производится для наблюдения за конкретными рисками и прогрессом в осуществлении составленных планов. Мониторингу должны быть подвергнуты сделанные оценки вероятности (probability) риска, его угрозы (impact), ожидаемая величина риска (exposure) и прочие факторы, способные повлиять на приоритет рисков. Наблюдению подвергаются также составленные планы, имеющиеся ресурсы и принятый календарный график. Мониторинг рисков обеспечивает прозрачность процесса управления рисками проекта на различных уровнях в дополнение к стандартному процессу управления проектом, отслеживающему степень завершенности проектных задач. Отчетность о рисках (risk reporting) обеспечивает информирование проектной группы, спонсоров и других заинтересованных сторон о состоянии рисков проекта и планов по управлению ими. Корректирование ситуации (risk control) представляет собой процесс исполнения принятых в отношении рисков планов и контроля за ходом их исполнения. Этот процесс также включает в себя инициирование изменений всего проекта (project change control requests), если изменения в состоянии рисков либо в соответствующих планах влияют на прогнозируемый объем работы, требуемые ресурсы или сроки. Извлечение уроков (risk learning) формализует процесс усвоения накопленного за время работы над проектом опыта в форме, доступной для использования как внутри проектной группы, так и на уровне всего предприятия. Заметим, что описанные фазы являются логическими шагами и они не обязательно для каждого из рисков должны следовать друг за другом в строгом хронологическом порядке. Проектные группы могут циклически повторять шаги выявления-анализа- планирования по мере обнаружения дополнительных факторов, влияющих на проект. При этом извлечение уроков может производиться лишь время от времени на уровне всего предприятия. Далеко не все риски проходят циклически через все приведенные выше шаги. Дисциплина управления рисками MSF полагает, что в каждом конкретном проекте на этапе планирования должно быть определено, когда и как процесс управления рисками инициируется, и при достижении каких условий происходит переход от одной фазы процесса управления рисками к другой как в отношении отдельных рисков, так и для различных их групп.
Выявление рисков Введение Выявление рисков является начальным шагом процесса управления рисками MSF. Чтобы проектная группа могла приступить к их анализу и планированию, необходимо изначально выявить и четко и однозначно сформулировать имеющиеся риски. Выявляя риски, проектная группа должна уделить внимание максимально широкому кругу факторов. В частности, должно быть проведено исследование и выявление неучтенных особенностей проекта и той среды, в которой он будет разрабатываться, так как они могут существенно повлиять на проект или даже стать причиной его неуспеха. На рис. 2 показаны исходные данные, используемые на шаге выявления рисков, получаемый результат, а также предпринимаемые действия.
Цели Целью фазы выявления рисков является создание проектной группой списка имеющихся рисков проекта. Этот список должен быть всеобъемлющим (comprehensive), охватывающим все факторы, влияющие на проект.
Исходные данные Исходными данными фазы выявления рисков являются имеющиеся знания как об общих, так и о специфических для данного проекта рисках, связанных с бизнесом, технологиями, организациями и внешними условиями. Дополнительные факторы, которым должно быть уделено внимание: имеющийся у команды опыт, применяемые внутри организации подходы к рискам, выраженные в виде правил и инструкций, а также вся информация о проекте, известная на данный момент, включая его историю и текущее положение дел. Проектная группа может также использовать любые другие источники – должно быть задействовано все, что может помочь выявлению рисков. На начальном этапе проекта с целью выявления рисков полезно проводить мозговые штурмы, дискуссии или даже формальные семинары с участием различных заинтересованных лиц для ознакомления с их взглядами на риски и открываемые
проектом возможности. Также могут оказаться полезными отраслевые схемы классификации рисков, такие как таксономия рисков SEI9, проектные чеклисты (checklists)10, сводные отчеты о предшествующих проектах и другие опубликованные источники и отраслевые руководства. Рисунок 2. Выявление рисков Шаги по выявлению рисков В процессе выявления рисков проектная группа старается четко сформулировать и перечислить все имеющиеся в проекте риски. На начальной стадии проекта может быть организован семинар или мозговой штурм с целью выявления рисков, возникающих в новых условиях. К сожалению, многие организации смотрят на эту деятельность как на одноразовое мероприятие, которое производится в начале и не повторяется на протяжении жизненного цикла проекта. Дисциплина управления рисками MSF отстаивает иную точку зрения, в соответствии с которой выявление рисков должно производиться регулярно, на протяжении всего проекта. Мероприятия по выявлению рисков могут привязываться к временному графику (например, быть ежедневными, еженедельными или ежемесячными), вехам (milestones) проекта или даже специфическим событиям (связанным с существенными изменениями в сфере бизнеса, технологий, менеджмента или внешней среды). Такие периодические мероприятия по выявлению рисков должны выполняться в соответствии с планами проектных групп. К примеру, выявление глобальных рисков проекта всей проектной группой может быть увязано с главными вехами проекта, но отдельные члены проектной группы в рамках областей своей компетенции могут производить выявление рисков повторно на промежуточных вехах (контрольных точках) проекта или даже в соответствии с некоторым еженедельным графиком. Во время первых шагов по выявлению рисков проекта особую важность представляет взаимодействие между членами проектной группы и другими заинтересованными сторонами, так как оно позволяет выявить различные взгляды на положение вещей и противоречия между ними. Для этого необходимо привлечь группы заинтересованных лиц и участников проекта с самыми различными интересами, опытом и профессиональными навыками. Процесс выявления рисков может также включать в себя исследовательскую работу, проводимую проектной группой, либо привлечение со стороны экспертов в предметной области проекта с целью получения больших знаний о специфически свойственных ей рисках.
Структурированный подход Везде, где только это возможно, MSF рекомендует использовать в процессе управления рисками структурированный подход. В проектах по разработке и внедрению программного обеспечения использование классификаций рисков на этапе выявления предоставляет ясно определенный, воспроизводимый и поддающийся оценке подход. Классификация рисков дает основу для стандартизации терминологии, необходимой для мониторинга и отчетности, и является незаменимой для создания базы знаний о рисках на уровне предприятия или всей индустрии. Классификации рисков помогают проектной группе мыслить всесторонне, предоставляя готовую систематизацию всех составляющих проекта, требующих внимания при выявлении рисков. Такая систематизация может быть получена на основании опыта схожих проектов, осуществленных ранее, или же на основании опытных знаний индустрии в целом. Формулировка рисков (risk statement formulation) является основной методикой, применяемой в рамках MSF для оценки проектов, построения приоритезаций рисков и планирования связанной с рисками деятельности.
Классификация рисков Классификации рисков (или категории рисков), иногда называемые таксономиями, предназначены для нескольких целей. Во время выявления рисков они стимулируют видение проектной группой всего многообразия рисков, возникающих из различных составляющих проекта. При проведении мозгового штурма классификации рисков облегчают одновременную работу с большим числом рисков, предоставляя подходящий способ группирования схожих рисков. Они также могут быть использованы в выработке общепринятой в проектной группе терминологии для мониторинга и отчетности о состоянии рисков. В конечном счете, классификации рисков совершенно необходимы для составления баз знаний о рисках на уровне предприятий и целых индустрий, так как они предоставляют инструментарий категоризации всей новой информации и удобного поиска существующих знаний. Следующая таблица показывает высокоуровневую классификацию источников рисков проектов.
Существует множество классификаций общих рисков проектов по разработке программного обеспечения. Хорошо известны и часто цитируются Barry Boehm11, Caper Jones12, и SEI Software Risk Taxonomy13, описывающие источники таких рисков. Также имеются детализованные списки областей рисков, покрывающие определенное количество составляющих проекта. Риски календарного планирования – это одна из общих областей рисков, с которой сталкиваются все проектные группы. Исчерпывающий обзор таких рисков, затрагивающих проекты в области разработки программного обеспечения, был составлен Steve McConnel.14 Проекты в специфических предметных областях, проекты, осуществляемые с применением узкоспециальных технологий, проекты для вертикальных рынков, а также проекты со специфическим конечным продуктом могут содержать хорошо известные риски, уникальные для своей области. Например, в области информационной безопасности существуют риски связанные с кражей, потерей или искажением информации в результате злоумышленного действия или случайного события. Подобные риски обычно именуются опасностями (threats)15, 16. При работе над проектами в таких областях полезно изучить классификации этих специальных рисков или же расширить имеющиеся классификации рисков общего назначения. Это должно обеспечить надлежащую широту мышления проектной группы при выявлении рисков проекта. Прочие источники информации о рисках проектов включают в себя базы данных рисков индустриальных проектов, такие как Software Engineering Information Repository (SEIR)17, и внутренние корпоративные базы знаний о рисках. Формулировки рисков Формулировка риска – это выражение на естественном языке причинно-следственной связи между реально существующим фактором проекта (текущим положением дел) и потенциально возможным, еще не случившимся событием или ситуацией. Первая часть формулировки риска называется условием (condition) и содержит описание существующего фактора или особенности проекта, которые, по мнению проектной группы, могут сделать результат проекта убыточным либо же сократить получаемую от проекта прибыль. Вторая часть формулировки риска называется (по)следствием (consequence). Она описывает ту нежелательную ситуацию, которой следует избежать. Первая и вторая части формулировки связываются такими словами, как “поэтому” и “в результате”, – они описывают не жесткую, но возможную (с вероятностью меньше 100%) причинно-следственную связь. Схематически это показано на рис. 3. Такая форма описания риска удобна тем, что на ранних этапах процесса управления рисками она увязывает последствие риска с видимым (и потенциально контролируемым) его условием. Использование альтернативного подхода, при котором проектная группа не концентрируется на описании условий на фазе выявления рисков, ведет к тому, что на более позднем этапе (при разработке стратегий управления) приходится восстанавливать условия и причины рисков. Заметим, что формулировки рисков не являются предложениями в форме “если-то”. В действительности они представляют собой факты наличия возможных, но еще не случившихся зависимостей. Рассмотрение гипотетических причинно-следственных связей “если-то” может оказать помощь при выработке планов с использованием деревьев альтернатив на этапе анализа и планирования. Однако на этапе выявления рисков задача состоит в обнаружении максимально возможного их числа. Поэтому анализ причинно-следственных связей должен быть отложен до фазы планирования. На
раннем этапе работы над проектом можно встретить огромное количество таких формулировок рисков, которые указывают на недостаточную информированность проектной группы. Это могут быть такие выражения как: “Мы еще не знаем об X, поэтому...” Рисунок 3. Формулировки рисков При формулировании риска проектная группа должна рассматривать как причину потенциально возможного нежелательного исхода, так и непосредственно сам этот исход. Формулировка риска включает в себя видимое положение вещей в проекте (условие) совместно с гипотетической ситуацией, которая может наступить (последствие). В процессе работы по детальному анализу рисков проектная группа должна находить схожести и естественные объединения формулировок тех рисков проекта, которые имеют общую первопричину. Это может быть достигнуто отслеживанием вглубь цепочек причинно-следственных связей, отталкиваясь от каждого из сформулированных условий рисков18. Также полезно отслеживать причинно-следственную связь в противоположном направлении для выявления возможных масштабных эффектов на уровне организации и внешней среды за рамками одного проекта. Это позволяет более полно представить суммарный урон или упущенные возможности, имеющие одно общее условие19. Зачастую оказывается, что одно условие риска влечет за собой множество последствий. Также возможно, что последствие, выявленное в одной составляющей проекта, может оказаться в роли причины/условия в другой составляющей. Подобные ситуации должны регистрироваться проектной группой в форме, позволяющей учесть на этапе анализа существующие между рисками взаимозависимости и взаимодействия. Такие взаимоотношения могут означать, что исчезновение одного риска может привести к ликвидации целой группы зависимых рисков и соответствующим изменениям в состоянии рисков всего проекта. Документирование этих взаимозависимостей на ранней стадии обнаружения рисков способно обеспечить гибкое детальное планирование рисков, эффективно использующее ресурсы проекта для работы над первопричинами и начальными звеньями цепочек причинно-следственных связей. Выявление причинно-следственных связей рисков должно дополняться фазами анализа и приоритезации с дальнейшей перепроверкой взаимозависимостей и первопричин наиболее важных рисков. Результаты Как минимум, в результате процесса выявления рисков должны быть получены их четкие, однозначные и согласованные формулировки, представленные в виде списка рисков. Если риски формулируются как связки условие-последствие в соответствии с рекомендациями SEI20, NASA21 или ранних версий MSF22, 23, то результатом будет набор таких условных формулировок для всех выявленных рисков. Этот список рисков (представленный в табличной форме) служит исходной информацией для следующей фазы процесса управления рисками – анализа. Выявление рисков обычно предоставляет значительный объем дополнительной полезной информации, включая обнаружение первопричин рисков, затрагиваемые стороны и др. Дисциплина управления рисками MSF рекомендует вести запись формулировок выявленных рисков, их первопричин и приносимого ими ущерба в табличной форме. Также полезно классифицировать эти риски по какой-либо существующей таксономии, так как это может помочь пополнить базу знаний предприятия о рисках. В список рисков может также вноситься информация, определяющая контекст риска. Это должно позволить как другим сотрудникам, так и заинтересованным лицам со стороны понять суть произведенной работы по выявлению рисков24, 25, 26. Описание контекста рисков может включать в себя · условия; · ограничения; · обстоятельства; · допущения; · влияющие факторы; · взаимозависимости рисков; · связанные с рисками вопросы; · владельцы подвергающейся риску собственности; · факторы, вызывающие у проектной группы беспокойство. Полученный список рисков (с указанием или без указания условий и первопричин рисков, приносимого ущерба и контекстной информации) будет превращен в главную таблицу рисков на следующем этапе процесса управления рисками. Вот пример такого списка:
Введение Анализ и приоритезация рисков – это второй шаг процесса управления рисками MSF. Анализ рисков трансформирует имеющиеся данные о рисках в форму, облегчающую принятие решений. Приоритезация рисков указывает, какие из них являются наиболее важными и, как следствие, работа над ними должна быть проведена прежде всего.
Во время этого этапа проектная группа рассматривает риски из списка, составленного при их выявлении, задает приоритеты и формирует главную таблицу рисков. Рисунок 4. Анализ и приоритезация рисков Используя эту таблицу, проектная группа может определить самые существенные из рисков - для управления ими надлежит выделить необходимые ресурсы для планирования и реализации соответствующих стратегий. Проектная группа может также выявить столь несущественные риски, что их влиянием можно пренебречь и вычеркнуть их из списка. По ходу работы над проектом и при изменении внешних обстоятельств шаги выявления и анализа рисков должны повторяться, и главная таблица рисков должна обновляться. В ней могут появляться новые риски и исчезать старые, не оказывающие более на проект существенного влияния. Исходные данные и результаты фазы анализа и приоритезации изображены на рис. 4.
Цель Основной целью шага анализа рисков является их приоритезация и определение тех рисков, на которые стоит выделить ресурсы для дальнейшей работы с ними.
Исходные данные Анализ рисков – это трансформация “сырого” списка, составленного на шаге выявления, в главную таблицу рисков. При его проведении проектная группа может использовать как собственный опыт, так и “внешние” источники информации. В качестве таковых могут выступать правила и рекомендации, действующие в организации, базы данных рисков индустрии, имитационные и аналитические модели, а также управленческое звено организации, эксперты предметной области проекта и др.
Процесс анализа рисков Существует много количественных и качественных методик проведения приоритезации рисков. Одна из них, простая и удобная в использовании, заключается в выработке проектной группой коллективных оценок двух общепризнанных параметров каждого из рисков – вероятности (probability) и угрозы (impact). Произведение этих двух величин дает единую метрику риска, называемую ожидаемой величиной (exposure).
Вероятность риска Вероятность риска – это мера возможности того, что последствие риска, описанное в его формулировке, действительно наступит. Вероятность риска должна быть больше нуля, так как иначе он из себя ничего не представляет. Также вероятность риска должна быть меньше 100%, иначе он не содержит неопределенности и представляет собой уже известную проблему. Оценка вероятности и ее применение – достаточно сложная задача. Однако имеющиеся на уровне предприятия или индустрии базы данных о рисках способны помочь получить такие оценки исходя из опыта значительного количества схожих проектов. В большинстве ситуаций проектные группы могут представить собственный опыт и/или имеющиеся в индустрии опытные данные в виде простых и понятных формулировок, которые затем могут быть превращены в числовые значения. Это может быть простейшая градация “низко-средне-высоко”, отображаемая в отдельно взятые численные значения (17%, 50%, 84%), либо же сложные оценки таких выражений как “почти невозможно”, “маловероятно”, “возможно”, “почти наверняка” и т.д. Следующая таблица демонстрирует трехуровневое разделение вероятности
Следующая таблица представляет семиуровневое разделение вероятности
Заметим, что используемое вероятностное значение представляет собой среднее значение из интервала. При помощи таких таблиц можно оценить вероятность на основе имеющейся словесной формулировки или числового интервала. При проведении численного оценивания рисков необходимо использовать для каждого из них один и тот же диапазон, чтобы полученная приоритезация была единообразна. Независимо от используемой методики количественного оценивания неопределенности, проектная группа должна выработать механизм получения единой итоговой оценки вероятности каждого риска, выражающей консенсуальное решение группы.
Угроза риска Угроза риска (risk impact) представляет собой меру серьезности негативных последствий, уровень убытков или оценку потенциальных возможностей, связанных с риском. Угроза должна быть непосредственным числовым выражением последствия риска, описанного в его формулировке. Она может оцениваться в денежных единицах или же по некоторой субъективной шкале. Выражение угроз всех рисков в деньгах имеет то преимущество, что оно будет более понятно инвесторам бизнеса. Финансовые угрозы рисков могут представлять собой долговременные расходы на функционирование и сопровождение продукта, уменьшение доли компании на рынке, кратковременные затраты на дополнительную работу или же цену возможностей. В иных ситуациях предпочтительна субъективная пятибалльная или десятибалльная шкала для оценки угрозы рисков. Для применения простых методик приоритезации рисков в главной таблице рисков необходимо указать величины угрозы всех рисков в одинаковых единицах. Поэтому полезно иметь таблицы преобразования специфических единиц измерения, таких как время и деньги, в значения, которые могут быть сопоставлены с субъективными единицами оценок, используемыми другими методиками анализа рисков. Пример показан в следующей таблице.
Такой подход позволяет сравнивать угрозы рисков различных проектов предприятия. Данная конкретная шкала представляет собой логарифмическую величину, при которой оценка угрозы берется примерно равной log10(сумма)-1. Большие значения соответствуют большим денежным суммам. Когда фискальные единицы не могут быть применены, проектная группа может использовать другие шкалы оценки угрозы, охватывающие необходимые составляющие. К примеру, Hall (1998) предлагает следующий подход27:
Система оценки воздействий должна отражать политику и ценности организации и проектной группы. Убыток размером $10, 000 может быть терпимым для одной проектной группы или организации, но совершенно недопустимым для другой. Для учета рисков с очень малой вероятностью (но большой угрозой) необходимо, чтобы шкала угроз была достаточно широкой, включающей катастрофические исходы.
Ожидаемая величина риска Ожидаемая величина риска (risk exposure) показывает общий уровень опасности риска, вбирая в одну числовую величину информацию о возможности реализации риска и уровне его угрозы. Проектная группа может затем использовать эту величину для приоритезации рисков. В простейшем случае количественного анализа рисков ожидаемая величина вычисляется как произведение вероятности риска и его угрозы. Когда для оценки вероятности и угрозы используются шкалы, может быть полезным создать матрицу возможных сочетаний значений этих шкал и разделить риски по категориям – на малые, средние и большие. К примеру при использовании трехзначной шкалы для вероятности и угрозы, возможные значения ожидаемой величины могут быть представлены такой таблицей:
Преимущество табличной формы представления уровней рисков заключается в том, что в отчетах для спонсоров и других заинтересованных лиц различные группы рисков могут быть выделены различными цветами. Например, красным – большие риски (в правом верхнем углу), желтым – средние риски вдоль диагонали, и зеленым – малые риски в нижнем левом углу. Такое разделение очень четко и легко понимаемо (“большой риск” воспринимается легче, чем “большая ожидаемая величина”).
Результаты Анализ рисков предоставляет проектной группе приоритезированный список рисков, который необходим на этапе планирования. Дисциплина управления рисками MSF называет его главной таблицей рисков (master risk list). Детальная информация о рисках, включающая в себя условия проекта, контекст, первопричину риска, использованные в процессе анализа значения оценочных величин и др., может быть вынесена для каждого риска в отдельный документ.
Главная таблица рисков Главная таблица рисков содержит условие возникновения риска, потенциальный эффект риска (последствие) и информацию, используемую для приоритезации (такую как вероятность, угроза и ожидаемая величина). Будучи отсортированной по убыванию ожидаемой величины рисков (или по иному критерию, используемому для ранжирования), эта таблица служит базисом для приоритезации рисков на этапе планирования. Пример главной таблицы рисков при использовании двухпараметрической оценки (вероятность и угроза) приведен ниже.
Малая угроза = 1, средняя угроза = 2, сильная угроза = 3 Ожидаемая величина = Вероятность Х Угроза Уровень детализации главной таблицы рисков соответствует уровню детализации изначального списка рисков. Эта таблица является ”живым” документом, лежащим в основе непрерывного процесса управления рисками. Она должна постоянно корректироваться и дополняться на протяжении этапов анализа, планирования и мониторинга. Главная таблица рисков – это фундаментальный документ, обеспечивающий активный и превентивный процесс управления рисками. Она помогает проектной группе в принятии решений, предоставляя основу для: · процесса приоритезации; · выявления критических мер, которые необходимо предпринять; · выявления взаимозависимостей. Ниже приведен список элементов, включаемых в главную таблицу рисков. Метод, использованный для определения ожидаемой величины риска, должен быть четко описан в плане управления рисками. Производимые в нем вычисления должны отражать точку зрения проектной группы на оценку важности различных факторов.
Документ описания риска Во время анализа риска (как и во время последующего планирования относящихся к риску мероприятий) удобно свести всю информацию, имеющую отношение к данному риску, в один документ, называемый документом описания риска (risk statement form). Этот документ обычно содержит данные из главной таблицы рисков, которые дополняются информацией, необходимой для проведения процесса управления риском. Документы описания рисков уместно рассматривать отдельно от главной таблицы рисков в случае, если плановые мероприятия по управлению рисками поручены не входящим в проектную группу лицам или коллективам. В следующей таблице представлена информация, которую проектная группа должна учесть при составлении документа описания риска.
Список главных рисков Анализ рисков дает оценку значимости каждого из них, что помогает решить, какие именно риски заслуживают внимания. Управление рисками требует временных и иных затрат и “отвлекает” сотрудников от другой деятельности, поэтому проектной группе важно выделить именно те из рисков, управление которыми абсолютно необходимо. Выделение списка главных рисков - простой способ проведения эффективного мониторинга. Список главных рисков должен быть доступен для всех заинтересованных сторон и может включаться в документы отчетности, такие как описание и рамки проекта (vision/scope document), план проекта (project plan) и отчеты о текущем состоянии проекта (project status reports). Обычно проектная группа выявляет ограниченное число главных рисков, над которыми следует вести работу (для большинства проектов не более 10) и выделяет ресурсы именно на них. Даже если у проектной группы возникает намерение управлять более чем 10-ю главными рисками, имеет смысл сконцентрироваться только на самых главных рисках, и лишь после того, как они взяты под контроль, переходить к менее критичным. По окончании приоритезации рисков проектная группа должна сконцентрироваться на выработке стратегии управления и включении соответствующих планов в общий план проекта.
Деактивация рисков Риски могут быть деактивированы – признаны несущественными на данный момент. Это позволяет проектной группе сосредоточиться на других рисках, действительно требующих активного управления. Классификация риска как несущественного означает, что проектная группа сочла неоправданными какие-либо затраты усилий на его мониторинг. Решения по деактивации принимаются на этапе анализа рисков. Некоторые риски деактивируются в силу их неправдоподобности, т.е. практически стабильной нулевой вероятности. Другие могут быть деактивированы, так как имеют очень малую угрозу, т.е. более выгодным оказывается принятие возможного ущерба, нежели затраты усилий на управление. Заметим, что не рекомендуется деактивировать риски, угроза которых выше определенного порога, если только проектная группа не является абсолютно уверенной в том, что их вероятность (а, следовательно, и ожидаемая величина) останется низкой при любых непредвиденных обстоятельствах. Также заметим, что деактивация рисков не тождественна их разрешению. При определенных обстоятельствах деактивированный риск может появиться вновь, и проектная группа решит опять принять его во внимание и осуществлять управление им.
Планирование рисков Рисунок 5. Планирование рисков На этапе планирования рисков (третьем этапе процесса управления рисками), основываясь на имеющейся таблице главных рисков, происходит построение планов конкретных действий. Планирование (planning) включает в себя разработку детальных стратегий и мероприятий в отношении каждого из главных рисков, приоритезацию этих мероприятий и создание сводного плана управления рисками. Последующее календарное планирование (scheduling) включает в себя интеграцию задач управления рисками в общий календарный график проекта. Задачи из плана управления рисками поручаются определенным членам проектной группы, и их выполнение подвергается активному мониторингу. Этот этап схематически изображен на рис. 5. На этом шаге в главной таблице рисков фиксируется дополнительная информация о наиболее приоритетных и значимых рисках. Иногда удобнее вынести эту информацию в отдельные документы, используемые членами проектной группы, ответственными за соответствующие риски.
Цели Основная цель шага планирования рисков – разработка детальных планов управления главными рисками, выявленными во время анализа, и обеспечение исполнения этих планов посредством их интеграции в общие процессы управления проектом.
Исходные данные Дисциплина управления рисками MSF предполагает тесную интеграцию процесса планирования рисков с другими стандартными проектными процессами планирования и обеспечивающими их средствами. Исходные данные процесса планирования рисков включают в себя не только главную таблицу рисков, список главных рисков и базу знаний о рисках, но также общие проектные планы вместе с календарными графиками проекта.
Мероприятия При разработке планов по сокращению ожидаемой величины риска: · концентрируйте внимание на рисках с большой ожидаемой величиной; · для понижения вероятности направляйте свою деятельность на причину риска; · ищите первопричины, а не боритесь с симптомами; · для сокращения угрозы направляйте свою деятельность на последствие; · после определения первопричины, ищите схожие риски, которые могут следовать из анализируемой первопричины; · помните о взаимозависимостях и взаимодействиях рисков. Некоторые подходы, применимые к сокращению рисков: · используйте доступные ресурсы для сокращения тех рисков, с которыми проектная группа в состоянии справиться сама; · для рисков, находящихся вне контроля проектной группы, найдите возможные обходные пути для их сокращения или передайте управление этими рисками лицам, имеющим необходимые полномочия (эскалация). Планируя конкретные действия, проектная группа должна рассмотреть шесть следующих возможных подходов: · Исследование (research). Достаточно ли мы знаем о данном конкретном риске? Должны ли мы лучше изучить его, чтобы получить о нем больше информации и определить его характеристики до того, как мы предпримем какие-либо действия? · Принятие (accept). Можем ли мы пережить последствия риска, если они все- таки наступят? Можем ли мы принять риск и не предпринимать по этому поводу никаких дальнейших действий? · Избежание (avoid). Можем ли мы избежать риска, изменив способ действия? · Перенос (transfer). Можем ли мы перенести риск на другой проект, проектную группу, организацию или частных лиц? · Предотвращение (mitigation). Можно ли сделать что-то заранее для уменьшения вероятности риска или его угрозы? · Смягчение последствий (реагирование, contingency). Может ли угроза риска быть уменьшена путем планирования некоторой реакции на него?
Исследование Многие из рисков связаны с неопределенностями, порожденными неполной информированностью. Они могут быть эффективно разрешены после дополнительного изучения связанной с ними предметной области. Например, до окончания составления плана проектная группа может принять решение о проведении маркетингового исследования, чтобы больше узнать об имеющихся у пользователях базовых навыках и об их желании использовать новые технологии. В случае решения о проведении исследований план управления риском должен включать в себя описание этих исследований, включая формулировки проверяемых гипотез и изучаемых вопросов, необходимое кадровое обеспечение и лабораторное оборудование.
Принятие Природа некоторых рисков такова, что лучшим решением является их принятие для реализации открываемых ими возможностей, так как просто не существует эффективных превентивных или коррективных мер. Принятие не есть бездействие. План управления рисками должен включать в себя обоснование того, почему проектная группа избрала принятие риска, а не выработку мер по его предотвращению и смягчению последствий. Имеет смысл продолжить мониторинг таких рисков на случай изменения их вероятности, угрозы или появления новой возможности управления. Для обеспечения мониторинга должны быть выделены необходимые ресурсы, и он должен основываться на метриках, установленных в рамках процесса по управлению рисками проекта.
Избежание Возможно, выявленный риск может быть разрешен наилучшим образом некоторыми изменениями в самом проекте (его рамках, scope), исключающими существование риска. В таком случае план управления рисками должен включать в себя обоснование изменения, и оно должно быть также отражено в плане самого проекта. Кроме того, должны быть инициированы мероприятия, необходимые для претворения принятого изменения в жизнь.
Перенос Иногда возможно передать управление риском третьей стороне, непосредственно не участвующей в проекте. Примерами таких случаев являются: · страхование; · найм сторонних консультантов с большим опытом работы; · покупка готовой компоненты вместо ее создания собственными силами; · привлечение внешних субподрядчиков. Перенос риска не обязательно означает его исчезновение. В общем случае перенос риска породит другие риски, требующие превентивного управления, но имеющие приемлемый уровень. Например, привлечение внешнего консультанта может перенести технологические риски за пределы проектной группы, но породит риски в областях управления и бюджетирования.
Предотвращение План предотвращения риска описывает меры и мероприятия, осуществляемые заблаговременно для предотвращения риска или сокращения его угрозы или последствий до приемлемого уровня. Предотвращение риска, в отличие от избежания, концентрируется на его снижении до приемлемого уровня (избежание означает изменение проекта с целью этот риск обойти). Главная цель предотвращения риска – снижение его вероятности. Например, некоторое дополнительное количество подключений к Internet сокращает риск полной потери доступа в глобальную сеть. Не для каждого риска есть эффективная стратегия предотвращения. В таких случаях целесообразно спланировать меры по смягчению последствий риска.
Результаты Результатом этапа планирования риска должен быть четко построенный план действий, использующий один из шести детально рассмотренных выше подходов. Шаги, реализующие эти планы, должны быть интегрированы в общий план проекта и его календарный график. Это включает в себя специфицирование количества выделяемых ресурсов, расписания и задач, определяющих действия членов проектной группы. Главная таблица рисков должна быть дополнена описаниями планов по предотвращению и реагированию и иной необходимой информацией.
Рисунок 6. Мониторинг рисков Мониторинг рисков (risk tracking) – это четвертый шаг процесса управления рисками MSF. Он важен для эффективной реализации запланированных действий. Мониторинг обеспечивает своевременное исполнение превентивных мер и планов по смягчению последствий. Первоочередная деятельность проектной группы на этом этапе – наблюдение за количественными параметрами рисков и условиями их триггеров с целью отслеживания моментов “включения” запланированных по отношению к риску действий. Мониторинг – это наблюдательная деятельность, предусмотренная составленным ранее планом управления рисками. Процесс мониторинга схематически показан на рис. 6.
Цели Цели фазы мониторинга рисков: наблюдение за прогрессом в выполнении принятых планов (предотвращения рисков и смягчения их последствий) и количественными параметрами (метриками), приводящими в действие триггеры планов смягчения последствий, а также информирование проектной группы о необходимости осуществления планов реагирования в случае активации соответствующих им триггеров.
Исходные данные Основными исходными данными для мониторинга являются: · Подготовленные ранее планы действий в отношении рисков, содержащие описание шагов по предотвращению и смягчению последствий, а также специфицирующие характеристики и количественные триггеры, подлежащие мониторингу. · Любые необходимые отчеты о ходе проекта (из числа используемых для оценки прогресса проекта в рамках стандартной схемы управления проектом). В зависимости от того, к каким количественным параметрам проектная группа применяет мониторинг, могут быть использованы различные дополнительные источники информации. В их число входят базы данных мониторинга проектов, хранилища исходного кода программ и системы регистрации рабочего времени. Даже такие источники, как базы данных отделов кадров, могут быть полезны в получении необходимой для мониторинга информации.
Мероприятия по мониторингу Во время фазы мониторинга проектная группа в процессе своей повседневной работы воплощает в жизнь планы по предотвращению рисков. За прогрессом этой деятельности ведется наблюдение. Также производится наблюдение за изменениями значений триггеров рисков. Все это отражается в отчетах, составляемых для каждого из рисков. Примеры параметров, к которым могут быть привязаны триггеры, и за которыми может проводиться постоянное наблюдение: · Количество “открытых” (найденных и неисправленных) ошибок на один модуль или компонент. · Среднее за неделю количество сверхурочных часов работы на одного сотрудника. · Еженедельное количество изменений в требованиях к разрабатываемой системе. Результаты Цель отчета о состоянии риска – информирование о происходящих изменениях в статусе риска и о прогрессе в осуществлении планов по его предотвращению. Сведения, которые полезно указать в отчете: · Наименование риска. · Классификация риска (к какой области проекта относится). · Исходные оценки вероятности, угрозы и ожидаемой величины. · Текущие оценки вероятности, угрозы и ожидаемой величины. · Уровень риска (низкий, средний, высокий). · Краткое изложение планов предотвращения и смягчения последствий. · Состояние плана предотвращения (завершенные мероприятия). · Готовность плана по смягчению последствий. · Состояния триггеров. · Планируемые действия. · Лицо, ответственное за риск. Цель сводного отчета о рисках, направляемого руководству или внешним заинтересованным сторонам, – доклад об общем состоянии рисков проекта. Полезно включить в такой отчет следующую информацию: · Наименование проекта. · Уровень риска в различных составляющих проекта. · Тенденции изменений в рисках. · Сводка планов по предотвращению и смягчению последствий. Такой отчет обычно включается в общий отчет о состоянии проекта. Корректирование ситуации
Пятый шаг процесса управления рисками MSF – корректирование ситуации (risk control) - предполагает осуществление мероприятий, предусмотренных планами смягчения последствий тех рисков, для которых сработали соответствующие триггеры. Процесс корректирования ситуации изображен на рис. 7.
Рисунок 7. Корректирование ситуации Инициирование корректирующих действий основывается на информации, полученной во время процесса мониторинга. MSF рекомендует использование существующих стандартных механизмов управления проектом для · планирования контроля рисков; · корректировки отклонений от планов; · реакции на достижение триггерных условий. Результаты и уроки, извлеченные из плановых мероприятий по смягчению последствий, включаются затем в отчет о ходе выполнения планов и их результатах. Таким образом соответствующая информация становится частью проектной/корпоративной базы знаний о рисках. При этом необходимо охватить как можно больше информации о возникших проблемах и о деталях осуществления плана, что важно для определения эффективности примененного подхода.
Цель Цель этапа корректирования ситуации – успешное выполнение выработанных ранее проектной группой планов по смягчению последствий главных рисков.
Исходные данные Исходными данными для шага корректирования ситуации являются документы, детально описывающие действия проектной группы, запланированные в отношении рисков, а также отчеты о состоянии рисков, указывающие на активацию триггеров.
Результаты Результатом шага корректирования ситуации является стандартный отчет о состоянии проекта, документирующий прогресс выполнения планов по смягчению последствий рисков. Полезно также кратко изложить извлеченные уроки (например, что возымело действие, а что показало свою неэффективность). Если изменения в текущей картине рисков могут потребовать привлечения дополнительных ресурсов или повлечь изменения в объеме работ и длительности проекта, то должен быть инициирован запрос соответствующего изменения (change control request) (это относится к проектам, использующим формальные процедуры управления изменениями).
Извлечение уроков из рисков Введение Извлечение уроков (learning from risk) – это шестой, заключительный, шаг процесса управления рисками MSF. Он позволяет стратегически оценить мероприятия по управлению рисками с точки зрения предприятия (организации). Этот шаг иногда называют “отдачей от рисков”, подчеркивая все то ценное, что организация приобретает – новые навыки, зрелость проектной группы и организации в целом, совершенствование процесса управления и др. Извлечение уроков может быть начато в любой момент и должно идти непрерывно на протяжении всего процесса управления рисками MSF. На этом шаге важно сконцентрироваться на трех ключевых целях: · Контроль текущего процесса управления рисками, позволяющий проектной группе регулярно получать обратную связь. · Обмен накопленным опытом с другими проектными группами, особенно в отношении выявления рисков и успешных стратегий их предотвращения. Это позволит пополнять существующую базу знаний о рисках. · Усовершенствование процесса управления рисками на основе отзывов и пожеланий проектной группы.
Рисунок 8. Извлечение уроков Для обмена опытом организовывают совещания, посвященные рассмотрению рисков. Они должны проводиться регулярно и, как и все другие совещания в рамках MSF, планироваться заблаговременно, с выработкой ясной и общеизвестной повестки дня. В них должны принимать участие все заинтересованные лица; атмосфера, в которой они проходят, должна быть максимально доброжелательной и демократичной. Шаг извлечения уроков схематически представлен на рис. 8.
Типы извлекаемых уроков Классификация рисков – мощное средство обеспечения доступности извлеченных из предыдущего опыта уроков для тех проектных групп, которые будут осуществлять оценку рисков в будущем. Двумя аспектами извлечения уроков, затрагивающими классификацию рисков, являются: · Новые риски. Если проектная группа столкнулась с проблемой, риск возникновения которой не был выявлен изначально, необходимо проанализировать, существовали ли какие-либо предпосылки ее предсказания, т.е. обнаружения риска. Возможно, существующие списки рисков нуждаются в обновлении, чтобы эффективнее выявлять признаки такого риска в будущем. Если был найден новый риск, его необходимо внести в корпоративную базу знаний. · Успешные стратегии предотвращения рисков. Другой принципиальный момент, который необходимо усвоить в качестве урока – это опыт успешных (или даже неуспешных) стратегий предотвращения рисков. Использование устоявшихся классификаций рисков предоставляет разумный метод группирования схожих рисков. В силу этого проектным группам не составляет труда детально изучить стратегии управления рисками, ранее приводившие к успеху.
База знаний о рисках База знаний о рисках – это формализованный или неформализованный механизм накопления опыта, полезного для осуществления управления рисками в будущем. Не имея такой базы, организация может столкнуться с трудностями при внедрении превентивного управления рисками. База знаний о рисках отличается от базы данных процесса управления рисками, используемой для хранения и мониторинга информации о конкретных рисках, планов по ним и их состоянии в ходе реализации проекта.
Достижение зрелости в управлении знаниями о рисках База знаний о рисках – это ключевой фактор постоянного совершенствования управления рисками. На нижнем уровне зрелости рабочие группы не имеют никакой базы знаний. Любая проектная группа начинает каждый раз процесс управления рисками с нуля. В таких условиях управление рисками, как правило, не превентивно – оно производится по факту случившегося – хотя и может достигнуть более высокого уровня активности. На этом уровне проектная группа обычно не осуществляет профилактических мер при управлении рисками. Следующий уровень зрелости включает использование неформализованной базы знаний, представленной, главным образом, знаниями наиболее опытных членов организации. Зачастую это достигается созданием рабочего органа, ответственного за риски, в котором такие лица наблюдают за работой каждой из проектных групп. Подобный подход поощряет активное управление рисками и может обеспечить некоторую степень его превентивности посредством использования определенных инструкций и требований. Вот пример такой инструкции: “Все проекты, длящиеся дольше 20 дней, должны пройти проверку их рискованности до того, как они будут начаты”. Начальный уровень формализации базы знаний о рисках достигается применением более структурированного подхода к выявлению рисков. Дисциплина управления рисками MSF предлагает применять в этих целях классификации рисков. Вводя формализованные процедуры накопления опыта и его систематизации, организация способна достичь значительно более высокого уровня превентивного управления, так как начинают становиться видимыми исходные причины рисков. Зрелые организации накапливают не только опыт обнаружения признаков, указывающих на вероятный риск, но также и стратегии, применявшиеся для управления рисками вместе с данными об их успешности. При таком уровне развития базы знаний шаги по выявлению и планированию рисков могут основываться на опыте большого числа проектных групп. Это позволяет всей организации оптимизировать расходы на управление рисками и увеличить отдачу от инвестирования в проекты. Опыт показывает, что при создании базы знаний о рисках: · Ее ценность увеличивается с появлением большего числа схожих процессов (к примеру, организация концентрируется на схожих проектах или повторяющихся бизнес-процессах). · Когда организация всегда концентрируется только на одном из проектов, становиться возможным поддержание меньшими усилиями более простой базы знаний о рисках. Управление рисками не должно превращаться в механический процесс, устраняющий для проектной группы необходимость размышлений. Даже в повторяющихся ситуациях условия ведения бизнеса, ожидания заказчиков, профессиональные навыки проектной группы и технологии подвержены непрерывным изменениям. Как следствие, проектная группа всегда должна производить оценку стратегий управления рисками с учетом конкретной специфики проекта.
Заключение Дисциплина управления рисками MSF отстаивает превентивный структурированный подход к управлению рисками разработки и внедрения программного обеспечения. Процесс управления рисками MSF состоит из шести логических шагов (выявление, анализ, планирование, мониторинг, корректирование и извлечение уроков), которые должны постоянно выполняться проектной группой в течение жизненного цикла проекта. Фаза извлечения уроков служит для обмена опытом, связанным с рисками проекта, и для повышения эффективности управления рисками предприятия путем пополнения общей базы знаний о рисках. Информация, содержащаяся в настоящем документе, представляет текущую точку зрения корпорации Майкрософт по обсуждаемым вопросам на момент публикации. В условиях меняющейся рыночной конъюнктуры, требующей соответствующей корректировки ведущихся разработок, данную информацию не следует рассматривать в качестве какого бы то ни было обязательства со стороны Майкрософт; корпорация не может гарантировать точность информации, представленной после даты публикации. Данный обзор носит чисто информативный характер. КОРПОРАЦИЯ МАЙКРОСОФТ НЕ ПРЕДОСТАВЛЯЕТ НИКАКИХ ГАРАНТИЙ, НИ ЯВНО ВЫРАЖЕННЫХ, НИ ПОДРАЗУМЕВАЕМЫХ В СВЯЗИ С ДАННЫМ ДОКУМЕНТОМ. На пользователе лежит ответственность за соблюдение всех применимых в данном случае законов об авторском праве. В целях обеспечения авторских прав никакая часть настоящего руководства ни в каких целях не может быть воспроизведена или передана в какой бы то ни было форме и какими бы то ни было средствами (электронными или механическими, включая фотокопирование и запись на магнитный носитель), если на то нет письменного разрешения корпорации Майкрософт. Предмет данного руководства может быть защищен патентами, патентными заявками, товарными знаками, авторским правом или иным образом в пользу корпорации Майкрософт. Данный документ не дает разрешения на использование этих патентов, товарных знаков или авторского права, если таковое не оговорено явным образом в каком-либо лицензионном соглашении корпорации Майкрософт. © Корпорация Майкрософт (Microsoft Corp.), 2002. Все права защищены. Microsoft является охраняемым товарным знаком корпорации Майкрософт в США и других странах. Названия компаний или продуктов, указанные здесь, могут быть товарными знаками соответствующих владельцев. Перевод данного документа на русский язык был осуществлен в 2003 г. корпорацией eLine Software (http: //www.elinesoftware.com). Другие документы по MSF на русском языке доступны в Internet по адресу: http: //www.microsoft.com/rus/msf.
1 MSF Process Model v. 3.0, 2002 (доступно на http: //www.microsoft.com/msf/) 2 Audrey J. Dorofee, Julie A. Walker, Christopher J Alberts et al, Continuous Risk Management Guidebook (Carnegie-Mellon University, 1996). 3 Ronald P. Higuera, “Team Risk Management: A New Model for Customer-Supplier Relationships”, SEI Technical Report CMU/ SEI-94-SR-5, (Pittsburgh, PA: Software Engineering Institute—Carnegie Mellon University), 1994. 4 Encarta 2002, Статья “Insurance. II. Reasons for Insurance”. 5 Jim McCarthy, Dynamics of Software Development (Redmond, Washington: Microsoft Press, 1995), page 99. 6 Восемь принципов – это: 1. ожидайте изменений – проявляйте гибкость (expect things to change – stay agile); 2. вырабатывайте общее видение (work toward a shared vision); 3. концентрируйтесь на бизнес-ценностях (focus on delivering business value throughout the life cycle); 4. инвестируйте в качество (invest in quality); 5. извлекайте уроки из любого опыта – и положительного, и отрицательного (learn from all experiences – good and bad); 6. поощряйте открытое общение (foster open communication); 7. распределенная ответственность, фиксированная отчетность (clear accountability, shared responsibility); 8. команда, наделенная полномочиями (empowered team). 7 MSF Team Model 3.0 Whitepaper (http: //www.microsoft.com/msf/). 8 См. более детальное рассмотрение в MSF 3.0 Process Model Whitepaper, доступно на http: //www.microsoft.com/msf/ 9 Ronald P. Higuera and Yacov Y. Haimes, “Software Risk Management”, SEI Technical Report CMU/SEI-96- TR-012 ESC-96-012 (Pittsburgh, PA: Software Engineering Institute—Carnegie Mellon University, 1996). 10 К примеру, Steve McConnell, Software Project Survival Guide, (Redmond, WA: Microsoft Press), 1998. 11 Barry W. Boehm, Software Risk Management, (New York, NY: IEEE Press), 1989. 12 Capers Jones, Assessment and Control of Software Risks. (Englewood, NJ: Prentice-Hall, 1994). ISBN 0-13- 741406-4 13 Ronald P. Higuera and Yacov Y. Haimes, “Software Risk Management”, SEI Technical Report, 1996. 14 Steve McConnell, Rapid Development, (Redmond, Microsoft Press), 1996, pp 87-91. 15 Thomas R. Peltier, Information Security Risk Analysis, (Boca Raton: Auerbach Publications, 2001). 16 Donald L Pipkin, Information Security: Protecting the Global Enterprise, (Newark, NJ: Prentice Hall, 2000). 17 http: //seir.sei.cmu.edu/ 18 Одна из эффективных методик мозгового штурма для обнаружения первопричины называется “Пять почему”. Согласно этому подходу, команда должна поставить вопрос “Почему это так? ” по отношению к условию риска, дать ответ и циклически повторить “Почему это так? - Потому что...” до пяти раз.
19 Это может быть достигнуто вариацией методики “5 почему”, при которой команда циклически повторяет вопрос-ответ “Что тогда?..Тогда будет...” до пяти раз. 20 Audrey J Dorofee, Julie A Walker, Christopher J Alberts, et al., Continuous Risk Management Guidebook. (Pittsburgh, PA: Carnegie Mellon University, 1996). 21 Linda H Rosenberg, Theodore Hammer, Albert Gallo, Continuous Risk Management at NASA, 1999 (http: //satc.gsfc.nasa.gov/support/ASM_FEB99/crm_at_nasa.html) 22 MSF Risk Management Process Whitepaper, 2001. 23 Principles of Application Development- Course 593 and Course 1517. 24 Rosenberg LH, et al., 1999. 25 Elaine Hall, Managing Risk. Methods for Software Systems Development, SEI Series in Software Engineering, (Reading, MA: Addison-Wesley, 1998), Ch. 4, “Identify Risk”. 26 Dorfee AJ, et al, 1996. 27 Elaine Hall, Managing Risk, p. 101. 28 Project Management Institute, A Guide to the Project Management Body of Knowledge 2000 Edition, (Newtown Square, PA: Project Management Institute, Inc. 2000), Chapter 11. 29 Elaine Hall, Managing Risk. 30 См. MSF 3.0 Project Management Discipline, доступно на: http: //www.microsoft.com/msf/ Microsoft Solutions Framework Дисциплина управления рисками MSF вер. 1.1 Содержание АННОТАЦИЯ......................................................................................................................................................................... 2 ВВЕДЕНИЕ............................................................................................................................................................................. 3 ОСНОВНЫЕ СВЕДЕНИЯ О РИСКАХ.......................................................................................................................... 4 БАЗОВЫЕ ПРИНЦИПЫ.................................................................................................................................................... 4 КЛЮЧЕВЫЕ КОНЦЕПЦИИ............................................................................................................................................ 6 ПЛАНИРОВАНИЕ УПРАВЛЕНИЯ РИСКАМИ........................................................................................................ 9 ПРОЦЕСС УПРАВЛЕНИЯ РИСКАМИ...................................................................................................................... 10 ВЫЯВЛЕНИЕ РИСКОВ................................................................................................................................................... 12 АНАЛИЗ И ПРИОРИТЕЗАЦИЯ РИСКОВ................................................................................................................. 19 ПЛАНИРОВАНИЕ РИСКОВ.......................................................................................................................................... 28 МОНИТОРИНГ РИСКОВ................................................................................................................................................ 33 КОРРЕКТИРОВАНИЕ СИТУАЦИИ........................................................................................................................... 36 ИЗВЛЕЧЕНИЕ УРОКОВ ИЗ РИСКОВ....................................................................................................................... 37 УПРАВЛЕНИЕ РИСКАМИ КАК СОСТАВНАЯ ЧАСТЬ ЖИЗНЕННОГО ЦИКЛА ПРОЕКТА.............. 42 УПРАВЛЕНИЕ РИСКАМИ НА ПРЕДПРИЯТИИ................................................................................................... 43 УПРАВЛЕНИЕ ПОРТФЕЛЕМ ПРОЕКТОВ............................................................................................................ 44 ЗАКЛЮЧЕНИЕ................................................................................................................................................................... 45 |
Последнее изменение этой страницы: 2019-03-30; Просмотров: 389; Нарушение авторского права страницы
