Глава 2. Оценка рисков проектов системной интеграции в

ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ
ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«Национальный исследовательский университет
«Высшая школа экономики».
Факультет бизнеса и менеджмента
Кафедра инноваций и бизнеса в сфере информационных технологий
ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА
На тему
«Развитие методов и инструментов управления ИТ-проектами
системной интеграции в современном информационном
обществе»
Студентка группы №241-М
Иванова Е.А.
Научный руководитель
доцент, к.т.н.,
Авдеева Зинаида
Константиновна
Москва 2015
Аннотация
Данная выпускная квалификационная работа посвящена вопросу
исследования проектов системной интеграции на российском рынке и
специфики управления такими проектами.
В первой главе работы рассматривается теоретический аспект проектов
системной интеграции, приводится обзор роли таких проектов на ИТ-рынке
России
в
текущем
состоянии.
Для
описания
специфики
проектов
рассматривается окружение проектов и оценка стейкхолдеров.
Вторая часть работы посвящена оценке рисков проектов системной
интеграции. Площадкой для проведения оценки выбрана компания ЗАО
«Софт Лайн Трейд». В главе приведена оценка рисков с использованием
методов, рекомендованных национальным стандартом Российской федерации
ГОСТ Р ИСО/МЭК 31010-201: «Дельфи» для идентификации и сбора рисков
типовых проектов системной интеграции и «матрица последствий и
вероятностей».
В третьей главе работы анализируются методы и инструменты, которые
способны нивелировать риски, выявленные на этапе анализа. В работе
приведены примеры нивелирования рисков управления требованиями:
процесс разработки требований и процесс управления изменениями. Большое
внимание уделено проблеме коммуникационных рисков в проектах системной
интеграции:
произведен
анализ
современных
средств
построения
корпоративной коммуникации, разработана модель нового онлайн-сервиса,
как инструмента нивелирования рисков, связанных с коммуникациями в
рамках проектов системной интеграции.
Abstract
This graduation qualification thesis is devoted to research system integration
projects on Russian market and the specific management process in such projects.
2
The first chapter contains theoretical aspects of system integration projects,
provides an overview of the role of such projects on Russian IT market in the current
state. In order to describe specifics of the project environment and assessment of
stakeholders are considered.
The second part is devoted to risk assessment system integration projects.
Russian IT integration company ZAO «Softline Trade» was chosen as a platform for
risk assessment. The chapter provides risk assessment using methods recommended
by the national standard of the Russian Federation GOST R ISO / IEC 31010-201:
"Delphi" for the identification and collection of risks typical system integration
projects and "matrix effects and probabilities."
The third chapter analyzes work methods and tools, which enable to neutralize
risks identified in the analysis phase. The paper provides examples of risks leveling
requirements management: the process of developing requirements and changes
management process.
Much attention is paid to the problem of communication risks in the system
integration projects: construction of modern corporate communication analysis,
development of a new online service model, as a means of leveling the risks
associated with communications within the system integration projects.
3
Оглавление
Введение ................................................................................................................... 5
Глава 1. Теоретический аспект управления проектами системной интеграции.
Особенности управления проектами системной интеграции ............................. 8
1.1. Теория управления проектами в области информационных систем ......... 8
1.2. Сущность, организационный уровень проектов системной интеграции.
Специфика управления проектами системной интеграции .............................. 10
1.3. Технические аспект проектов системной интеграции .............................. 19
1.4. Выводы по первой главе .............................................................................. 26
Глава 2. Оценка рисков проектов системной интеграции в практике
российских ИТ-компаний..................................................................................... 27
2.1. Методология оценки рисков ........................................................................ 27
2.2. Этап анализа рисков проектной деятельности .......................................... 31
2.3. Выводы по второй главе ............................................................................... 42
Глава 3.Анализ инструментов и методов управления проектами для
нивелирования рисков проектов системной интеграции. ................................. 44
3.1. Методы нивелирования рисков проектов системной интеграции ........... 44
3.2. Анализ инструментов для нивелирования рисков проектов системной
интеграции ............................................................................................................. 52
3.3. Развитие инструментов для поддержки проектной деятельности ............... 64
3.4. Выводы по третьей главе.................................................................................................... 67
Заключение ............................................................................................................ 68
Библиографический список ................................................................................. 70
Приложение 1. Результат проведения идентификации рисков методом
Дельфи ................................................................................................................... 74
Приложение 2. Результат оценки рисков экспертной группой ........................ 77
Приложение 3. Оценка решений унифицированных коммуникаций как услуги
(CaaS) на мировом рынке .................................................................................... 79
Приложение 4. Методы и инструменты нивелирования рисков, выявленных
на этапе анализа .................................................................................................... 82
4
Введение
Российский рынок информационных технологий переживает непростой
период, согласно публикации уточненного прогноза по мировой ИТ-отрасли 9
апреля 2015 года от исследовательской компании Gartner аналитики
прогнозируют снижение объемов мирового ИТ-рынка на 1,3%. [30, стр. 3] На
российском рынке это связано с трудной экономической ситуацией и
девальвацией рубля. Снижение объемов ИТ-рынка также связано с падением
продаж оборудования в России, Западной Европе и Японии. Однако, в рамках
текущий ситуации происходит рост интереса российских компаний к ИТуслугам.
Спрос на ИТ-услуги связан с растущим многообразием и сложностью
используемых корпоративных ИТ-систем, которые требуют больших затрат
на установку, интеграцию, обучение и поддержку. В кризисный период
основной задачей ИТ становится обеспечение эффективности бизнеспроцессов компании за счет использования ИС.
Непростые отношения с Западом лишь подчеркивают необходимость
снижения зависимости России от западных ИТ-систем, укрепления ИТинфраструктуры,
проведение
консалтинговых
проектов
российскими
компаниями особенно в государственном секторе и военно-промышленном
комплексе [23].
Тема исследования становится наиболее актуальной в рамках
изменений, происходящих на российском рынке ИТ-услуг: приоритет в
выборе компаний – исполнителей по проектам системной интеграции и
проведении консалтинговых работ будет отдаваться российским компаниям.
Усовершенствование методов управления проектами системной интеграции,
понимание специфики и рисков таких проектов, а также инструментов по их
устранению является актуальным вопросом для российских компаний ИТсектора.
5
Оценка
современного
состояния
проблемы
и
степень
ее
проработанности. Анализ отечественных и зарубежных источников по
проблемам управления проектами системной интеграции показал, что многие
вопросы, связанные со спецификой таких проектов, остаются незатронутыми.
Проект системной интеграции в первую очередь является проектом и
содержит все основные характеристики управления проектами, однако также
для таких проектов есть специфичные черты, которые заслуживают анализа.
Теория управления комплексными проектами проработана такими
зарубежными авторами как Дункан В.Р, Верзух Э., Клиффорд Ф. Грей, Эрик
У. Ларсон, Тернер Дж.Родни, Ньютон Р.
Среди научных трудов, затрагивающих управление проектами среди
российских ученых можно выделить: Разу М.Л., Мазур И.И, Рогова Е.М,
Алешин А.В., Аньшин В.М., Ковалев А.
Основополагающими стандартами по управлению проектами в мире
являются руководство к своду знаний по управлению проектами - PMBOK,
руководство к качеству при управлении проектами - ISO 10006-97, система
знаний о процессах управления проектами- PRINCE 2.
Также необходимо выделить ряд основных стандартов, определяющих
требования
к
компетенции
руководителей
проектов: международные
требования к компетенции специалистов по управлению проектами (PM ICB),
разработанных Международной ассоциацией управления проектами IPMA
(Швейцария), а также основанный на них российский стандарт
-
Национальные требования к компетентности СОВНЕТ (Россия).
В рамках прохождения преддипломной практики был собран и
проанализирован материал по проектам системной интеграции для типовых
проектов системной интеграции в компании интеграторе ЗАО «СофтЛайн
Трейд».
Объектом исследования является проект системной интеграции на
российском рынке. Предметом исследования являются процесс управления
проектами системной интеграции в российской практике.
6
Целью исследования является выявление рисков управления проектами
системной
интеграции
и
возможностей
для
их
нивелирования
с
использованием современных методов и инструментов.
Задачами исследования являются:
1.
Проанализировать
проект
системной
интеграции
и
его
характерные черты;
2.
Выявить текущие риски проектов системной интеграции в рамках
работы российской компании – интегратора (ЗАО «СофтЛайн Трейд») на
основе экспертной оценки;
3.
Разработать рекомендации по нивелированию рисков проектов
системной интеграции с учетом их специфики, используя рассмотренные
методы и инструменты;
4.
Проанализировать современные технологии и инструменты для
обеспечения распределенной работы в проектной деятельности;
Практическая
значимость
данного
исследования
заключается
в
разработке рекомендаций для нивелирования рисков типовых ИТ проектов
системной интеграции на российском рыке и выявлении потребности этого
сектора в новых сервисах.
7
Глава 1. Теоретический аспект управления проектами системной
интеграции. Особенности управления проектами системной интеграции
1.1.
Теория управления проектами в области информационных
систем
Бизнес-процессы
любого
предприятия
требуют
своевременной
автоматизации и информатизации. Автоматизация происходит посредством
разработки и внедрения информационных систем, позволяющих решать
задачи и достигать поставленные бизнесом цели.
Для бизнеса всегда есть риск понести финансовые потери в случае
прекращения или вынужденной приостановки проектов подобного типа. В
ходе
проекта
важно
соблюдать
баланс
и
отслеживать
следующие
характеристики: качество выполнения проекта, его сроки и стоимость.
Исследовательская организация Standish Group выделяет 10 факторов,
которые препятствуют своевременному завершению проекта по созданию и
развитию информационных систем. Среди этих факторов можно указать три
самых значимых и распространенных [19]:

Недостаточно полная информация получена от конечных
пользователей системы;

Неполные требования и незаконченная спецификация требований;

Изменения в требованиях и в спецификации требований;
В рамках комплексных проектов по разработке, внедрению или
развитию информационных систем риск возникновения таких факторов
повышается. Выполнение этих проектов требует слаженной командной
работы участников проекта, как на стороне компании-заказчика, так и на
стороне исполнителей. Эффективное снижение рисков в данном случае
напрямую зависит от выстраивания процесса управления комплексом
требований.
Свод знаний по управлению проектами PMBoK (Project Management
Body of Knowledge) являющийся суммарным справочным материалом по
8
группам процессов управления дает такое определение термину проект:
«Проект» - временное предприятие, имеющее своей целью создание
некоторого уникального продукта, услуги или достижение конкретного
результата [1, стр. 97-102]. Если дать более развернутую формулировку, то
«проект» представляет собой набор скоординированных и поэтапных
действий, которые ограничены по времени, они имеют фиксированное начало
и конец, требования к качеству и срокам, итогом выполнения которых будет
уникальный результат.
Ключевые характеристики проекта:

Время (у проекта всегда можно выделить начало и конец);

Уникальный результат (результатом всегда выступает что-то
принципиально новое: продукт, услуга, организационная структура и т.д.);

Поэтапность
(последовательность
этапов
проекта
с
промежуточными результатами);
В зависимости от характера деятельности можно выделить несколько
типов проектов в ИТ-сфере:

Разработка программного продукта;

Внедрение программного продукта;

Сопровождение/поддержка программных продуктов;

Проекты, направленные на изменение/совершенствование ИТ-
инфраструктуры;
Согласно классическим подходам в проектном управлении выделяют
четыре основные фазы:

Инициация;

Планирование;

Реализация;

Закрытие;
Жизненный цикл проекта характеризует фазу, которые проходят от
начала проекта до его завершения. Определение жизненного цикла проекта
9
помогает менеджеру проекта решать, как следует разделять фазы проекта и
при необходимости выделить некоторые из них в самостоятельные проекты.
Для
комплексных
специфических
ИТ-
характеристик,
организационного
консалтинга
проектов
т.к.
и
следует
они
выделить
направлены
системной
несколько
на
интеграции.
сочетание
Специфика
управления комплексными проектами возникает по причине того, что этапы
реализации охватывают все слои структуры ИТ компании [5]. Схематичное
изображение структуры представлено на рис. 1.
Рисунок 1. Структура уровней комплексного проекта
1.2.
Сущность, организационный уровень проектов системной
интеграции. Специфика управления проектами системной интеграции
Системная интеграция – объединение отдельных компонентов или
подсистем в одну систему с обеспечением гарантии того, что все подсистемы
будут функционировать совместно как единая глобальная система.
В информационных технологиях понятие системная интеграция – это
процесс
построения
взаимосвязей
между различным оборудованием,
информационными системами и программными приложениями физически
или
функционально
при
помощи
специальных
техник,
таких
как
компьютерные сети, интеграция корпоративных информационных систем,
10
реинжиниринг и проектирование бизнес-процессов, программирование и др.
[31]
Проекты системной интеграции –это разработка комплексных решений
по автоматизации технологических и бизнес-процессов предприятия,
конечной целью таких проектов является максимально эффективное
управление технологическим процессом, основными бизнес-процессами и
организацией в целом [11].
Стадии проекта системной интеграции укрупненно можно разделить на:
1. Анализ;
2. Разработка (Выбор решения);
3. Внедрение;
4. Сопровождение;
Отдельными поддерживающими процессами будут выступать: поставка
программного и аппаратного обеспечения, техподдержка.
Проекты системной интеграции могут быть различны по своей
сложности, объему работ и количеству затрагиваемых систем. Однако, целью
таких проектов всегда выступает получение эмерджентных свойств в новой
единой системе [20].
Эмирджентность может быть получена даже в небольшом проекте,
например, построение системы электронного документооборота в компании
приводит к уменьшению трудозатрат бухгалтеров компании за счет
информационного
обмена
между
оперативной
и
бухгалтерской
информационными системами по сравнению с использованием этих же
подсистем по отдельности.
Типовой пример системной интеграции – это построение единой
корпоративной информационной системы (КИС).
Подсистемами при этом являются:

которые
Сетевая инфраструктура, состоящая из более мелких подсистем,
также
интегрированы
друг
с
другом:
оборудование
телекоммуникации, серверное оборудование, рабочие станции.
11

Информационные системы, которые используются в компании:
ERP, CRM, СЭД, BPM и прочие. Целью построения единой КИС является
интеграция этих информационных систем там, где это возможно. Например,
можно обеспечить сокращение трудозатрат оператора Call-центра, построив
интеграцию телекоммуникационного оборудования Call-центра и CRM.

Системы управления технологическими процессами (SCADA).

Прочие ИТ-компоненты.
Проект системной интеграции, рассматриваемый в рамках данной
работы, представляет собой более сложную деятельность, чем внедрение
отдельных систем, т.к. отдельное решение позволяет решить ограниченное
число бизнес-задач, в то время как при помощи системной интеграции
создается единая КИС, задачей которой является решение большинства
бизнес-задач.
Компания – системный интегратор в ИТ – это компания-подрядчик (по
сути Value Added Reseller), которая извлекает прибыль из добавленной
стоимости компании-заказчика. Добавленная стоимость получается за счёт
интеграции продуктов и снижения издержек. Системный интегратор по
специфике своей деятельности также оказывает консультационные услуги,
услуги по настройке ПО и оборудования.
Компании, занимающиеся проектами системной интеграции должны
иметь в штате высококвалифицированных бизнес-консультантов, которые
могут оценить цель и задачи проекта и в итоге предложить заказчику
комплексное ИТ-решение, которое способно обеспечить автоматизацию
необходимых бизнес-процессов заказчика. Кроме этого внедрением такого
проекта должна заниматься команда квалифицированных инженеров, а также
системный архитектор проекта, который непосредственно отвечает за
построение интеграций между подсистемами и обладает экспертными
знаниями.
12
В качестве площадки для исследования мною была выбрана компания
ЗАО «СофтЛайн Трейд» (торговая марка – Softline), которая является одним
из крупнейших игроков на рынке системных интеграторов России.
Подразделение Softline Solutions внедряет решения для комплексной
автоматизации бизнес-процессов и эффективного управления бизнесом (ERP
- системы от SAP и Oracle) и решения по управлению отношениями с
клиентами (CRM - системы), а также разрабатывает дополнительные
отраслевые модули для CRM-систем, расширяющие их возможности.
Основное направление – это комплексные проекты системной интеграции
[24].
Подразделение Softline Consulting Services занимается построением
полнофункциональной информационной структуры предприятий, внедряет
технологии управления корпоративной информацией, бизнес-анализа и
корпоративных коммуникаций с учетом индивидуальных потребностей
заказчика. Компания ЗАО «СофтЛайн Трейд» осуществляет как отдельно
проекты по оказанию консалтинговых услуг, так и как часть большого
интеграционного проекта.
В период с 2012 по 2014 активно происходит рост рынка системной
интеграции, в первую очередь – это банковская отрасль, телеком и ритейл –
они инвестировали в повышение эффективности своих бизнес- процессов, в
развитие сервисов, т.е. в оптимизацию своих бизнес- процессов с помощью
ИТ. В это время основные игроки рынка активно наращивали свои
компетенции [22].
Далее представлены характерные особенности комплексных проектов
системной интеграции ЗАО «СофтЛайн Трейд».
Компания имеет широкую сеть представительств: 50 городов в России,
странах СНГ и дальнего Зарубежья. Ведение проектов системной интеграции
осуществляет команда специалистов из разных городов. Зачастую, с разницей
в часовых поясах. Компетенции специалистов имеют распределенный
характер, т.е. специалисты, занимающиеся разработкой, определенного
13
программного продукта, либо внедрение продукта, определенного вендора
могут быть в различных городах, кроме того в организационной структуре
занимать разные должности и подчиняться разным руководителям.
При построении проектной команды необходимо учитывать следующие
характерные черты компании и проекта:

Специалисты могут быть из разных городов/регионов/ стран;

Компания-заказчик
может
быть
из
другого
города/региона/страны;

Разница во времени в зависимости от часовых поясов участников
команды проекта и команды компании-заказчика;

Специалисты проектной команды могут быть лично не знакомы и
не иметь опыта совместной работы;

Специалисты параллельно ведут более одного проекта;

Затраты на очные встречи с заказчиком, в случае привлечения
нескольких сотрудников;
Организационные аспект управления и ведения проекта в компании:

Компания имеет сильную матричную организацию, т.е. сочетает в
себе функциональные и проектные характеристики: каждый участник
проектной команды починяется своему Функциональному руководителю,
руководитель проекта подчиняется Начальнику отдела руководителей
проектов. В ходе проекта участники команды проекта подчиняются
Руководителю проекта.

В компании применяется стандарт управления проектами
PMBOKv5.

Руководители
проектов
сертифицированы
по
стандарту
PMBOKv5.
Техническая организация управления и ведения проекта в компании:

Для управления проектами с компании используется платформа
MS Project;
14

Для постановки задач и оперативного взаимодействия также
используется ПО, разработанное компанией, - Work Flow Soft.

Специалисты
используют
современные
средства
для
корпоративной коммуникации: MS Lync, Skype;

Для обмена данными по проекту используется внутреннее
хранилище, организованное при помощи портала Sharepoint, либо сторонние,
например, Яндекс Диск, в случае если в команде проекта участвует
субподрядчики из других компаний;

Основным каналом взаимодействия является – корпоративная
почта на базе MS Exchange;
Для более детального описания проекта системной интеграции
рассмотрим заинтересованные стороны проекта (теория Э.Фримана) – рис.2.
Рисунок 2. Заинтересованные стороны проекта
Для грамотного управления проектами необходимо проанализировать
положение каждого из стейкхолдеров и определить механизмы его вовлечения
в проект и способы управления его действиями для этого составим матрицу
стейкхолдеров на основе таких показателей, как:
1)
фактору
Влияние – это сила стейкхолдера в управлении проектом. К этому
относят
возможность
данного
стейкхолдера
влиять
на
инвестирование проекта, дальнейшее бюджетировании; а также степень
15
влияния на людей, принимающих решения по главным вопросам в ходе
проекта.
2)
Важность – это показатель вклада стейкхолдера в результат
проекта. Определяется тем, насколько решение проблем стейкхолдера может
повлиять на конечный результат проекта. К важности относят, например,
специфичные знания стейкхолдера, а также его потребности, которые должны
быть удовлетворены для того, чтобы проект стал эффективным.
Матрица стейкхолдеров проекта системной интеграции представлена на
рис.3.
Рисунок 3. Матрица стейкхолдеров проекта
Стратегия
«Партнеры»
заключается
в
максимально
возможном
вовлечении стейкхолдеров с высоким уровнем важности и влияния. Это
группа привлекается к принятию ключевых решений в проекте. Необходимо
повышать заинтересованность этой группы и полностью удовлетворять ее
16
потребности.
Для
управления
рекомендуется
использовать
принцип
партнерства в коммуникации при ведении переговоров.
Стратегия
«Консультанты»
имеет
консультативный
характер
и
применяется к группе стейкхолдеров с высоким уровнем важности, но низким
уровнем влияния, т.е. к второстепенным стейкхолдерам. Их необходимо
привлекать в качестве консультантов и согласовывать с ними только
стратегически важные решения.
Стратегия «Поддержка» применяется к группе стейкхолдеров с низким
уровнем важности, но высоким уровнем влияния. заключается в получении
поддержки для проекта. Данная группа должна быть ознакомлена со всеми
ключевыми решениями в ходе проекта, хотя она не принимает прямого
участия в решении данных вопросов. Рекомендуется данную группу
привлекать
к
обсуждению
возможных
проблем
для
обеспечения
дополнительной поддержки по важным решениям.
Стратегия «Временные работники» заключается в игнорировании и
используется для стейкхолдеров с низким уровнем влияния и низким уровнем
важности. Рекомендуется привлекать данную группу к выполнению
требуемых задач, не погружая в детали проекта и использовать самый низкий
уровень информирования.
Далее рассмотрим внутренние и внешние факторы окружения проекта
системной интеграции. К внутренним факторам окружения относятся:

Организационная структура компании;

Стиль руководства;

Организация управления проектами;

Компетенции участников проектной команды;

Организационная коммуникация проектной команды;

Доступность участников проектной команды;

Заинтересованность участников проектной команды;

К внешним факторам окружения относятся:
17

Политический фактор;

Экономический фактор;

Лицензионная политика компаний-вендоров;

Инфраструктура;

Компании-партнеры / субподрядчики;
Выделяют следующие проблемные области в проектах системной
интеграции [27]:

Autonomy (автономность);
o Автономность систем;

Heterogeneity (гетерогенность);
o Технический уровень: различные платформы аппаратного
обеспечения, различные операционные системы, различные
СУБД;
использование
различных
языков
использование
различных
программирования;
o Концептуальный
уровень:
подходов к проектированию архитектур,

Distribution (распределенность);
o Распределенность по серверам;
o Распределенность по приложениям;
o Распределенность по различным компаниям;
На рис. 4 изображено влияние проблемных областей на проект
системной интеграции и методы их нивелирования (пунктирные линии),
рекомендованные лучшими практиками.
18
Рисунок 4. Проблемные области системной интеграции.
Компании интеграторы выполняющие проекты такой сложности
должны обладать следующими характеристиками:

Имеет разработанную методику ведения подобных проектов;

Имеет опыт построения процесса создания системной интеграции
с обеспечением активностей на всех уровнях проекта;

или
Обладает компетенциями, необходимыми для ведения проекта
имеет
возможность
субподрядчиков
для
привлекать
выполнения
проверенных
работ,
когда
и
качественных
компетенций
самого
интегратора недостаточны.
1.3.
Технические аспект проектов системной интеграции
Достаточно крупный интеграционный проект может включать в себя
следующие уровни работ:
19

Технический уровень. В любом случае системная интеграция
включает в себя создание или внедрение конкретного аппаратного и
программного обеспечения. Для обеспечения этого уровня проекта компанииинтеграторы должны обладать дифференциальными компетенциями, т.е.
иметь экспертные знания в каждом из внедряемых продуктов. Например, ERPсистем, Service Desk, основных линеек серверного и телекоммуникационного
оборудования. В ходе проекта особенно важно наличие интегральные
компетенции – наличие в компании экспертов в построении взаимодействия
между различными классами систем, а также имеющих опыт и знания
технологий связывания систем между собой.

интеграции
Управленческий уровень. В состав команды проекта системной
зачастую
входят
более
десятка
сотрудников
компании-
интегратора, а также несколько специалистов компании-субподрядчика. Для
достижения целей проекта руководить разрозненной командой должен
высококвалифицированный менеджер проектов или несколько менеджеров,
каждый из которых может отвечать за часть проекта, но во главе всех
менеджеров стоит главный менеджер проекта. Осложняющим фактором также
выступает то, что интеграционные эксперты зачастую участвуют более чем в
одном проекте одновременно и для управления их доступностью должно
координироваться
надпроектного
функциональными
управления.
руководителями,
Системный
интегратор
т.е.
должен
за
счет
обладать
высокими компетенциями в области управления проектами.

Консалтинговый
интеграционного
проекта
уровень.
необходимо
Для
на
успешного
старте
результата
проекта
четко
сформулировать его цели и задачи, основываясь на бизнес-стратегии и
текущей ситуации в компании заказчика, а также описать архитектуру
создаваемой в ходе проекта КИС и обосновать ее экономическую
эффективность. Для обеспечения этого уровня проекта необходимо наличие у
компании-интегратора специалистов обладающих компетенциями как в
финансовой сфере, так и в технической.
20

Коммерческий и политический уровни. Сложный и длительный
интеграционный проект должен быть экономически рентабелен в первую
очередь для самой компании-интегратора, поэтому в составе проектной
команды должны быть участники, обеспечивающие согласование и
урегулирование финансовых разногласий с руководителями компаниизаказчика. Также стоит учесть, что в рамках крупных интеграционных
проектов зачастую всплывают политические проблемы: лоббированием
собственных интересов в ущерб целям проекта со стороны отдельных лиц
компании-заказчика.
Проект системной интеграции зачастую является вынужденной и
сложной мерой для обеспечения эффективности бизнес-процессов компании.
Есть несколько основных подходов к реализации интеграции [20].
Подход 1: Построение интеграции с нуля. Например, в организации
используются три независимые информационные системы: «Склад» для учета
хранения и перемещения товара на складе, «CRM» учет продаж и ведение
взаимодействий с клиентами организации и «Бухгалтерия». На начальном
этапе между системами нет обмена данными. Выставленные счета в CRM
распечатываются и заносятся в Бухгалтерию вручную. Информация о
поступлении оплаты по счетам отправляется в почте. На складе учет товаров
ведется параллельно с бухгалтерским учетом в разных системах, что приводит
к двойной работе, неактуальной информации и т.д.
Построение информационного обмена и синхронизация данных
позволит компании сэкономить на оплате рабочего времени сотрудника на
выполнение дублирующих функций в системе.
Подход 2: вертикальная интеграция. В соответствии с этим подходом
системы интегрируются по принципу функциональных экспертиз, например,
для функционирования системы «Бизнес-аналитика» необходимо получение
данных, как бухгалтерского, так и оперативного учета. Для этого необходимо
создать
вертикальную
интеграцию
между
двумя
системами
для
предоставления информации системе «Бизнес Аналитика».
21
Подход 2: Интеграция «многие к одному». Данный интеграционный
проект позволяет создать информационный для многих систем к одной
условно центральной.
Подход 3: Интеграция «Многие ко многим». Каждая подсистема может
обращаться и использовать данные другой подсистемы, также она может
служить источником данных для любой из подсистем. Такая интеграция
сложна в поддержке, т.к. при изменении в одной системе нужно будет
перестраивать и другие связанные системы.
Подход 4: «Горизонтальная» интеграция подразумевает использование
промежуточного ПО для обеспечения обмена информацией между системами,
так называемые шины данных. Основная задача этого ПО хранить
репозиторий данных, подключенных к ней ИС, тем самым обеспечивая
обращение ИС к шине данных, а не на прямую к необходимой ИС.
Преимуществами такой интеграции является возможность производить
изменения в ИС, без потери информационного обмена. Также процесс
подключения новых ИС к интеграции достаточно упрощен.
Объекты и методы интеграции систем.
Информационную
систему
можно
рассмотреть
с
точки
зрения
её
компонентов:

Платформа системы: железо и системное ПО, то на чем
функционируют остальные компоненты ИС;

Данные: СУБД и базы данных;

Приложения, которые реализуют бизнес-логику системы, они
состоят из пользовательского интерфейса фреймворк, сервера приложений;

Бизнес-процессы, в рамках которых используется ИС;
Можно сказать, что интеграция систем представляет собой интеграцию одного
или нескольких компонентов этих ИС. Рассмотрим процесс интеграции
в зависимости от компонентов:
Интеграция платформ.
22
Целью интеграции платформ является обеспечение взаимодействия
между приложениями, работающими на разных программно-аппаратных
платформах, например, между приложениями, расположенными на серверах
Windows, Solaris, Linux.
Для построения таких интеграций существует несколько решений:

Виртуализация;

Удаленный вызов процедур (RPC, CORBA, DCOM, Web-сервисы);

ПО промежуточного слоя (Microsoft.Net, Java Runtime);
Интеграция данных.
ИС по определению работает с данными. Целью построения интеграций
данных является совместное использования данных различных ИС.
Интеграция данных из баз данных, зачастую проще, чем интеграция платформ,
т.к. современные СУБД промышленного уровня имеют возможности
программного доступа к данным из других приложений. Подходы к
интеграции данных:

Универсальный доступ к данным (SQL-запросы, ODBC, JDBC);

Хранилища данных (OLAP, OLTP, концепция ETL);
Интеграция приложений.
Целью интеграции на уровне приложений является использование
готовых функций приложений другими приложениями. Например, ПО Callcenter с которым работают операторы горячей линии компании должно при
звонке обращаться в систему биллинга для проверки баланса клиента и в
систему Service-desk для проверки истории обращения клиента. Те. На входе
телефонный номер клиента, на выходе- данные о счете, записи обращений.
Структура база данных биллинговой системы и системы Service Desk является
ее внутренней информацией, публикуются же конкретные функции,
позволяющие другим ИС запрашивать через них необходимые данные.
Подходы к интеграции приложений:

Интерфейсы прикладного программирования (например, Windows
API);
23

Обмен сообщениями (Корпоративная шина сервисов);

Сервис-ориентированная архитектура (публикация функционала
корпоративных приложений в виде Web-сервисов);

Интеграция пользовательских интерфейсов;
Интеграция бизнес-процессов.
Это наиболее целостный подход к интеграции. Интеграция такого
уровня затрагивает как интеграцию данных, приложения, так и интеграцию
людей, реализующих задачи этих бизнес-процессов. Основные идеи
построения интеграции бизнес-процессов:

Проектирование и описание бизнес-процесса с указанием правил
взаимодействия сотрудников с ИС, тем самым обеспечивая логическую
взаимосвязь ИС. Сценарий взаимодействия с ИС может создаваться при
помощи специализированного ПО, который далее будет управлять ходом
этого бизнес-процесса согласно сценарию;

Операции взаимодействия с ИС должны быть детально описаны в
терминах информационного обмена данными: формат, сервисы, приложения,
события, политики безопасности, права доступа;

ПО, в котором заложен сценарий взаимодействия подключаются
посредством адаптеров интегрируемые ИС, участвующие в бизнес-процессе;

Готовым
к
работе
бизнес-процессом
в
интегрируемой
информационной системе управляет менеджер процесса: он может запускать
и
останавливать
подпроцессы,
контролировать
состояние,
вводить
необходимые данные и условия на отдельных операциях бизнес-процессов,
требующих управления человеком.
Можно выделить следующие классы продуктов для интеграции ИС:

Реализующие идеологию SOA (IFS Applications, Flextera, IBM
WebSphere);

Реализующие идеологию Messaging (промежуточное ПО);

Корпоративные шины сервисов;
24

Средства интеграции на уровне бизнес-процессов (BPEL, Business
Process Execution Language);

Средства интеграции данных;
На основе рассмотренного анализа проектов системной интеграции
можно выделить ряд специфичных характеристик присущих проектам
системной интеграции:
 Длительный срок проекта (в среднем 1-2,5 года);
 Мультивендорность;
 Изменение производятся от уровня инфраструктуры до уровня
бизнес- процессов;
 Конечная потребительская ценность;
 Направленность на повышение эффективности бизнеса (включая
консалтинг, бизнес-приложения и ИТ-инфраструктуру);
 Специфический
порядок
реализации
(охватывает
этапы
от
построения бизнес-процессов до инфраструктуры);
 Необходимость высоких компетенций участников команды проекта
в разных классах систем;
 Необходимость построения объединенных коммуникаций между
участниками проекта;
 Сложность обеспечения доступности экспертов на протяжении всего
проекта;
 Распределенность команды проекта;
25
1.4.
Выводы по первой главе
В условиях снижения объемов рынка ИТ в России и кризисной ситуации
в общем руководство компаний ведет политику минимизации издержек.
Капитальные затраты в ИТ компания может снизить, отказавшись от закупок
нового ПО, дорогостоящей миграции. Операционные же расходы быстро
снизить невозможно, это повлечет за собой изменения в основных бизнеспроцессах компании и процессах их поддерживающих. Для повышения
эффективности работы компании готовы привлекать ИТ и проводить проекты
по оптимизации как бизнес-процессов ИТ, так и оптимизации текущий
инфраструктуры.
Спрос на ИТ-услуги на рынке России продолжает расти. Для оказания
качественных услуг ИТ-компаниям, в том числе компаниям-интеграторам
необходимо выстроить процесс управления технологичными проектами на
высоком уровне как методологически, так и технически. На текущий момент
процесс управления проектами в российских ИТ-компаниях разнородный, в
большинстве своём процесс есть, но на практике его применение не всегда
эффективно из-за специфики проектов и их участников. Проекты системной
интеграции занимают большую долю рынка ИТ-услуг в России и имеют свои
специфические черты. В информационных источниках описание аспектов
управления такими проектами встречается редко, в рамках первой главы дано
определение системной интеграции и приведено описание проектов
системной интеграции с указанием специфичных характеристик проекта,
которые необходимо учитывать компаниям для эффективного оказания ИТуслуг.
26
Глава 2. Оценка рисков проектов системной интеграции в
практике российских ИТ-компаний
2.1.
Методология оценки рисков
Методы управления рисками проектов для малых и средних проектов
достаточно проработаны и описаны, что позволяет эффективно уменьшать
уровень рисков и управлять трудозатратами по проекту (Табл. 1)
Для ведения крупных проектов единого метода и стандарта для
управления проектами недостаточно.
Таблица 1
Методы управления рисками в различных проектах
Масштаб
проекта
Малый
Число
работ
До 50
Число
подпроектов
Нет
Связность
работ
Низкая
Средний
50-100
Единицы
Низкая,
средняя
Крупный
1001000
От
нескольких Высокая
десятков
до
нескольких сотен
Методы управления
PMI 1 FMEA MSF,
личный
опыт
руководителя
Стандартные
методики (ASAP 2
PJM 3 PMI), SPICE4
COBIT
Проработаны слабо
Этапы управления рисками, согласно национальному стандарту
Российской федерации ГОСТ Р ИСО/МЭК 31010-2011 [2] представлены на
рис. 5.
27
Рисунок 5. Процесс управления рисками
Каждый этап управления рисками предполагает применение различных
методов. Данные методы складываются в общий процесс реализации
управления рисками по этапам.
Методические принципы с помощью которых происходит организация
процесса основываются на последовательном выполнении отдельных этапов,
процедур и шагов с использованием известных и применяемых на практике
подходов, методов, на основе о самом объекте, риск для которого подлежит
управлению. В нашем случае объектом оценки является проект системной
интеграции.
Оценка риска – процесс, в который входит идентификация, анализ и
сравнительная оценка риска. Риск может быть оценен в масштабе всей
организации, ее подразделений, отдельных проектов. Поэтому в различных
ситуациях могут быть применены различные методы оценки риска.
Оценка риска обеспечивает понимание возможных опасных событий, их
причин и последствий, вероятности их возникновения и принятие решений:

о необходимости проводить действия по нивелированию рисков;
28

о способах максимально эффективного нивелирования рисков;

об обработки риска;

о приоритетности действий по обработке риска;
В рамках данной работы будут рассмотрены следующие этапы:

Идентификация рисков;

Анализ рисков;

Сравнительная оценка рисков;
Этап идентификации рисков управления проектной деятельностью.
Идентификация риска – это процесс, включающий в себя определение
элементов риска, составление их перечня и описания каждого элемента.
Целью
этапа
идентификации
риска
выступает
составление
перечня
источников риска и/или событий, которые могут повлиять на достижение
целей проекта или в целом сделать выполнение этих целей невозможным.
Идентификацию рисков могут выполнять члены команды проекта и
эксперты по вопросам управления рисками (руководители проектов
системной интеграции). Частота итерации и состав участников выполнения
каждого цикла в каждом случае могут быть разными.
Примеры методов к оценке рисков [1,2]:

Метод документальных свидетельств, примерами могут быть:
анализ контрольных листов, анализ экспериментальных данных, а также
данных и событий, произошедших в прошлом;

Подход, в соответствие с которым группа экспертов следует
установленному
процессу
идентификации
риска
посредством
структурированного множества подсказок или вопросов;

Индуктивные методы, например, HAZOP.
Для
достижения
использованы
полноты
различные
идентификации
вспомогательные
риска
методы,
могут
например,
быть
метод
мозгового штурма и метод Дельфи.
29
Для идентификации рисков в данной работе был применен метод
анализа контрольных листов (интервью экспертов) и метод Дельфи. Метод
Дельфи используется для получения обобщенного мнения группы экспертов.
Сейчас этот термин зачастую используют более широко в разных форматах
мозгового штурма, существенной особенностью и отличием метода Дельфи
является то, что эксперты отвечают на вопросы индивидуально и анонимно,
при этом имея возможность узнать мнения других экспертов.
Область применения метода в процессе управления рисков возможна на
любой стадии процесса, где необходимы согласованные оценки экспертов.
Входными данными будут являться риски, для отбора которых необходимо
согласованное единое мнение. Выполнение метода представляет собой
проведение
частично
структурированного
анкетного
опроса
группы
экспертов. Эксперты в момент ответа на опрос не могут взаимодействовать
друг с другом или обмениваться мнениями, что позволяет обеспечить
независимость мнений при ответе на анкетирование.
Этапы проведения опроса методом Дельфи:
1)
Сформировать группу проведения и мониторинга
процесса;
2)
Собрать группу экспертов (возможно формирование
нескольких групп);
3)
Разработать первоначальные опросные листы;
4)
Тестировать опросные листы;
5)
Отправить/передать опросные листы индивидуально
каждому участнику-эксперту;
6)
Проанализировать и обобщить ответы экспертов и
распространить результаты среди участников дискуссии;
7)
Провести повторный опрос участников дискуссии до
тех пор, пока не будет достигнуто согласие по обсуждаемой
тематике.
30
Результат проведения опроса по методу Дельфи для выявления рисков
проекта, представлен в Приложении 1
Этап анализа рисков проектной деятельности
2.2.
Анализ риска заключается в анализе и исследовании информации о
риске. Анализ риска формирует входные данные процесса оценки риска и в
конечном итоге помогает принять решение о необходимости обработки риска,
а также осуществить выбор стратегии и методы обработки риска.
Анализ
риска
включает
анализ
вероятности
и
последствий
идентифицированных рисков с учетом применяемых способов управления.
Данные о вероятности событий и их последствиях используют для
определения уровня риска. Также анализ риска включает анализ результатов
применения и эффективность существующих методов управления.
Различные методы анализа риска описаны в табл. 2.
Методы, используемые при анализе риска, могут быть качественными,
количественными
или
смешанными.
Качественный
анализ
рисков
основывается на оценке рисков в терминах возможных последствий, применяя
заранее
установленные
критерии.
Критериями
могут
быть
затраты,
требования (внешние и внутренние) и прочее. При качественной оценке риска
выявляются последствия, вероятность и
уровень риска по заранее
определенной и описанной шкале, например, «высокий», «средний» и
«низкий».
Управлять всеми выявленными рисками не представляется возможным,
так как это повлечет за собой большие финансовые и кадровые затраты. Для
формирование оптимальной стратегии управления рисками необходимо
осуществить их ранжирование Задачи качественного анализа состоят в
разделении рисков на группы и расположении их в порядке приоритетов.
К методам качественной оценки относятся, прежде всего, экспертные
методы. Упрощённый алгоритм технологии экспертного оценивания рисков
представлен на рис. 6.
31
Рисунок 6. Алгоритм технологии экспертного оценивания рисков
В
смешанных
методах
используют
числовую
шкалу
оценки
последствий, вероятности и их сочетания для определения уровня риска по
формуле.
При количественном анализе оценивают практическую значимость и
стоимость последствий, их вероятности и получают значение уровня риска в
определенных единицах, установленных ранее при разработке области
применения управления рисками.
Для анализа рисков был выбран смешанный метод – «матрица
последствий
и
вероятностей» из списка
методов, рекомендованных
национальным стандартом Российской федерации ГОСТ Р ИСО/МЭК 310102011 [2] и описанный также в своде знаний по управлению проектами PMBOK
v5 [1] (табл. 2).
32
Таблица 2.
Характеристики методов оценки риска
Процесс оценки риска
Идентификация
риска
Последствие
Вероятностные
характеристики
Уровень
риска
Сравнит
ельная
оценка
риска
Мозговой штурм
SA1)
NA2)
NA
NA
NA
Структурированные или
частично
структурированные
интервью
SA
NA
NA
NA
NA
Метод Дельфи
SA
NA
NA
NA
NA
Контрольные листы
SA
NA
NA
NA
NA
Предварительный анализ
опасностей (PHA)
SA
NA
NA
NA
NA
Исследование опасности
и работоспособности
(HAZOP)
SA
SA
A3)
A
A
Анализ опасности и
критических
контрольных точек
(HACCP)
SA
SA
NA
NA
SA
Оценка
токсикологического
риска
SA
SA
SA
SA
SA
Структурированный
анализ сценариев
методом «что, если?»
(SWIFT)
SA
SA
SA
SA
SA
Анализ сценариев
SA
SA
A
A
A
Анализ воздействия на
бизнес (BIA)
A
SA
A
A
A
Анализ первопричины
(RCA)
NA
SA
SA
SA
SA
Анализ видов и
последствий отказов
(FMEA)
SA
SA
SA
SA
SA
Анализ дерева
неисправностей (FTA)
A
NA
SA
A
A
Анализ дерева событий
(ETA)
A
SA
A
A
NA
Анализ причин и
последствий
A
SA
SA
A
A
Наименование метода
Анализ риска
33
Процесс оценки риска
Идентификация
риска
Последствие
Вероятностные
характеристики
Уровень
риска
Сравнит
ельная
оценка
риска
Причинно-следственный
анализ
SA
SA
NA
NA
NA
Анализ уровней защиты
(LOPA)
A
SA
A
A
NA
Анализ дерева решений
NA
SA
SA
A
A
Анализ влияния
человеческого фактора
(HRA)
SA
SA
SA
SA
A
Анализ «галстукбабочка»
NA
A
SA
SA
A
Техническое
обслуживание,
направленное на
обеспечение надежности
SA
SA
SA
SA
SA
Анализ скрытых
дефектов (SA)
A
NA
NA
NA
NA
Марковский анализ
A
SA
NA
NA
NA
Моделирование методом
Монте-Карло
NA
NA
NA
NA
SA
Байесовский анализ и
сети Байеса
NA
SA
NA
NA
SA
Кривые FN
A
SA
SA
A
SA
Индексы риска
A
SA
SA
A
SA
Матрица последствий и
вероятностей
SA
SA
SA
SA
A
Анализ эффективности
затрат (CBA)
A
SA
A
A
A
Мультикретириальный
анализ решений (MCDA)
A
SA
A
SA
A
Наименование метода
1)
Анализ риска
SA – строго применим; 2)NA – не применим; 3)A - применим
Матрица последствий и вероятностей представляет собой объединение
качественных или смешанных оценок последствий и вероятностей. Она
применяется для определения и/или ранжирования уровня риска. Формат
матрицы будет зависеть от области применения.
34
Использование матрицы последствий и вероятностей обеспечивает
обмен информацией об общем восприятии качественных уровней риска
внутри команды проекта, организации в целом или экспертной группы.
Форму матрицы последствий и вероятностей применяют для анализа
критичности в FMECA или для установления приоритетов после этапа
применения исследования HAZOP. Ее также можно применять в ситуациях,
когда имеется недостаточно данных для подробного анализа, или в случае,
когда ситуация не оправдывает затраты времени и усилий на проведение
количественного анализа.
Входные данные: шкалы последствий и вероятностей, установленные в
соответствии с требованиями потребителя, единая матрица, включающая
риски.
Оценочные шкалы и матрица могут быть разработаны и на основе
количественных шкал. Например, по отношению к надежности шкала
вероятности может отображать приближенное значение интенсивности
отказов, а шкала последствий –затраты, вызванные отказом, в денежных
единицах.
Применение
данного
метода
требует
наличия
специалистов
соответствующей компетентности (предпочтительно –экспертной группы) и
всех имеющихся данных для обоснования экспертных заключений о
последствиях и вероятности.
В рамках данной работы было проведено интервьюирование экспертной
группы.
Метод
экспертных
оценок
может
включать:
групповые
и
индивидуальные оценки. В ходе написания работы был применен метод
индивидуальных
оценок
«Интервьюирование»,
в
рамках
которого
специалистам предлагалось заполнить матрицу и проставить веса.
В этом случае опрос проводился при непосредственном общении
исследователя и экспертов, путем выдачи анкет для работы эксперта в удобное
для него время на рабочих местах, а также посредством рассылки анкет
экспертам по почте. В исследовании принимали участие:
35

Менеджеры проектов, имеющие опыт реализации проектов
системной интеграции от 3х лет;

Работающие в компании численностью от 1000 человек;

Работающие с территориально распределенными командами;
Процесс выполнения метода: для ранжирования рисков участник
должен в первую очередь подобрать такое описание последствий, которое
наилучшим образом соответствует описываемой ситуации, далее необходимо
определить вероятность, с которой эти последствия могут наступить. Затем
определялся с помощью матрицы уровень риска. Результат оценки рисков
экспертной группой представлен в приложении 2.
Многие опасные события имеют различный диапазон результатов с
соответствующими вероятностями. Например, незначительные проблемы
обычно происходят чаще, чем катастрофы. Поэтому можно ранжировать часто
получаемые
результаты,
наиболее
серьезные
или
другие
сочетания
вероятности и последствий.
В
большинстве
рассматриваемых
случаях
требуется
уделять
наибольшее внимание серьезным возможным результатам, поскольку они
представляют большую угрозу и являются более значительными. В некоторых
же случаях необходимо ранжировать как незначительные проблемы, так и
маловероятные катастрофы как отдельные виды риска. При этом следует
рассматривать вероятность, связанную с выбранным последствием, а не
вероятность события в целом.
Выходные данные: перечень опасных событий с указанием уровня
значимости.
Для оценки риска необходимо вычислить класс вероятности риска (P) и
уровень последствия (I).
Перечень критериев последствий и класс вероятности строится на
основе рекомендаций cвода знаний по управлению проектами PMBOK v5.
Перечень критериев последствий указан в табл. 3. Классы вероятности риска
приведены в табл. 5.
36
Таблица 3.
Таблица критериев последствий
СТОИМОСТЬ
СРОКИ
СОДЕРЖАНИЕ
КАЧЕСТВО
«1» - очень
низкий
Незначительное
увеличение
стоимости (не
более 10% от
маржи проекта)
Сокращение
содержания
едва заметно
Ухудшение
качества
едва заметно
Анкета зеленая.
«2» - низкий
Увеличение
стоимости
(более 10 % от
маржи проекта)
Незначительное
увеличение
сроков (не
более % от
планового
срока)
Увеличение
сроков (более5
% от планового
срока)
Воздействию
подвержены
незначительные
области
содержания
«3» - средний
Увеличение
стоимости (на
10–20 %)
Увеличение
сроков
(на 5–10 %)
«4» - высокий
Увеличение
стоимости (на
20–40 %)
Увеличение
сроков
(на 10–20 %)
«5» - очень
высокий
Увеличение
стоимости
(более 40 %)
Увеличение
сроков (более
20 %)
Воздействию
подвержены
значительные
области
содержания (до
50%)
Изменение
содержания
неприемлемо
для одной из
сторон (более
50%)
Содержание
работ не
управляемо
Воздействию
подвержены
только самые
не
требовательные
области
Анкета зелёная.
Снижение
качества
значительно,
но приемлемо
Заказчиков.
Анкета желтая.
Снижение
качества
неприемлемо
для спонсора
Анкета
красная.
Конечный
результат
проекта
практически
бесполезен
Анкета
красная.
На основе экспертных оценок произведем оценку рисков по всему
перечню, выявленному на этапе идентификацией и проставим оценки.
За оценку последствий будем принимать наибольшую оценку по всем
критерием данного риску. Например, для оценки Риска X (табл. 4).
37
Таблица 4.
Пример оценки риска по критериям последствий.
Описание Риска
Риск X
СТОИМОСТЬ СРОКИ
3
3
СОДЕРЖАНИЕ КАЧЕСТВО
2
1
Итоговая оценка последствия Риска X будет равна max(3;3;2;1) = 3.
Далее рассмотрим классы возможные классы вероятности риска (p),
табл. 5.
Таблица 5
Реализуемость риска
КЛАСС
РЕЙТИНГ
E
Вероятно
D
Возможно
C
Маловероятно






Редко
Невероятно
B
A


КРИТЕРИЙ
Риск реализуется;
Скорее всего произойдёт несколько раз
течении одного проекта;
Вероятность наступления высока;
Риск, скорее всего, проявится;
Происходит в подобных проектах, но не
часто;
Вероятность проявления и не проявления
риска примерно равна;
Может произойти случайно;
Риск, скорее всего, не проявится;
В приложении 1 представлена анкета для оценки рисков в разрезе этапов
жизненного цикла проекта по критериям последствий и классам вероятности
рисков.
На основе сопоставления определенных выше критериев последствий и
класса вероятности риска оценивается уровень риска. Уровни риска,
установленные для ячеек таблицы, зависят от определений, применяемых для
шкал вероятности и последствий. Матрица построена с преимущественным
влиянием последствий. Матрица определения уровня риска приведена в
табл. 6. Описание значений уровня риска, необходимых действий и методов
управления риском представлены в табл.7.
38
Риск-менеджмент включает следующие базовые методы: отказ от риска,
снижение, передача и принятие.

Отказ от чрезмерно рисковой деятельности (метод отказа от
риска),

Профилактика или диверсификация (метод снижения риска),

Передача на аутсорсинг наиболее затратных функций (метод
передачи риска),

Согласие с рисков и формирование резервов (запасов) ресурсов
(метод принятия риска).
Таблица 6
Класс вероятности
Матрица уровней риска
5 Вероятно
III
II
II
I
I
4 Возможно
III
III
II
II
I
3 Маловероятно
IV
III
III
II
II
2 Редко
IV
IV
III
III
II
1 Невероятно
IV
IV
IV
III
III
1
2
3
4
5
Класс последствий
39
Таблица 7
Описание уровней риска
Уровень риска
Необходимые действия
Критичный
Высокий
Незамедлительные
действия,
необходимые для
снижения риска
целевого уровня путем
разработки
мероприятий по
минимизации рисков.
Средний
В случае
экономической
целесообразности
руководство
компании может
принять решение о
разработке
мероприятий по
минимизации рисков.
Периодический
мониторинг уровня
риска.
Периодический
мониторинг уровня
риска.
Низкий
Методы управления
Отказ от риска или
рассмотрение методов
снижения риска
Отказ от риска
недопустим. Должны
быть рассмотрены
возможности
перенаправления,
уменьшения риска.
Должны быть
рассмотреть варианты
нивелирования риска
Принятие риска
В приложении 1 представлена таблица рисков в разрезе этапов
жизненного цикла проекта согласно PMBOK v5 с указанием уровня риска.
По результатам проведения опроса экспертной группы была получена
следующая тепловая матрица рисков (см. приложение 2).
Произведем классификацию рисков критичного и высокого уровня.
Классификация рисков представлена в табл. 8.
40
Таблица 8
Типы рисков критичного и высокого уровня в проектах системной
интеграции
Уровень
риска
Риски
Тип риска
Этап 1. Инициация проекта
Неверное понимание потребностей заказчика
I
Требования
II
Требования
Анализ рисков не осуществляется на этапе
планирования и подготовки продажи проекта
II
Оценка
рисков
Плохо проработана архитектура решения из-за
отсутствия полных данных о инфраструктуре
заказчика
II
Ошибка в планировании объема работ и
трудозатратах
Исполнителей,
т.к.
не
проводятся первичный анализ и оценка
сложности проекта сотрудниками, которые
станут непосредственными исполнителями по
проекту
II
Неверная постановка задач
определение содержания работ
проекта
и
Требования
Процессные
Этап 3. Исполнение проекта
Риски, связанные с территориальной распределенностью проектной
команды
II
Сложности в коммуникации в реальном
Коммуникати
времени между участниками проекта
вные
II
Увеличение расходов на командировки
Коммуникати
Исполнителей
вные
Риски, связанные с участием в проектной команде представителей
нескольких компаний/региональных хабов компании
II
Конфликт интересов между проектами, в
Политические
которых Заняты Исполнители
Смена участников проектной команды
Исполнителя до завершения проекта
II
Процессные
41
Риски
Отказ от выполнения работ субподрядчиком
(субподрядчик не заинтересован в результате
проекта)
Отсутствие единой точки коммуникации всех
участников проекта как со стороны
Исполнителя, так и Заказчика (ВКС,
переговоры, демонстрации)
Невозможность ведения совместной работы
участников проектной команды Исполнителя
над разработкой документов (проектные,
сопроводительные).
Невозможность удаленного подключения из-за
политик безопасности участников проекта (со
стороны Исполнителя и Заказчика)
В договоре и техническом задании нет четкого
описания границ проекта
Уровень
риска
II
Тип риска
Процессные
II
Коммуникати
вные
II
Коммуникати
вные
II
Коммуникати
вные
II
Требования
Завышенные ожидания по проекту и Заказчика
II
Требования
Сложный
и
продолжительный
согласования на стороне Заказчика
II
Требования
I
Требования
этап
Изменение требований со стороны Заказчика
Этап 4. Закрытие проекта
Процедура
закрытия
проекта
слабо
II
формализована в Договоре
2.3.
Требования
Выводы по второй главе
Специфика проектов системной интеграции влияет на риски проектов.
Методы управления рисками для малых и средних проектов достаточно
проработаны и описаны, что позволяет эффективно уменьшать уровень рисков
и управлять трудозатратами по проекту, а для ведения крупного
технологичного проекта системной интеграции необходимо выявить и
описать типовые риски таких проектов. Для решения этой задачи в
исследовании был проведен опрос экспертной группы на базе компании ЗАО
«Софт Лайн Трейд» с использованием метода Дельфи для идентификации и
сбора рисков типовых проектов системной интеграции. Для анализа рисков
был выбран смешанный метод – «матрица последствий и вероятностей» из
42
списка методов, рекомендованных национальным стандартом Российской
федерации ГОСТ Р ИСО/МЭК 31010-2011. В результате проведения этапа
идентификации был сформирован перечень рисков, характерных для проектов
системной-интеграции в компании. На этапе оценки удалось получить
тепловую карту рисков с распределением рисков по уровням в зависимости от
их последствий и вероятности возникновения.
Исходя из анализа рисков экспертной группой можно сделать вывод, что
основные риски критичного и высокого уровня – это риски, связанные с
управлением требованиями, изменениями и коммуникациями участников
проекта.
43
Глава 3.Анализ инструментов и методов управления проектами
для нивелирования рисков проектов системной интеграции.
3.1.
Методы нивелирования рисков проектов системной
интеграции
Согласно результатам, большинство выявленных рисков проекта
связаны с коммуникациями участников команды проекта и управлением
требованиями на всех этапах жизненного цикла проекта.
Нивелирование коммуникативных рисков на методологическом уровне
возможно с помощью согласование и ведения документов проекта [8]:

Коммуникационный план проекта, где описываются каналы
передачи информации, их периодичность и получение обратной связи между
участниками команды проекта. Устав проекта, где описываются принципы
ведения проекта, используемое ПО.

Реестр заинтересованных сторон проекта, где описывается
окружение проекта и лист стейкхолдеров проекта;
Большая роль в нивелировании коммуникационных рисков лежит на
используемых инструментах коммуникации.
Как отмечают эксперты в области управления проектами, качество
продукта существенно связано с умением команды работать с требованиями.
Так же, как и оценка качества работы команды в значительной степени зависит
от нетехнических навыков, а желания и умения понимать проблемы и
потребности Заказчика, и затем транслировать эти знания в продукт [10].
Для анализа требований в рамках проектной деятельности для компании
ЗАО «СофтЛайн Трейд» разработана модель управления требованиями и
описан процесс управления требованиями.
Стандартно модель управления требованиями проектами состоит из
трех этапов. На первом этапе происходит сбор бизнес-требований, которые
затем фиксируются в документе «Реестр требований» и в проектном решении,
на основе этих требований определяются рамки проекта. Решение о принятии
или отклонении бизнес-требования необходимо принимать для каждого
44
требования отдельно, принятого на этапе проектирования проекта системной
интеграции. Бизнес требование необходимо оценить по следующим
признакам:

Выполнимость в рамках функциональности проектируемого
решения;

Гарантии и критерии успешного выполнения;

Критичность в бизнес-процессе компании-Заказчика;

Соответствие стандартам организации;
Также проставляется взаимосвязь требований и выстраивается иерархия
требований.
Следующий уровень –это сбор и обработка требований пользователя.
При обработке требования пользователя происходит их приоритезация на
основе следующих признаков:

Влияние автора требования,

Актуальность;

Критичность для работы системы;

Риск порождения дальнейших ошибок;
Бизнес-требования связаны с требованиями пользователей, кроме того
они связаны между собой, поэтому на втором этапе необходимо выстроить
требования с использованием метода аналитических сетей.
Управлением бизнес-требованиями и требованиями пользователь
занимается Бизнес-аналитик. Его задача максимально точно определить
изначальные потребности Заказчика и ранжировать их. Он определяет, что
пользователь хочет достичь, используя систему и насколько внедряемая
решение может удовлетворить эти потребности.
На основе первого и второго уровня формируются требования к
внедряемой системе.
Одно требование пользователя может быть решено с помощью одного
или нескольких системных требований. Далее происходит ранжирование
системных
требований.
При
ранжировании
системных
требований
45
учитывается вес пользовательского требования на основе которого было
сформулировано это требований.

Для определения приоритетов системных требований необходимо
учесть признаки:

Влияние на затраты ресурсов при реализации;

Влияние на смежные функциональные блоки;

Риск возникновения ошибок;

Влияние на сроки;
На основе анализа системных требований формируются системные
спецификации (архитектура решения), на этом этапе определяется как
конкретная
архитектура
системы
будет
удовлетворять
системным
требованиям, выявленным ранее. Этим этапом управляет Архитектор проекта.
Модель управления требованиями для принятия решений строится от
бизнес-требований с дальнейшей детализацией на следующие уровни.
Поскольку при построении модели требований учитываются относительные
веса требований более высоких иерархий, мы получаем приоритизированные
системные требования на основе которых строится архитектура решения и
план работ проекта.
Построение сложных логических связей между требованиями, а также
использование различных признаков для их приоритизации требует
использование специализированного ПО для составления моделей требований
[13, стр. 67-70].
Список ПО для составления моделей требований проекта:

SuperDecisions;

IBM Rational RequisitePro

Telelogic DOORS

Sybase PowerDesigner

Borland Caliber RM

Sybase PowerDesigner
46

OpenSource Requirements Management Tool

RequirementsWin
Укрупненно процесс управления требованиями представлен на рис.7.
Рисунок 7. Процесс управления требованиями, внедряемый в компании ЗАО
«СофтЛайн Трейд»
Ещё одним аспектом управления требованиями является управление
изменениями требований.
Как указано в анализе риск «Изменение требований со стороны
Заказчика» имеет критичный уровень, т.е. он наиболее часто свершается в
рамках реализации проектов, а также имеет серьезные последствия для
стоимости, сроков, содержания и качества проекта.
Для управления изменениями в компании ЗАО «СофтЛайн Трейд» была
предложена для внедрения модель управления изменениями.
Управление изменениями представляет собой совокупность процессов,
включающих идентификацию, фиксацию, оценку, принятие решения,
управление реализацией изменения, контроль [26].
47
Процесс управления изменениями функционируют на всем этапе
проекта от инициации до закрытия проекта. Для проектной деятельности
компании ЗАО «СофтЛайн Трейд» процесс управления изменениями в
проекте осуществляется с момента подписания договора, до сдачи-приемки
результатов работ и подписания акта.
Все изменения, которые влияют на итоговый продукт проекта, должны
быть обязательно согласованы ЛПР в компании-заказчике. Для этого в текст
Договора вносится статья, описывающая процедуру рассмотрения и
утверждение изменений, а также сроки выполнения этой процедуры каждой
из сторон.
Классификация изменений:

Внешние (инициированы Заказчиком);

Внутренние (инициированы Исполнителем).

В свою очередь изменения делятся на типы

Технические (связаны с реализацией проекта);

Организационные (например, изменение состава команды);

Контрактные (состав работ, сроки, стоимость).
Инициаторами изменений могут являться:

Представители компании-заказчика (в том числе, ЛПР);

Любой участник команды проекта из команды Исполнителя;

Третья
сторона
(субподрядчик,
фриланс,
консультант
по
проектированию);

Конечный пользователь, если конечный пользователь не в
компании-заказчика.
Процесс управления изменениями представлен на рис.8.
48
Рисунок 8. Процесс управления изменениями
Этапы процесса:
1)
Подача запроса на изменение.
Каждый запрос на изменение должен быть документирован, указаны все
обновленные требования, которые будут производится в рамках этого
изменения. На основе описанных требований осуществляется оценка
возможности проведения изменения.
Форма запроса на изменение должна быть согласована и прикреплена к
Договору или иным правоустанавливающие документам проекта, например,
Устав проекта.
2)
Оценка
Оценка последствий.
степени
воздействия
предлагаемого
изменения
на
проект
производится коллегиально всеми участниками проектной команды. Для
принятия решения о внесении изменений проект или их отклонении
49
необходимо, чтобы предлагаемые изменения были правильно поняты, между
ними расставлены приоритеты и оценена их стоимость и длительность. По
результатам оценки документируются все степени воздействия (включая сроки проекта, стоимость изменений).
Оценка последствий внесения изменений в проект решает следующие
вопросы:

Вызвано ли изменение недостаточной проработкой требований и
неверным отражением модели требований;

Какая выгода будет получена от внесения изменений участниками
сторон;

Риски, связанные с реализацией, отказом и принятием изменения;

Влияние изменений на остальные уровни требований;

На каком этапе жизненного цикла производится изменение;

Как результат проведения изменения повлияет на сроки,
стоимость, состав и качество проекта.
3)
Принятие решения.
Решение о необходимости предложенного изменения или отказе от его
реализации принимается следующими лицами:

Руководителем проекта (при изменении сроков и стоимости
проекта не более 10% от общей стоимости проекта),

Куратором и спонсором проекта (при изменении сроков и
стоимости более 10%, но не более 20%),

Советом по управлению изменениями при величине изменений
более 20%.
По запросам на изменения могут быть приняты решения:

Утвердить;

Отклонить;

Отправить на доработку (Отложить);
50
Любое решение фиксируется РП в журнале Контроля изменений и в
обязательном порядке доноситься до Заказчика.
4)
Реализация изменения.
Если принято решение об утверждении изменения, работа над данными
изменениями происходит:

В рамках проекта;

Только после подписания обеими сторонами дополнительного
соглашения к договору;
В рамках реализации изменения руководитель проекта должен:

Утвердить новые версии плана работ и всех остальных
необходимых документов (Устав проекта, Риски проекта, Карточка проекта,
План-график работ, Смета, Рабочие документы проекта);

Принять решение о привлечении дополнительных ресурсов
(внутри компании/ субподряд/фриланс);
o Инициировать запрос на оценку внутренних ресурсов;
o Инициировать
заключение
договора
или
дополнительного
соглашения с субподрядчиком.

Выделение дополнительного бюджета (при необходимости);

Закрепляет новые сроки проекта;
5)
Контроль изменения.
Когда изменение будет выполнено, вопрос может быть снят с контроля,
следовательно, статус запроса на изменение должен быть изменен в журнале
Контроля изменений
Необходимо
оповещать
участников
проекта
о
произошедших
изменениях в проекте для сохранения актуальности работ участников проекта.
Это оповещение должно быть запланировано заранее, в плане управления
коммуникациями.
Процесс управления требованиями в компании ЗАО «СофтЛайн Трейд»
сейчас переживает переход со второго уровня зрелости процесса к третьему
т.е. от детального документального оформления и учета к структурированию
51
требований,
ведению
реестра
требований,
шаблонов
для
сбора
и
идентификации требований для всех проектов компании, ведение типов и
атрибутов требований.
На этом этапе большое внимание уделяется обучению проектной
команды новым методам работы, работы с новым программным обеспечением
для управления требованиями и дополнительными проверкам спецификаций
требований на полноту и проверяемость. В итоге требования становятся более
качественными, что ведет к сокращению стоимости и сроков разработки.
Компании-интеграторы в России и странах СНГ еще не широко и не
повсеместно используют методы проектного управления, что приводит к
репетиционным рискам, срывам сроков проекта и судебным искам.
Выстроенный процесс управления требованиями на высоком уровне зрелости
позволит компании иметь серьезное преимущество на рынке ИТ-интеграторов
России и СНГ в ситуации ужесточения конкуренции.
3.2.
Анализ инструментов для нивелирования рисков проектов
системной интеграции
Как отмечают руководители ИТ-компании, [10] большинство рисков
проекта носят коммуникационный характер, и проявляются ещё на начальном
этапе, а далее, в процессе проекта, зачастую происходит неверное
выстраивание коммуникаций. Проблемы с коммуникациями на начальном
этапе приводят к потере управления требованиями и неверным содержанием
ограничения в договоре.
Зачастую коммуникационные риски возникают в общении участников
команд проекта, особенно в рамках сложных интеграционных проектов. Часть
таких коммуникационных рисков можно нивелировать организационнометодическими средствами: проработанный устав проекта, договор с
субподрядчиком и т.д.
Часть коммуникационных рисков лежит в техническом оснащении
компаний-участников
проекта.
Для
построения
современной
среды
52
коммуникации проекта рассмотрим требования к решениям со стороны
участников проекта.

Компания – интегратор (крупная распределённая компания):
o Телефония;
o Видео-конференц связь;
o Совместная обработка документов;
o Мобильность;
o Постановка задач;
o Отслеживание статуса участника;
o Безопасность передачи данных;
o Простота подключения нового участника;
o Приемлемая стоимость стоимость;

Компания-Заказчик (крупная компания):
o Телефония;
o Видео-конференц связь;
o Безопасность передачи данных;
o Простота подключения нового участника;
o Приемлемая стоимость стоимость;

Субподрядчик (ИП, малый-бизнес);
o Телефония;
o Видео-конференц связь;
o Мобильность;
o Простота подключения нового участника;
o Приемлемая стоимость стоимость;
53
Для реализации технических требований участников проектной команды
возможно рассмотреть 2 сценария:
1. На основе передовых мировых решения корпоративного уровня (оценка
Gartner);
2. На основе имеющихся решений компаний-участников и сторонних
онлайн-сервисов;
Мировым
трендом
построения
коммуникация
является
модель
коммуникации как сервис (Communication as a Service – CaaS). Мировые CaaS
– вендоры предоставляют готовую площадку для коммуникаций и выступают
ответственными за управление аппаратным и программным обеспечением
пользователей. Вендоры предоставляют гарантированное качество сервиса и
обслуживание по SLA в рамках договора. Модель CaaS позволяет
пользователям выбирать необходимый функционал решения и оплачивать его
согласно тарифам вендора. Модель CaaS разработана на ценовой политике
общего назначения, которая предоставляет пользователям сервисный план.
Для оценки передовых систем унифицированных коммуникаций в рамках
данного исследования был проанализированs отчеты Gartner «Critical
Capabilities for Unified Communications as a Service» [29], «Magic Quadrant for
Unified Communications as a Service» [28] за 2014 год.
В рамках отчета рассматриваются четыре возможных сценария
использования UCaaS в различных типах компаний:

SMB – возможность применения в компании малого (организации,
в которых работают от 20 до 99 сотрудников) и среднего бизнеса (100 – 999
сотрудников);

Крупные предприятия с небольшими требованиями к УК –
возможность применения в крупных предприятиях (начиная от 1000
сотрудников и более), которые не выдвигают значительных требований к
решению (помимо телефонии и мобильности) и представлены (работают) в
одном регионе;
54

Крупные
предприятия,
которым
необходимо
полнофункциональное УК-решение – возможность применения в крупных
корпорациях (более 1000 сотрудников), работники которой централизованы в
одном регионе. Требования охватывают полный спектр функционала,
предоставляемого УК-решениями (например: телефония, мобильность, web –
конференции, видеоконференцсвязь, обмен мгновенными сообщениями и
прочие)

Комплексные или международные требования к УК-решениям –
интернациональные корпорации (более 1000 сотрудников), работники
которых распределены по различным географическим регионам. Требования
охватывают полный спектр функционала, предоставляемого УК-решениями
(например:
телефония,
мобильность,
web
–
конференции,
видеоконференцсвязь, обмен мгновенными сообщениями и прочие).
Большинство предлагаемых UCaaS-решений имеет схожий функционал,
поэтом для того, чтобы осуществить сравнительный анализ поставщиков
услуг (решений) было идентифицировано несколько наиболее критичных
функций:

Телефония
Возможность предоставления функционала, схожего с функционалом
традиционного IP PBX решения (телефонная станция на основе межсетевого
протокола IP), например:
o Передача голоса по фиксированным (проводным) и мобильным
каналам связи;
o Софтфон (программное обеспечение для ПК, позволяющее
совершать телефонные или видео звонки);
o Возможность установления голосовых и видео сессий высоко
разрешения посредством пиринговой (peer-to-peer) архитектуры.
Наиболее
важные
функции
включают
в
себя
инструменты,
позволяющие осуществлять диагностику VoIP, интеграцию с локальными
офисными АТС, возможность подключения филиалов, одновременную
55
поддержку нескольких линий (возможность одновременной поддержки
нескольких активных звонков) и возможность интеграции (или создания) с
call-центром.

Мобильность
Возможность использования УК-клиентов в различных мобильных
средах, включая: ноутбуки, планшетные компьютеры, смартфоны. Базовая
функциональность включает в себя возможность переадресации звонка с
VoIP-телефона пользователя на его мобильное устройство (например,
телефон). Расширенный вариант позволяет использовать fixed mobile
convergence (решение, позволяющее создать единую сеть офисных и
мобильных телефонов с общим планом короткой нумерации, создавая
возможность созваниваться напрямую по коротким внутренним номерам
сотрудникам из офисов в разных городах России, в т.ч. без использования
реальной офисной АТС) и видеоконференцсвязь.

Организация конференц-связи (Аудио/Видео/Веб)
Возможность использования широкого функционала по организации
различных (аудио, видео, веб) конференций между широким спектром
устройств: как фиксированных (проводных), так и мобильных. Для создания
конференции необходимо реализовать интеграцию и поддержку различных
технологий: «переговорных комнат», использования удаленных веб-камер,
мобильных устройств и ПК-пользователей. Функционал конференций
напрямую зависит от типа собраний: более простые решения используются
для небольших (или неформальных) совещаний, в то время как более сложные
и гибкие решения используются для собраний больших групп пользователей
или для собраний, имеющих повышенные требования к возможностям
управления.

Портал самообслуживания пользователей
Функционал,
позволяющий
пользователям
самим
управлять
настройками своей учетной записи. Более продвинутые решения позволяют
применять ролевую, региональную, или структурную модель управления как
56
расширенным, так и базовым функционалом, и отчетностью, при этом
управление осуществляется через дружественный и интуитивно понятный
веб-интерфейс.
Отсутствие
порталов
самообслуживания
побуждает
использовать дорогие и весьма затратные (по времени) подходы для
предоставления прав и изменению настроек учетных записей, а именно:
ручные или полу автоматизированные.

Установка и интеграция
Включает в себя набор профессиональных услуг, удаленную поддержку
(по телефону и/или электронной почте) и различные веб-инструменты для
добавления новых пользователей. Небольшие и простые внедрения могут
осуществляться, в основном, удаленно. Большие и сложные внедрения требует
очного присутствия профессионалов, при этом могут решаться такие задачи
как:
o Управление проектной деятельностью;
o Проектирование сетевой архитектуры (или формирование перечня
необходимых изменений текущей);
o Тестирование решение и прочее
Требования в этой области напрямую зависят от потребностей
различных
Компаний:
от
поставщика
могут
потребовать
широкого
функционала возможностей - долгосрочной поддержки; интернационального
присутствия; поддержки различных языков, валюты и соответствия
требованиям законодательства и регуляторов различных стран.

Предоставляемые услуги и поддержка
Удовлетворенность Компании-заказчика во многом зависит именно от
этого функционала. Более продвинутые решения предлагают порталы,
позволяющие осуществлять мониторинг и отслеживать статус решения
проблем. С технической точки зрения более сильные решения предлагают
функционал, включающий в себя:
o Мониторинг
производительности
и
отслеживание
статуса
решения проблем
57
o Предоставление качественных статистических данных
o Оповещения о приближении к пороговому значению возможного
траффика
o Информацию о загрузке сети (мониторинг производительности
сети) и показателях маршрутизаторов
o Возможность создания заявок (ticket) для решения возникающих
проблем
o Предоставление
доступа
к
детализированной
платежной
информации
o Возможность онлайн-оплаты услуг поставщика услуг
С точки зрения компаний-участников процесса коммуникации в отчете
анализируются следующие типы компаний:

Услуги для малого и среднего бизнеса (компания-субродрядчик)
Рынок SMB очень разнообразен и разделен на сегменты, при этом
требования к унифицированным коммуникациям одного сегмента могу
значительно отличаться от требований другого. Однако ограничения,
накладываемые на возможные ИТ-ресурсы в SMB-сегменте значительно
сильнее, чем у крупных корпораций, что в свою очередь формирует
определенные тенденции при интеграции UCaaS-решений. Малый и средний
бизнес отдает предпочтения UCaaS решениям, которые:
o Имеют простой и интуитивно понятный пользовательский
порталом, которым легко пользоваться;
o Обладают прозрачной и простой схемой ценообразования и
оплаты;
o Просты в интеграции (требуют минимальной настройки и
доработки);
o Поставляются с легкодоступной поддержкой;
o Интегрированы
в
используемые
приложения
(например,
salesforce.com) или в приложения, которые взаимосвязаны с
существующими бизнес-процессы Компании;
58
В целом, SMB имеют множество потребностей в коммуникациях,
аналогичных потребностям крупных корпораций (при этом их требования к
настройке и/или модернизации решения существенно ниже), однако
количество
ресурсов
(финансовых
и
ИТ),
которыми
они
могут
воспользоваться, не так велико.

Услуги для крупного бизнеса (Компания –Заказчик, Компания-
Интегратор)
Крупный бизнес имеет, как правило, более сложные требования к УКрешениям, которые часто должны быть интегрированы в существующую
WAN-среду. Такие внедрение должны учитывать разнообразные потребности
множества работников, большое количество сайтов и сложность процесса
принятия решений. Корпорации ожидают от решения минимального времени
простоя, высокой производительности и надежности, а также значительного
уровня обеспечения безопасности. Из-за существующих инвестиций в
точечные (локальные) решения крупные компании рассматривают UCaaS в
долгосрочной перспективе как часть более крупной инициативы по переносу
требуемого функционала в облако. Обычно, корпорации предпочитают
работать с поставщиками, которые:
o Зарекомендовали себя на рынке и имеют опыт работ в
аналогичных компаниях (по размеру и/или сектору экономики);
o Могут разрабатывать (или дорабатывать) и поддерживать
решения «на заказ»;
o Могут предложить специальные услуги (в некоторых случаях),
чтобы обеспечить необходимый уровень безопасности;
o Предоставляют легко и быстро масштабируемый сервис, который
может поддерживать значительное количество пользователей.

Международные,
распределенные
компании
(Компания-
интегратор, Вендор)
Возможность осуществлять поддержку международных компаний.
Международные компании отличаются от крупных корпораций не столько
59
размером, сколько тем, что они осуществляют и поддерживают свою
деятельность в различных регионах, при этом соблюдая и выполняя локальные
требования
стран
международными
присутствия.
По
этой
причине,
компаниями,
поставщики
при
UCaaS-услуг
работе
с
должны
предоставлять поддержку, с учетом нормативных, регуляторных и языковых
требований. В большинстве случаев, поставщик UCaaS-услуг должен
объединиться с региональными партнерами для того, чтобы оказывать полный
спектр услуг.
Для каждого типа компании были определены веса, отображающие
степень влияния каждой критичной функции на тот или иной сценарий в
процентах. После чего каждое рассматриваемое решение (поставщик) было
оценено по «5» бальной шкале, при этом считается, что:

Оценка 1 = «Очень низкое соответствие» (почти все необходимые
требования не выполняются решением (поставщиком));

Оценка 5 = «Очень высокое соответствие» (решение (поставщик)
значительно превышает необходимые требования);
Оценка по каждой из рассматриваемых критичных функций умножается
на соответствующий для нее вес, в зависимости от сценария, после чего
суммируются полученные значения («оценка по функции» * «вес»), что и
формирует итоговую оценку решения (поставщика).
Результат оценки согласно отчету, Gartner представлен в Приложении 2.
По оценкам аналитического агентства лидерами этой отрасли являются
решении вендоров: West, Thinking Phone Networks, Orange Business Services,
HP, 8x8. Магический квадрант Gartner представлен на рис.9.
60
Рисунок 9. Магический квадрант Gartner CaaS – решений за 2014 г.
На российском рынке представлены следующие компании – лидеры:
Orange Business Services, HP.
Данные решения способны максимально удовлетворить потребности
участников коммуникаций, рассмотренных выше. Полная таблица оценки
решений представлена в приложении 3. Сводная таблица представлена на
рис.10.
61
Рисунок 10. Оценка CaaS решений
Для построения объединённых коммуникаций между участниками
проектов системной интеграции наиболее подходящим решением является
Orange Business Services. Компания-интегратор может выступать в качестве
провайдера услуги, предоставляя лицензии на использование решения во
время проекта.
Сценарий решения коммуникационных рисков с помощью построения
решения на основе имеющегося у участников проекта ПО предполагает
использование сторонних сервисов с ограниченным функционалом для
удовлетворения тех или иных потребностей участников на время проекта.

Телефония –Lync, Skype, мобильное подключение;

Видео-конференц связь Lync, Skype, Cisco Webex;

Совместная обработка документов – Яндекс Диск,Google Drive,
Drobox;

Постановка задач – MS Exchange,Workflow Soft, Wrike,Megaplan;

Отслеживание статуса участника – Lync, Skype;
62

Безопасность передачи данных – при использовании сторонних
решений низкая;

Простота подключения нового участника - да;

Приемлемая
стоимость
–
большинство
функционала
перечисленных решений бесплатно;
Сводный обзор сторонних облачных решений российского рынка представлен
в табл.9.
Таблица 9.
Обзор облачных коммуникационных решений для управления проектами
Cisco Webex
Мегаплан
Wrike
Адванта
Zoho Projects
Телефония
+
-
+
-
-
-
-
-
Мобильность
+
+
-
+
+
+
+
+
-
+
-
-
-
-
-
-
-
+
+
+
+
+
+
-
-
+
+
+
+
-
-
+
+
-
+
-
-
+
-
-
-
-
-
+
+
+
+
+
+
+
от
$30/мес/
чел
Условно
бесплат
но до 5
чел
Условн
о
бесплат
но до 2
ГБ
от
$50/мес/
чел
от
$50/мес/
чел
от
$75/мес/
чел
от
$50/мес/
чел
Функциональн
ые требования
Skype
Workflow Soft
Яндекс
Диск,
Организация
конференцсвязи
(Аудио/Видео/
Веб)
+
Совместная
обработка
документов
-
Постановка и
планирование
задач
-
Отслеживание
статуса
участника
+
Безопасность
передачи
данных
-+
Простота
подключения
нового
участника
Стоимость
Google
Drive,
Drobox
+
Услов
но
беспла
тно до
5 чел
63
3.3.
Развитие инструментов для поддержки проектной
деятельности
Распределенные проекты имеют большое количество участников
разного типа: малый и средний бизнес, крупный бизнес, международные
компании, частные лица: эксперты и фриланс. Проекты системной интеграции
длятся в среднем около1,5-2 лет, а значит на протяжении всего срока проекта
необходимо выстраивать и обеспечивать коммуникацию между участниками
проекта. Компании-участники выдвигают ряд требований к техническим
решениям для коммуникации: поддержка телефонии, мобильности, ВКС,
совместная обработка документов и ведение проекта, защищенность каналов
передачи данных, сложность внедрения и поддержки и т.д. Частные лица –
эксперты и фриланс также должны быть подключены к этой платформе для
коммуникации.
Необходимость построения единой платформы для коммуникаций на
время проекта порождает появление новых сервисов на рынке ИТ-услуг и
электронного бизнеса. Текущие онлайн-сервисы не перекрывают всех
потребностей компаний, решения корпоративного уровня зачастую имеют
высокую стоимость внедрения. В дальнейшем возможен рост компаний
способных предоставить площадку для взаимодействия участников проекта
как сервис по заданным требования заказчика.
Рассмотрим описание сервиса для ведения проектных коммуникаций
(B2B).

Предпосылки (проблемы, которые может решить предлагаемый
сервис):
При построении коммуникаций для распределенных проектных команд не
всегда достаточно использовать корпоративные решения объединённых
коммуникаций:
o Разрозненные решения команд-участников;
o Высокая стоимость подключения;
o Недостаточен функционал решения;
64
o Большинство решений корпоративного уровня производятся
иностранными вендорами;
o Большинство онлайн-сервисов имеют узкий функционал;

Функциональные требования к сервису:
o Телефония
o Мобильность
o Организация конференц-связи (Аудио/Видео/Веб)
o Совместная обработка документов
o Постановка и планирование задач
o Отслеживание статуса участника
o Безопасность передачи данных
o Простота подключения нового участника
o Стоимость
o Хранение данных на территории РФ

B2B
Решение:
сервис,
имеющий
облачную
архитектуру,
которые
позволяет
организовать взаимодействие участников проекта по заданным требованиям.

Потребительские сегменты
o Сервис ориентирован на распределенные компании среднего и крупного
бизнеса, занимающихся проектной деятельностью с привлечение
субподрядных организаций.
o Компаний малого бизнеса, ещё не выстроивших свою инфраструктуру.

Ценностное предложение:
Ведение коммуникаций проекта на единой платформе для всех участников
проекта, включая:
o Звонки;
o ВКС;
o Демонстрация и управление экраном;
o Работа над документами;
65
o Отслеживание статуса участника;
o Безопасность передачи данных;
o Хранение данных на территории РФ;

Каналы-сбыта:
o Продажи через интернет;
o Партнерские подписки: Компании-интеграторы и прочие компании
имеющие распределенные проекты;

Модели продаж:
o Freemium – бесплатная версия до 5 пользователей;
o Field Sales – визиты в компании для продаж ЛПР (сегмент крупного и
среднего бизнеса);

Взаимоотношения с клиентами:
o Самообслуживание–индивидуальные настройки, инструкции, онлайн
тех поддержка;
o Поддержка – продажа лицензий, обучение, поддержка в случае крупных
сделок для построения коммуникаций между участниками среднего и
крупного бизнеса на проекте;

Потоки поступления дохода:
o Продажа лицензий;
o Поддержка проекта и кастомизация;

Ключевые ресурсы:
o Разработчики ПО
o Специалисты по продажам;

Ключевые виды деятельности:
o Платформа/сети;
o Разработка и развитие коммуникационной платформы;

Ключевые партнеры:
o Компании –интеграторы;
o Компании-поставщики ПО;
o Телекоммуникационные компании;
66

Структура издержек:
o Люди – заработная плата разработчиков;
o Содержание платформы – затраты на аппаратное обеспечение,
хостинг, ЦОД;
o Маркетинг и продажи – продвижение продукта на рынке;
o Поддержка
пользователей
–
поддержка
пользователей
платформы;
3.4.
Выводы по третьей главе
В третьей главе рассмотрены и описаны методы и инструменты
нивелирования рисков проектов системной интеграции. В рамках анализа
методов были предложены модели управления требованиями и изменениями
для использования в компании, на базе которого проводилось исследование
рисков.
В Приложении 4 представлен свод методов и инструментов по
нивелированию рисков, выявленных на этапе анализа. В данной работе
подробно
разработан
вопрос
нивелирования
рисков
управления
требованиями, изменениями и риски коммуникаций.
Для оценки инструментов нивелирования коммуникативных рисков
проекта были рассмотрены отчеты аналитического агентства Gartner по
одному из самых популярных направлений систем коммуникации UCaS, –
облачные решения корпоративного уровня для построения коммуникаций.
Также проведена оценка онлайн-сервисов для коммуникации. Анализ
работы проектной команды показал потребность в построении единой
платформы для коммуникации в проекте с распределенными участниками из
разных компаний, а также при участии частных лиц.
Для разработки и развития таких сервисов в России на текущий момент
есть все предпосылки. Решения-российских разработчиков, которые сейчас
присутствуют на рынке могут быть доработаны и развиваться в другом
потребительском секторе – корпоративном.
67
Заключение
Основной целью исследования было выявление рисков управления
проектами системной интеграции и возможностей для их нивелирования с
использованием современных методов и технологий.
Рассмотрев
текущее
состояние
рынка
ИТ-услуг
России,
была
определена роль проектов системной интеграции: они занимают весомую
долю на рынке ИТ-услуг (42%) и спрос на этот вид услуг будет лишь расти в
ткущих условиях.
В информационных источниках теоретический аспект системной
интеграции описан недостаточно.
В результате проведенной работы рассмотрены теоретические основы
системной интеграции, дано определение проекта системной интеграции и
описание
специфики
проектов
системной
интеграции
на
основе
консолидирования информационных источников и мнения экспертов в
управлении проектами.
Одной из основных задач в ходе исследования было проведение оценки
рисков проектов системной интеграции в практике российских ИТ-компаний.
Площадкой для проведения оценки рисков стала компания-интегратор ЗАО
«СофтЛайн Трейд». В результате опроса экспертов был сформирован
перечень рисков, характерных для проектов системной-интеграции в
компании и получена тепловая карта рисков с распределением рисков по
уровням в зависимости от их последствий и вероятности возникновения.
Основные риски критичного и высокого уровня – это риски, связанные
с управлением требованиями, изменениями и коммуникациями участников
проекта. На основе представленных рисков был сделан вывод о том какие
потребности (методологические и технические) в управлении проектами
системной интеграции существуют на данный момент.
Для нивелирования выявленных рисков на методологическом уровне в
ходе работы были разработаны и описаны процессы разработки требований и
68
управления изменениями для компании, на базе которой производилось
исследование.
Коммуникативные риски проектов являются одними из самых высоких
рисков, выявленных на этапе оценки. Наличие рисков такого типа говорит о
потребности в техническом решении для нивелирования рисков. В ходе
работы
была
проведена
сравнительная
характеристика
решений
корпоративного уровня для построения унифицированных коммуникаций, а
также анализ онлайн-сервисов, существующих на рынке.
По итогам исследования был сделан вывод о необходимости разработки
(доработки) сервиса объединенных коммуникаций, который смог бы
удовлетворить текущие потребности участников проектов, таких, например,
как проекты системной интеграции. В работе описана бизнес- модель B2B
сервиса для построения коммуникации распределенных участников проектов.
В дальнейшем необходима более детальная проработка бизнес-модели:
описание бизнес-процессов, более детальный обзор рынка и потребительских
сегментов, архитектура системы.
Взяв за основу сегмент проектов системной интеграции, в ходе работы
было проведено выявление основных рисков и потребностей для управления
такими проектами, на основе чего был сделан вывод о существовании
сегмента в котором может и должен появиться сервис способный
удовлетворить технические требования пользователей.
Таким образом, удалось выявить специфику проектов системной
интеграции и описать необходимые сервисы для поддержки управления
проектами системной интеграции.
69
Библиографический список
1. A Guide to the Project Management Body of Knowledge ( PMBOK® Guide ) —
Fifth Edition (ENGLISH) // PMI, 2013 589 pages.
2. Национальный стандарт РФ ГОСТ Р ИСО/МЭК 31010 —2011 [Электронный
ресурс]:
//
URL:
http://ivan-shamaev.ru/wp-content/uploads/2013/05/31010-
2011_Russia.pdf (дата обращения 11.03.2015).
3. Агапов В., Яковлев С., Пратусевич В. Обзор и оценка перспектив развития
мирового и российского рынков информационных технологий 2014 IDC
Russia [Электронный ресурс]: // URL: http://www.rusventure.ru/ru/pressservice/news/detail.php?ID=45815 (дата обращения 15.04.2015).
4. Атапина Н. В. Сравнительный анализ методов оценки рисков и подходов к
организации риск-менеджмента [Электронный ресурс] / Н. В. Атапина //
Молодой ученый. — 2013. — №5. — С. 235-243.
5. Балашов, А. И. Управление проектами: учебник для бакалавров / А. И.
Балашов,Е. М. Рогова, М. В. Тихонова, Е. А. Ткаченко; под ред. Е. М. Роговой.
—М.: Издательство Юрай, 2013. — 383 с.
6. Белов И., Нижникова Е «Рекомендации стандартов управления проектами не
следует принимать как...» [Электронный ресурс] /И. Белов, Е. Нижникова //
Директор информационной службы — 2014 г — №7. —с 14-19
7. Богданов В. Можно ли обойтись без автоматизации процессов управления
проектами? [Электронный ресурс]: 12.06.2013 // URL: http://www.bogdanovassociates.com/rubrs.asp?rubr_id=534&art_id=563 (дата обращения 23.02.2015)
8. Говорков А. С. О некоторых проблемах управления проектами [Электронный
ресурс] / А. С. Говорков // Молодой ученый. — 2009. — №3. — С. 45-47.
9. Гринберг, А. С. Информационный менеджмент [Электронный ресурс]: Учеб.
пособие для вузов / А. С.Гринберг, И. А. Король. - М. : ЮНИТИ-ДАНА, 2012.
- 415 с. - (Серия «Профессиональный учебник: Информатика»). - ISBN 5-23800614-4.
70
10.Зырянов М. Риск-менеджмент в ИТ-службе [Электронный ресурс]:/М.
Зырянов.// «Директор информационной службы», . — 2014. — №9.
11.Кириллов И. От системной интеграции к Professional Services [Электронный
ресурс]:/ Кириллов И. // «СЕТИ И БИЗНЕС» — 2010 — №4 (53).
12.Корепанов М.Б., Зиле И. А., Фунтов В. Н. Создание информационной системы
управления
проектами
газодобывающего
предприятия
[Электронный
ресурс]:/ М.Б. Корепанов // URL: УПРАВЛЕНИЕ ПРОЕКТАМИ № 4 (13) –
2008.
13.Кравченко Т.К. Управление требованиями при реализации ИТ-проектов
[Электронный ресурс] / Н. В. Атапина // Бизнес-информатика. — 2013. —
№3(25). — С. 63-71.
14.Ладяев
Д.
Необходимость
[Электронный
ресурс]:
проведения
06.08.2014
предпроектного
//
URL:
обследования
http://www.elma-
bpm.ru/journal/2176/ (дата обращения 02.03.2015).
15.Русякова М. С. Обзор современных моделей оценки зрелости управления
проектами [Электронный ресурс] / М. С. Русякова // Молодой ученый. — 2014.
— №11. — С. 230-236.
16.Симионова
Н.Е.
[Электронный
Интеграционные
ресурс]
/
Н.
Н.Е.
проекты:
проблемы
Симионова
//
управления
Интернет-журнал
«НАУКОВЕДЕНИЕ» — 2013. — №3.
17.Султанов Ф.Ф. Межкорпоративная информационно-аналитическая система
мониторинга
проектной
деятельности
предприятия
менеджмента
[Электронный ресурс] /Ф.Ф. Султанов // Электронный журнал «Труды МАИ»
— 2014 — Выпуск №73.
18.Учитель, Ю. Г. Разработка управленческих решений [Электронный ресурс]:
учебник
для
студентов
вузов,
обучающихся
по
специальности
«Антикризисное управление» и другим экономическим специальностям,
специальности «Менеджмент организации» / Ю. Г. Учитель, А. И. Терновой,
К. И. Терновой. - 2-е изд., перераб. и доп. - М.: ЮНИТИ-ДАНА, 2012. - 383 с.
- ISBN 978-5-238-01091-5.
71
19.Фролкина Е. С. Насколько часто и почему происходит перерасход бюджета в
крупных инфраструктурных проектах / Е. С. Фролкина // Российский журнал
управления проектами. М.: ИНФРА-М. V. 3. I. 1. C. 3-16. DOI: 10.12737/2689
20.Холодков А. Системная интеграция: технический аспект [Электронный
ресурс]: 13.10.2014 // URL: http://www.ibs.ru/media/our-analytics/novaya-itrealnost-vyzovy-i-vozmozhnosti/ (дата обращения 15.04.2015).
21.Анализ методологий управления проектами [Электронный ресурс]: 17.01.2012
// URL: http://infostart.ru/public/296315/ (дата обращения 18.03.2015).
22.Обзор TAdvisor: Рынок ИТ России [Электронный ресурс]: Прогноз на 2015 год
// 10.04.2015. URL: http://www.tadviser.ru/ (дата обращения 15.04.2015).
23.Новая
ИТ-реальность:
вызовы
и
возможности
[Электронный
ресурс]:13.10.2014 // URL: http://www.ibs.ru/media/our-analytics/novaya-itrealnost-vyzovy-i-vozmozhnosti/ (дата обращения 15.04.2015).
24.О компании Softline [Электронный ресурс]: // URL: http://softline.ru/about (дата
обращения 01.02.2015).
25.Рейтинг консалтинговых компаний [Электронный ресурс]: 22.07.2014 // URL:
http://infostart.ru/public/296315/ (дата обращения 10.04.2015)
26.Управление изменениями в организации [Электронный ресурс]:/ 27.04.2015 //
URL:
http://www.ibcm.biz/Konsalting-izmeneniy/upravlenie-izmenenijami-v-
organizacii.html (дата обращения 01.05.2015).
27.CIS 8020 – Systems Integration, Georgia State University OECD [Электронный
ресурс]: // URL: http://elite.polito.it/files/courses/02CIX/SystemIntegration.pdf
(дата обращения 25.04.2015).
28.Gartner 2014 Magic Quadrant for Unified Communications as a Service,
Multiregional [Электронный ресурс]// URL [Электронный ресурс]// URL:
https://www.gartner.com/doc/2924518/critical-capabilities-unifiedcommunications-service (дата обращения 09.05.2015).
29.Gartner: Critical Capabilities for Unified Communications as a Service, North
America With Additional Regional Presence [Электронный ресурс]// URL:
72
https://www.gartner.com/doc/2924518/critical-capabilities-unifiedcommunications-service (дата обращения 09.05.2015).
30.Press Release Gartner: Gartner Says Worldwide IT Spending to Decline 1.3 Percent
in 2015 [Электронный ресурс]: STAMFORD, Conn., April 9, 2015 // URL:
http://www.gartner.com/newsroom/id/3025217 (дата обращения 15.04.2015).
31.System
integration,
definition
[Электронный
ресурс]:
//
URL:
httphttp://en.wikipedia.org/wiki/System_integration (дата обращения 20.01.2015).
73
Приложение 1
Результат проведения идентификации рисков методом Дельфи
1.1.
Анкета для опроса Экспертной группы ЗАО «ЗАО СофтЛайн Трей»
Опрос по теме технологичных проектов системной интеграции в нашей компании. Проекы, связанные с
построением архитектуры с системами нескольких классов, проекты включающие в себя работы от этапы проектирования
процессов до внедрения решения. Прошу вас вспомнить примеры таких проектов и ответить на вопросы:
1.
В скольких проектах системной интеграции вы приняли участие?
2.
Какая средняя длительность проектов?
3.
Сколько участников проекта в среднем?
4.
Сколько компаний-субподрядчиков, фрилансеров необходимо было привлекать для реализации таких
проектов?
5.
Каковы основные трудности в таких проектах?
6.
Опишите риски проектов в свободной форме:

При инициации проекта;

При планировании проекта;

При Исполнении проекта?

При Закрытии проекта?
Таблица11
Перечень рисков, идентифицированных в ходе опроса экспертной группы
№
Наиболее распространенные риски при реализации проектов системной интеграции
(экспертная оценка)
1.
1.1.
1.2.
1.3.
1.4.
1.5.
1.6.
1.7.
Этап 1. Инициация проекта
Отсутствие контакта с ключевыми стейкхолдерами проекта
Неверное понимание потребностей заказчика
Неверная постановка задач проекта и содержание работ
Снижение оперативности взаимодействия участников команды проекта
Анализ рисков не осуществляется на этапе планирования и подготовки продажи проекта
Конфликт интересов внутри Компании-Исполнителя
Конфликт внутри команды проекта при взаимодействии Исполнителей из разных компаний/подразделений,
ввиду отсутствия единого подхода к реализации проекта
Плохо проработана архитектура решения из-за отсутствия полных данных о инфраструктуре заказчика
Этап 2. Планирование проекта
Ошибка в планировании объема работ и трудозатратах Исполнителей,т.к. не проводятся первичный анализ и
оценка сложности проекта сотрудниками, которые станут непосредственными исполнителями по проекту
Недостаточная квалификация Исполнителей для осуществления проекта
Этап 3. Исполнение проекта
Риски, связанные с территориальной распределенностью проектной команды
Отсутствие единой точки коммуникации всех участников проекта как со стороны Исполнителя, так и
Заказчика (ВКС, переговоры, демонстрации)
Увеличение расходов на командировки Исполнителей
Проблемы с подключением к сети интернет
1.8.
2.
2.1.
2.2.
3.
3.1.
3.2.
3.3.
3.4.
75
№
Наиболее распространенные риски при реализации проектов системной интеграции
(экспертная оценка)
3.5.
Риски,
связанные
с
участием
в
проектной
команде
представителей
нескольких
компаний/региональных хабов компании Softline
Потеря контроля при ведении проекта из-за перегруженности руководителей проекта
Конфликт интересов между проектами, в которых Заняты Исполнители
Нарушение субординации/зон ответственности внутри команды проекта
Конфликты внутри команды проекта
Смена участников проектной команды Исполнителя до завершения проекта
Отказ от выполнения работ субподрядчиком (субподрядчик не заинтересован в результате проекта)
Невозможность ведения совместной работы участников проектной команды (Использование разных, порой
несовместимых технологий для коммуникации (совместная обработка документов)
Невозможность удаленной работы из-за политик безопасности участников проекта
Риски, связанные с отсутствием ограничений по проекту
В договоре и техническом задании нет четкого описания границ проекта
Завышенные ожидания по проекту и Заказчика
Нет понимания стейкхолдеров проекта на стороне Заказчика, не ведется управление стейкхолдерами
Сложный и продолжительный этап согласования на стороне Заказчика
Изменение требований со стороны Заказчика
Частая недоступность ключевых работников Заказчика
Не сформирована/лишь формально сформирована команда проекта на стороне компании-Заказчика
Этап 4. Закрытие проекта
Процедура закрытия проекта слабо формализована в Договоре
Давления Заказчика, «репутационные риски»
Реализации смежных (не имеющих прямого отношения к проекту) задач специалистами проектной команды
3.6.
3.7.
3.8.
3.9.
3.10.
3.11.
3.12.
3.13.
3.14.
3.15.
3.16.
3.17.
3.18.
3.19.
3.20.
3.21.
4.
4.1.
4.2.
4.3.
76
Приложение 2
Результат оценки рисков Экспертной группой
Таблица 12
Оценка рисков проекта системной интеграции экспертной группой
Уровень
риска
Риски
Этап 1. Инициация проекта
Отсутствие контакта с ключевыми стейкхолдерами проекта
Неверное понимание потребностей заказчика
III
II
Неверная постановка задач проекта и определение содержания работ
II
Снижение оперативности взаимодействия участников команды проекта
III
Анализ рисков не осуществляется на этапе планирования и подготовки
продажи проекта
Конфликт интересов внутри Компании-Исполнителя
II
III
Конфликт внутри команды проекта при взаимодействии Исполнителей
из разных компаний/подразделений, ввиду отсутствия единого подхода
к реализации проекта
III
Плохо проработана архитектура решения из-за отсутствия полных
данных о инфраструктуре заказчика
II
Этап 2. Планирование проекта
Ошибка в планировании объема работ и трудозатратах Исполнителей
,т.к. не проводятся первичный анализ и оценка сложности проекта
сотрудниками, которые станут непосредственными исполнителями по
проекту
II
Недостаточная
проекта
III
квалификация
Исполнителей
для
осуществления
Этап 3. Исполнение проекта
Риски, связанные с территориальной распределенностью проектной команды
Сложности в коммуникации в реальном времени между участниками
II
проекта
Увеличение расходов на командировки Исполнителей
II
Проблемы с подключением к сети интернет
III
Риски, связанные с участием в проектной команде представителей нескольких
компаний/региональных хабов компании
Риски
Уровень
риска
Этап 1. Инициация проекта
Потеря контроля при ведении проекта из-за перегруженности
руководителей проекта
III
Конфликт интересов между проектами, в которых Заняты Исполнители
II
Нарушение субординации/зон ответственности внутри команды
проекта
Конфликты внутри команды проекта
Смена участников проектной команды Исполнителя до завершения
проекта
IV
III
II
Отказ от выполнения работ субподрядчиком (субподрядчик не
заинтересован в результате проекта)
II
Отсутствие единой точки коммуникации всех участников проектной
команды Исполнителя
II
Невозможность ведения совместной работы участников проектной
команды (Использование разных, порой несовместимых технологий
для коммуникации (Заказчик, основная компания и субподрядчик
используют разное ПО), что приводит к сложности проведения
видеоконференций, демонстраций и семинаров.)
II
Невозможность удаленной работы из-за политик безопасности
участников проекта
Риски, связанные с отсутствием ограничений по проекту
II
В договоре и техническом задании нет четкого описания границ проекта
II
Завышенные ожидания по проекту и Заказчика
Нет понимания стекхолдеров проекта на стороне Заказчика, не ведется
управление стейкхолдерами
II
III
Сложный и продолжительный этап согласования на стороне Заказчика
II
Изменение требований со стороны Заказчика
Частая недоступность ключевых сотрудников Заказчика
Не сформирована/лишь формально сформирована команда проекта на
стороне компании-Заказчика
I
III
III
Этап 4. Закрытие проекта
Процедура закрытия проекта слабо формализована в Договоре
II
Давления Заказчика для расширения работ (Реализации смежных (не
имеющих прямого отношения к проекту) задач специалистами
проектной команды)
III
78
Приложение 3
Оценка решений унифицированных коммуникаций как услуги (CaaS) на мировом рынке
Таблица 13
Вес требований к функциям CaaS –решения по типам компаний
Малый и средний
бизнес
Крупный бизнес:
незначительные
требования к UCрешениям
Крупный бизнес:
полнофункциональное
UC-решение
Международные
компании к UCрешениям
Телефония
20%
25%
20%
20%
Мобильность
5%
5%
5%
5%
Организация конференц-связи
(Аудио/Видео/Веб)
5%
5%
15%
15%
Портал самообслуживания пользователей
10%
10%
10%
10%
Установка и интеграция
10%
10%
10%
10%
Предоставляемые услуги и поддержка
25%
20%
15%
15%
Услуги для малого и среднего бизнеса
25%
0%
0%
0%
Услуги для крупного бизнеса
0%
25%
25%
10%
Международная поддержка
0%
0%
0%
15%
100%
100%
100%
100%
Критичные функции
Итого
Таблица 14
8x8
Arkadin
AT&T
Avanade
CSC
Google
HP
iCore
Intermedia
Microsoft
Mitel
Orange Business
Services
RingCentral
ShoreTel
Sprint
Star2Star
Communications
Telefonica
Telesphere
Thinking Phone
Networks
Verizon
West
Оценка решений унифицированных коммуникаций как услуги (CaaS) на мировом рынке
Телефония
4.0
2.0
4.0
3.0
3.0
1.0
3.5
4.0
2.0
1.5
4.0
4.0
3.5
4.0
3.0
3.5
3.5
4.0
4.0
4.0
4.0
Мобильность
4.0
3.0
3.0
3
3.0
3.0
3.0
3.0
2.0
3.0
3.0
3.0
4.0
3.0
3.0
2.0
3.0
2.5
3.5
3.0
3.0
Организация
конференц-связи
(Аудио/Видео/Ве
б)
2.0
4.0
4.0
3.0
3.0
4.0
3.0
2.0
2.0
2.5
3.0
4.0
3.0
2.0
2.0
2.5
3.0
2.0
2.0
3.0
4.0
Портал
самообслуживани
я пользователей
4.0
3.0
2.0
2.0
2.0
4.0
3.0
3.0
4.0
4.0
3.0
4.0
4.0
3.0
2.0
3.0
2.5
3.0
4.0
2.5
3.5
Установка и
интеграция
2.0
3.0
3.0
4.0
3.0
2.0
4.0
3.0
3.0
2.0
3.0
3.0
2.0
3.0
3.0
3.0
3.0
4.0
4.0
3.0
3.0
Предоставляемые
услуги и
поддержка
4.0
3.0
3.0
3.0
3.0
2.0
3.0
3.0
4.0
3.0
3.0
3.0
3.0
3.0
3.0
4.0
2.0
4.0
4.0
2.5
3.5
Услуги для
малого и
среднего бизнеса
5.0
4.0
2.0
1.0
1.0
4.0
1.0
4.0
4.0
4.0
4.0
2.0
5.0
3.0
3.0
4.0
3.0
3.5
4.0
3.0
3.0
Услуги для
крупного бизнеса
2.0
2.0
4.0
4.0
4.0
3.0
3.5
2.0
2.0
3.0
3.0
3.0
1.0
3.0
2.0
3.5
2.5
2.5
2.5
4.0
3.5
Критичные
функции
80
Arkadin
AT&T
Avanade
CSC
Google
HP
iCore
Intermedia
Microsoft
Mitel
Orange Business
Services
RingCentral
ShoreTel
Sprint
Star2Star
Communications
Telefonica
Telesphere
Thinking Phone
Networks
Verizon
West
Международная
поддержка
8x8
Критичные
функции
2.0
3.0
4.0
4.0
3.0
4.0
4.0
1.0
1.0
4.0
2.5
5.0
2.0
1.0
2.0`
1.0
3.5
1.0
2.5
2.5
3.5
8x8
Arkadin
AT&T
Avanade
CSC
Google
HP
iCore
Intermedia
Microsoft
Mitel
Orange Business
Services
RingCentral
ShoreTel
Sprint
Star2Star
Communications
Telefonica
Telesphere
Thinking Phone
Networks
Verizon
West
Таблица 15
Оценка решений унифицированных коммуникаций как услуги (CaaS) по типам компаний-потребителей
Малый и средний
бизнес
3.95
3.10
2.90
2.50
2.40
2.65
2.70
3.40
3.30
2.93
3.45
3.10
3.65
3.15
2.85
3.53
2.80
3.60
3.88
3.03
3.43
Крупный бизнес:
незначительные
требования к УКрешениям
3.20
2.55
3.45
3.25
3.15
2.35
3.35
2.95
2.70
2.60
3.25
3.40
2.68
3.20
2.60
3.38
2.75
3.35
3.50
3.35
3.58
Крупный бизнес:
полнофункционально
е УК-решение
3.00
2.70
3.50
3.25
3.15
2.60
3.33
2.80
2.60
2.63
3.20
3.45
2.65
3.05
2.50
3.25
2.78
3.15
3.30
3.33
3.60
Международные
требования к УКрешениям
3.00
2.85
3.50
3.25
3.00
2.75
3.40
2.65
2.45
2.78
3.13
3.75
2.80
2.75
2.50
2.88
2.93
2.93
3.30
3.10
3.60
Критичные
функции
81
Приложение 4
Методы и инструменты нивелирования рисков, выявленных на этапе анализа
Таблица 16
Риски
Уровень
риска
Сводная таблица методов и инструментов нивелирования рисков управления проектами системной интеграции
Тип риска
Метод нивелирования
Инструмент нивелирования
Этап 1. Инициация проекта
Неверное понимание потребностей
заказчика
I
Требования
Внедрение модели разработки
требований
Использование ПО разработки
требований
Неверная постановка задач проекта и
определение содержания работ
II
Требования
Внедрение модели разработки
требований
Использование ПО разработки
требований
Анализ рисков не осуществляется на
этапе планирования и подготовки
продажи проекта
II
Оценка рисков
Внедрения процесса оценки
рисков проекта
−
Плохо проработана архитектура
решения из-за отсутствия полных
данных о инфраструктуре заказчика
II
Требования
Проведение предпроектного
обследования инфраструктуры
заказчика
Использование ПО разработки
требований
82
Риски
Уровень
риска
Тип риска
Ошибка в планировании объема работ
и трудозатратах Исполнителей, т.к. не
проводятся первичный анализ и
оценка
сложности
проекта
сотрудниками,
которые
станут
непосредственными исполнителями
по проекту
II
Процессные
Метод нивелирования
Инструмент нивелирования
Формирование команды проекта
на этапе инициации
−
Этап 3. Исполнение проекта
Риски, связанные с территориальной распределенностью проектной команды
Сложности в коммуникации в
реальном
времени
между
участниками проекта
II
Коммуникатив
ные
Коммуникационный план проекта
UCaS-системы, новые онлайн
сервисы колаборации
Увеличение
расходов
командировки Исполнителей
II
Коммуникатив
ные
−
UCaS-системы, новые онлайн
сервисы колаборации
на
Риски, связанные с участием в проектной команде представителей нескольких компаний/региональных хабов компании
Конфликт
интересов
проектами, в которых
Исполнители
между
Заняты
Смена
участников
проектной
команды Исполнителя до завершения
проекта
II
II
Политические
План проекта, диаграмма Ганта
−
Процессные
Ведение карты стейкхолдеров
участников проекта, работа с
ключевыми специалистами
Автоматический мониторинг
сервисов по поиску вакансий,
отслеживание резюме и
активностей сотрудников
83
Отказ
от
выполнения
работ
субподрядчиком (субподрядчик не
заинтересован в результате проекта)
Отсутствие
единой
точки
коммуникации
всех
участников
проекта как со стороны Исполнителя,
так и Заказчика (ВКС, переговоры,
демонстрации)
Невозможность ведения совместной
работы
участников
проектной
команды
Исполнителя
над
разработкой документов (проектная,
сопроводительная).
Невозможность
удаленного
подключения
из-за
политик
безопасности участников проекта (со
стороны Исполнителя и Заказчика)
Уровень
риска
Риски
Тип риска
Метод нивелирования
Инструмент нивелирования
II
Процессные
Составления реестра проверенных
субподрядчиков, Ведение карты
стейкхолдеров участников
проекта
−
II
Коммуникатив
ные
−
UCaS-системы, новые онлайн
сервисы, системы онлайн
колоборации
II
Коммуникатив
ные
−
Системы совместной обработки
документов нового онлайн-сервиса
−
Перенос процесса разработки в
виртуальную среду, тестовый стенд
доступный всем участникам
проектной команды
II
Коммуникатив
ные
В договоре и техническом задании
нет четкого описания границ проекта
II
Требования
Завышенные ожидания по проекту у
Заказчика
II
Требования
Внедрения стандартов
технической документации в
Компании
Согласование и утверждение
документов: Устав проекта,
Договор, Техническое задание
−
−
84
Риски
Уровень
риска
Сложный и продолжительный этап
согласования на стороне Заказчика
II
Изменение требований со стороны
Заказчика
I
Процедура закрытия проекта слабо
формализована в Договоре
II
Тип риска
Метод нивелирования
Время согласования
Требования
закладывается на этапе
подписания Договора
Внедрение процесса управления
изменениями,
Требования
Согласование процесса
управления изменениями на этапе
подписания Договора
Этап 4. Закрытие проекта
Согласование Договора с
Юридическим департаментом.
Требования
Формализация требований на
этапе предпроектного
обследования.
Инструмент нивелирования
−
−
−
85