Информатизация бизнеса. Управление рисками

Анализ предположений/сценариев. Анализ предположений (сетевые методы анализа) – метод, который исследует правильность предположений и затем идентифицирует риски, исходя из правильности, полноты и последовательности предположений. Данный метод идентификации направлен на определение областей, которые могут быть подвержены риску, исходя из правильности, полноты и последовательности предположений о данной области. Анализ предположений производится при аудите документов проекта и позволяет формулировать потенциальные риски, исходя из того, что выдвинутое предположение о проекте может оказаться неверным. Часто для анализа применяется гипотеза «что, если», при помощи которой можно исследовать правильность предположений о ходе выполнения проекта ИТ на каждом этапе жизненного цикла и идентифицировать риски, исходя из правильности, полноты и последовательности предположений. Например, если предположение, что «в ближайшие 5 лет в компании планируется увеличение данных в n раз и для передачи данных достаточно будет использовать сетевой кабель с пропускной способностью» неверно, то существует потенциальный риск невозможности обмена коммуникациями при увеличении информации более чем в n раз.

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

1) определить участников принятия решений и ответственных за возникновение риска (кто принимает решение?);

2) определить последствия неопределенности (на что влияет?);

3) определить характер изменений и способ реагирования на риски (что изменить и как?).

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

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

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

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

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

Рис. 11. Пример причинно-следственной диаграммы для идентификации ИТ-рисков

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

Структурирование рисков с использованием структурной декомпозиции риска (Risk Breakdown Structure, RBS) сформировано по аналогии со структурной декомпозицией работ проекта (WBS) и позволяет группировать риски по источникам появления для определения суммарного воздействия рисков.

Универсальный пример иерархических уровней структурной декомпозиции рисков ИТ-проекта представлен ниже в табл. 3.

Использование данного метода в области ИТ требует большого знания предметной области и наличия достаточной информации.

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

• дать наименование риску и присвоить ему уникальный номер;

• определить ответственного за данный риск;

• описать причины возникновения риска;

• описать последствия наступления риска;

• зафиксировать статус риска (новый/в работе/закрыт).

Таблица 3.