Информатизация бизнеса. Управление рисками
Шрифт:
Процедура идентификации рисков должна проводиться регулярно на протяжении жизненного цикла ИТ-проекта для выявления упущенных и новых образовавшихся потенциальных рисков. Мероприятия по выявлению рисков могут привязываться к временному графику (например, быть ежедневными, еженедельными или ежемесячными) или вехам проекта.
После формирования плана управления рисками начинается этап идентификации рисков, на котором определяются риски, способные повлиять на проект, и документируются характеристики этих рисков. Идентификация рисков – это итеративный процесс, который периодически повторяется на всем протяжении проекта, поскольку в рамках его жизненного цикла могут обнаруживаться новые риски. Поэтому процедура идентификации рисков должна проводиться регулярно на протяжении реализации проекта для выявления упущенных и новых образовавшихся потенциальных рисков. В идентификации
В рамках процесса идентификации рисков ИТ-проекта необходимо:
• определить, какие риски могут повлиять на проект;
• обеспечить итеративный процесс выявления рисков;
• организовать методы идентификации и совещания по проекту;
• анализировать все возможные допущения и ограничения;
• анализировать сильные и слабые стороны, угрозы и возможности;
• обеспечить своевременное и полное документирование рисков проекта;
• обеспечить четкие и своевременные коммуникации.
В идентификации рисков должно быть задействовано как можно больше участников: менеджеров проекта, заказчиков, пользователей, независимых специалистов, – поскольку требуется понимание миссии проекта, его предметной области, целей заказчика, инвестора и других заинтересованных лиц.
Для сбора информации о рисках могут применяться различные подходы. Среди этих подходов наиболее распространены:
1) обзор документации;
2) метод мозгового штурма;
3) метод Дельфи (Delphi);
4) SWOT-анализ;
5) интервью (опросы экспертов);
6) контрольные списки;
7) анализ предположений/сценариев;
8) причинно-следственные диаграммы;
9) структурирование рисков с использованием структурной декомпозиции риска.
Обзор документации. Метод используется для первоначального ознакомления с проектом и предполагает проведение обзора существующих документов группой управления рисками проекта, включает структурированный анализ плана проекта и имеющихся предложений (ограничений) как на уровне всего проекта, так и на уровне отдельных работ.
Исходные данные для выявления и описания характеристик рисков могут браться из разных источников. В первую очередь это база знаний организации. Информация о выполнении прежних проектов может быть доступна в архивах предыдущих проектов. Следует помнить, что проблемы завершенных и выполняемых проектов – это, как правило, риски в новых проектах.
Другим источником данных о рисках проекта может служить разнообразная информация из открытых источников, научных работ, маркетинговая аналитика и другие исследовательские работы в данной области. Наконец, многие форумы по программированию могут дать бесценную информацию о возникших ранее проблемах в похожих проектах (рис. 9).
Среди документов, которые могут быть эффективно использованы с целью идентификации рисков для максимально полного списка рисков, предлагаются следующие документы:
• устав проекта;
• структурная декомпозиция работ;
• описание продукта;
• расписание проекта;
• предполагаемые затраты и сроки;
• ресурсный план;
• план поставок;
• список предположений и ограничений.
Дополнительно может использоваться документация предыдущих проектов и доступная внешняя информация – коммерческие базы данных, учебные пособия, специализированные издания, открытые публикации по похожим проектам и прочее.
При анализе планов проекта проводится анализ соответствия задач по плану договорным документам и ранее принятым соглашениям, соответствия выделяемого времени масштабам задач, возможности управлять и контролировать работы по представленному плану, анализ процедур взаимодействия, методологий и подходов к работе и порядка выполнения работ.
Рис. 9. Процесс выявления рисков согласно методологии MSF
Каждый проект задумывается и разрабатывается на основании ряда гипотез, сценариев и допущений. Как правило, в описании содержания проекта перечисляются принятые допущения – факторы, которые для целей планирования считаются верными, реальными или определенными без привлечения доказательств. Неопределенность в допущениях проекта следует также обязательно рассматривать в качестве потенциального источника возникновения рисков проекта. Анализ допущения позволяет идентифицировать риски проекта,
Метод мозгового штурма. Метод «мозгового штурма» – наиболее распространенный метод идентификации рисков. Цель – составить перечень возможных рисков, которые позднее могут быть отобраны в процессе окончательного формирования списка рисков. При использовании этого метода организуются встречи с наиболее квалифицированными специалистами, которые высказывают свои идеи по рискам проекта.
На первом этапе все члены команды называют риски, которые кажутся им наиболее актуальными. Все предложения записываются без обсуждения, это продолжается до тех пор, пока есть идеи, которые можно записать, или до наступления определенного срока. Встреча может оказаться более удачной, если участники подготовятся заранее, выбрав определенные категории рисков. На втором этапе происходит обсуждение предложенных рисков. Оставляют только те риски, которые команда признала интересными для дальнейшего рассмотрения. Встречи проходят без перерыва и без комментариев по поводу суждения каждого – споры и замечания не допускаются. Затем риски группируются по типам и их характеристикам, им даются определения.
Основным недостатком этого метода является то, что на встречах участники не имеют возможности выступить анонимно, что может повлиять на качество результата, в случае если участник боится выступить с идеей, обратной мнению начальника или более авторитетного лидера.
Метод Дельфи. Метод Дельфи позволяет достичь единогласия экспертов и специалистов в области управления рисками. В данном методе используется группа экспертов от семи до десяти человек. Метод во многом похож на метод мозгового штурма, однако есть важные отличия. Во-первых, при применении этого метода эксперты участвуют в опросе анонимно. Метод предполагает анонимное заполнение анкет или опросников экспертами с последующей корректировкой оценки на основании обработанных комплексных результатов экспертизы. Все участники опроса определяются заранее, но в экспертизе выступают, не встречаясь друг с другом. Поэтому результат характеризуется меньшей субъективностью, меньшей предвзятостью и меньшим влиянием отдельных экспертов. Во-вторых, опрос экспертов проводится в несколько этапов. На каждом этапе ведущий рассылает анкеты, собирает и обрабатывает ответы. Полученные результаты рассылаются экспертам для уточнения с учетом мнения других экспертов. Каждый эксперт имеет возможность ознакомиться с комплексными результатами экспертизы, а затем дать новую, более взвешенную оценку. Согласованный список рисков может быть получен в результате нескольких итераций заочных согласований. В итоге получается список рисков в порядке их важности, основанный на независимом мнении каждого привлеченного эксперта. Данный метод позволяет достичь некоего общего мнения специалистов о рисках, а также уменьшить необъективность, предвзятость анализа и преждевременное влияние отдельных членов группы на мнения других экспертов. Недостатком этого метода может являться сложность реализации всех этапов.
SWOT-анализ. SWOT-анализ (Strength, Weaknesses, Opportunities and Threats) – оценка качеств проекта ИТ с точки зрения сильных и слабых сторон, возможностей и угроз. SWOT-анализ обеспечивает анализ проекта с каждой из перечисленных сторон, чтобы сформулировать предположения об основных угрозах реализации проекта в целом.
Так, например, при проведении SWOT-анализа сильные стороны (Strength) описывают более развитые, проработанные составляющие проекта ИТ, такие как наличие опыта персонала в подобных проектах, наличие требуемых навыков и квалификаций, наличие бесперебойных технологий, обеспечивающих достижение целей проекта ИТ. Слабые стороны (Weakness) описывают составляющие проекта, представляющие угрозу своей неясностью, неполнотой, слабой проработкой или организацией, например нечеткая постановка целей или нежелание сотрудников переходить на новые технологии. Возможности (Opportunities) представляют возможности по стратегии реализации проекта, дополнительные преимущества, получаемые за счет минимизации затрат и максимизации результата, такие как уменьшение трудозатрат за счет использования более развитых информационных технологий, обеспечение безопасности данных или увеличение скорости обмена информацией между сотрудниками. Угрозы (Threats) определяют факторы, которые могут помешать выполнить проект с плановыми результатами либо вообще сделать его реализацию невозможной, бессмысленной, невыгодной и т. д., например несовместимость технологий, невозможность переноса данных из одной системы в другую, прекращение финансирования проекта в результате административной реформы и организационных изменений (рис. 10).