1.2 Управление рисками при проведении проекта по интеграции системы

Проведя анализ этапов интеграции системы, были выявлены основные факторы риска проекта интеграции учетно-управленческой системы⁹:

а) Факторы риска на этапе принятия решении об интеграции программно-аппаратных средств системы,

б) Факторы риска при выборе компании интегратора и консультанта,

в) Факторы риска на этапе составления плана по интеграции системы,

г) Факторы риска на этапе внедрения,

д) Долгосрочные факторы риска.

Для наиболее объективного анализа рисков необходимо пристальнее остановиться на этапе составления плана по интеграции системы [33] (Приложение 2). Под этим этапом, как заказчики, так и исполнители часто понимают совершенно разные вещи. Для увеличения точности анализа рисков необходимо произвести декомпозицию выбранного этапа на следующие составляющие:

Этап анализа и сбора требований Заказчика и Разработка рамочного технического задания (ТЗ). На этом этапе происходит сбор необходимой информации для формирования требований на разработку системы. Итогом этого этапа является документ, в котором описаны основные требования к системе, без декомпозиции и детализации. В «Рамочном ТЗ» должны быть указаны основные параметры требований и характеристики системы¹⁰: стоимость владения ERP системой, продолжительность внедрения: срок с момента принятия решения об интеграции системы до её запуска в промышленную эксплуатацию и т.д. В совокупности документ должен отражать основные требования Заказчика к системе или другими словами - общую информацию о предстоящем проекте [9]:

а) Общую информацию о документе и его составителях;

б) Цели и задачи системы;

в) Описание пользователей системы, их цели и задачи;

г) Рамки проекта по интеграции системы;

д) Информационная архитектура системы: карта системы, шаблоны, описание интерфейса;

е) Описание контента системы;

ж) Описание функционала системы;

и) Описание процесса и майлстоунов, если требуется;

к) Перечень всевозможных требований при разработке системы и верификации полученной работы.

Этап описания бизнес-процессов и разработки технического задания (ТЗ)¹¹.

ТЗ разрабатывается Исполнителем в результате плотного взаимодействия с Заказчиком. Определяются и фиксируются все существенные требования (функциональные/ нефункциональные); проводится оценка трудоемкости, а, следовательно, и стоимости проекта с погрешностью в 15-20%. ТЗ тщательно согласовывается с заказчиком и является основным приложением договора между сторонами. Впоследствии ТЗ декомпозируется на задачи, которые затем заносятся в трекер (например, Pivotal Tracker) для их последующего выполнения, тестирования и подтверждения.

Этап разработки Технического проекта (ТП). Этот документ описывает разрабатываемую систему с максимального количества срезов\ ракурсов¹². ТП разрабатывается исключительно для внутреннего использования. Отражает математические, информационные, технические и организационные детали реализации разработанных требований, так же содержит логику совокупной архитектуры системы. Обычно представлен как один документ, описывающий основные требования проекта; так же к нему пришиваются небольшие документы, описывающие требования для реализации конкретных задач, полученных на этапе декомпозиции.

Математическое обеспечение. Исследует логику, по которой функционирует система: определяются наиболее эффективные алгоритмы, формулы и показатели, описывающие выбранную систему.

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

Программное обеспечение. Этот срез обычно представляется одним документом (ЕОСТ 19.20178 от 01.01.80). В данном документе описывается при помощи, каких программных средств выполняется логика из математического и информационного среза. В стандарте предоставлено полное и подробнейшее описание этого документа.

Техническое обеспечение. Данный срез представлен большим количеством проектной документации: по стандарту всего 22 документа (ЕОСТ 2.114-95). Стандарт предусматривает описание всего технического окружения, включая ПК пользователей, локальные сети, инженерные системы и даже строительную часть (при необходимости).

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

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

Основные виды и признаки риска¹⁴:

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

б) технические риски, возникающие при простое системы по причине её временной неработоспособности, либо, когда система не выполняет поставленных задач по причине недостаточной производительности.

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

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

д) правовые риски - возможность изъятия товарно-материальных ценностей компании при вероятности оценки проекта как незаконного.

Для разработки классификатора рисков проекта по интеграции можно использовать следующие методы:

Анализ и определение необходимой информации из базы известных рисков.

Организационные элементы проекта (ОЭП), отвечающие за этот процесс, анализируют базу рисков и определяют из неё наиболее подходящие по специфике для оценки интеграции системы.

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

Диверсионный анализ. Нанятые консультанты или ОЭП ставят себя на место элементов ближней и дальней внешней среды (в зоне контроля и в сфере влияния) способных принести ущерб проекту. Обычно этот метод проводится синхронно с мозговым штурмом¹⁵.

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

Метод Дельфи. Метод заключается в привлечении к оценке рисков проекта независимых экспертов (от 10 до 20) из разных областей и с разной специализацией, но в рамках проекта. Эксперты обязательно должны работать по отдельности, т.е. нужно по максимуму исключить их взаимодействие в процессе заполнения письменного теста. В последствии теста передаются ответственному лицу, структурируются ответы тестов, готовятся промежуточные и окончательные результаты тестов экспертов.

На этапе оценки риска необходимо определить ключевые из них. Для каждого риска необходимо оценить его Вероятность Свершения и Возможную Величину Последствия по балльной шкале (таблица 1.1)¹⁶.

Произведение этих значений будет определять вес риска:

а) Вероятность риска (probability of risk) - вероятность свершения риска. Является одной из характеристик риска; для его оценки могут использоваться целые числа от 1 до 4 (где 1 - низкая вероятность, 4 - высокая вероятность)

б) Последствия риска (risk consequences) - определяет значение возможной величины понесенных убытков в случае свершения риска. Является одной из характеристик риска и может измеряться целыми числами от 1 до 4 (где 1 -малое влияние, 4 - блокирующее влияние).

в) Вес риска (risk weight) - это произведение вероятности наступления риска на балльное значение возможных последствий в случае его свершения.

Таблица 1.1 Матрица для оценки веса рисков.

Вероятность риска/ Последствия риска	Малое влияние=/	Среднее=2	Критическое=Л	Блокирующее влияние=4
Высокая вероятность =4	4	8	12	16
Средняя Вероятность=3	3	6	9	12
Низкая вероятность=2	2	4	6	8
Очень низкая вероятность=1	1	2	3	4

На этапе планирования рисков фактически должно проводиться управление рисками, должна разрабатываться стратегия их оптимизации на основании расставленных приоритетов (Приложение 2)¹⁷. На основании анализа литературы по управлению рисками было сделано решения остановиться на трех стратегиях:

Снятие ответственности за последствия риска посредством её передачи третьей стороне (компания-партнер, страховая компания). Имеет смысл использовать эту стратегию, если сам исполнитель не может повлиять на риск.

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

Ответственность принимаем на себя. Для противодействия риску разрабатывается следующие виды планов: стратегические, для того, чтобы снизить риск, и оперативные, на случай если риск все-таки свершился и оказывает влияние на проект:

а) Стратегический план необходимо внедрять до свершения риска. Фактически проводятся мероприятия, направленные на снижение вероятности наступления риска. Для объективного контроля необходимо составить таблицу рисков с причинно-следственной связью «причина-риск-эффект». Для снижения Вероятности риска, нужно воздействовать на его причину. Чтобы снизить/ликвидировать Последствия, нужно мониторить и контролировать элемент, на который он воздействует.

б) Оперативный план внедряется в случае, если меры по борьбе с риском не принесли результатов, риск случился и стал проблемой. Проводятся мероприятия, направленные на устранение/снижение последствий риска в случае его свершения¹⁸.

В заключение хотелось бы добавить, что совокупность 4х стадий управления рисками представляет собой некоторый цикл управления рисками (аналогично циклу Деминга). Цикл управления рисками необходимо периодически повторять для наиболее объективного регулирования рисков; периодичность проведения цикла управления рисками устанавливается в зависимости от сроков выполнения проекта.