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

Авдошин Сергей Михайлович

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

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

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

Рис. 10. Пример SWOT-анализа для идентификации рисков ИТ-проекта

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

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

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

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

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

2) определить

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 3.

Структурная декомпозиция рисков ИТ-проекта 

4.2. Качественная и количественная оценка рисков