Построение модели идентификации рисков при реализации компонентов системы

Грушин Дмитрий Александрович
ЗАО «БДО Юникон Бизнес Солюшнс»
Ведущий консультант
Г. Москва

По оценке некоторых российских экспертов, вплоть до 60% проектов по созданию информационных систем в России являются провальными и не дотягивают до критериев успешности. Аналогичная статистка приводится и западными специалистами, установив оценку провальных проектов на уровне 43%. При рассмотрении проектов по внедрению продуктов SAP и причин их провалов, одну из причин связанную с не непрофессиональными специалистами можно практически исключить. Принимаем этот факт как следствие того, что на данный момент рынок консультантов SAP достаточно высоко квалифицирован. Ключевой же причиной неудачи многих проектов является полное отсутствие или неэффективное управлениями рисками. Случай с полным отсутствием управлением рисками подробного рассмотрения не требует. Что касается неэффективного управления рисками – одной из центральной проблемой выступает не тот факт, что риски были описаны не достаточно полно или не достаточно качественно, а тот факт, что они не персонифицированы к конкретным заинтересованным сторонам данного проекта, что не позволяет успешно управлять ожиданиями и соответственно рискаим.

Для четкого понимания причин возникновения рисков, приведем основные факторы появления неопределенностей, которые их и порождают:

• Низкая определенность ожидаемого результата и неполнота требований
• Значительное количество настраиваемых и сильно интегрированных компонентов системы, что ведет к многократному увеличения связей
• Принимаемые решения обуславливаются не технической совершенностью, а вынуждены приниматься на основании компромисса
• Высокая динамика обновления законодательной базы, влекущая за собой изменения вплоть до изменений в архитектуре решения

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

При реализации IT проектов, а конкретнее проектов по внедрению информационных систем на базе продуктов SAP, существуют характерные особенности, которые не всегда покрываются классическими процессами управления рисками, описанными в стандарте PMI PMBOK Guide. Среди таких «непокрытых» особенностей главенствующую роль можно отвести тому факту, что большая часть работ заключается в конфигурировании компонентов системы. Что в совокупности с сильной интеграцией этих компонентов порождает большое количество участников, которые способны влиять и изменить эту конфигурацию. Данный аспект рабочего взаимоотношения между заинтересованными сторонами не нашел должного отражения, хотя зачастую может являться основным источником рисков. Ввиду этого и появляется необходимость в построении отдельных моделей для идентификации рисков, в рамках которых будет возможно персонифицировать выявленные риски к конкретным заинтересованным лицам.

Переходя к практической части реализации, необходимо уточнить специфику реализуемого компонента:

• Сильная зависимость от конфигурации смежных модулей реализуемой системы
• Большая динамика изменений в смежных модулях
• Сильная зависимость от данных смежных модулей
• Большая динамика изменений в законодательной базе

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

В результате, для построения нашей модели логично вытекают необходимые и достаточные задачи для эффективной работы:

• Определение требований к функциональной группе
• Выявление направлений влияния на требования:
• Построение структуры заинтересованных сторон
• Построение карты заинтересованных сторон
• Присвоение приоритетов заинтересованным сторонам
• Консолидация вероятных источников рисков
• Построение карты рисков

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

Рисунок 1
Оценив все предъявляемые требования, мы имеем необходимые и достаточные данные для выделения заинтересованных сторон и группировки их по направлению воздействия на функциональную группу и на предъявляемые требования.

Рисунок 2
В результате регистрации и группировки всех стейкхолдеров для нашей функциональной группы, структура заинтересованных сторон выглядит следующим образом:

Рисунок 3
Теперь обладая всей необходимой информацией построим карту заинтересованных сторон с детализацией общих требований:

Рисунок 4

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

Приоритеты фиксируются на карте влияния заинтересованных сторон:

Рисунок 5

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

Таблица 1

В результате данная таблица содержит все необходимые данные для построения кары рисков
Таблица 2

Заключение

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