Глава 3. Внедрение корпоративной системы управления проектами в компании сотовой связи.

1. Роль и задачи направления Проектов по продуктам.

В мае 2016 года руководством рассматриваемой нами компании сотовой связи было принято решение пересмотреть организационную структуру компании, чтобы оптимизировать процессы запуска новых продуктов (сокращение time-to-market). Еще одной причиной решения о внедрении КСУП в компании было сосредоточиться на стратегических проектах, чтобы эффективно достигать долгосрочных целей и выполнения бюджета.

Первым шагом к внедрению КСУП было создание нового направления в рамках дирекции по продукту – направление Проектов по продуктам. Таким образом, внедрение КСУП началось изнутри компании.

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

Как было сказано ранее, направление Проектов по продуктам выполняет, прежде всего, базовые функции проектного офиса.

Согласно классификации офисов управления проектами, описанной в PMBoK 5^th edition, направление проектов по продуктам является контролирующим подразделением:

• Обеспечивает соответствие регламентированным процессам по проектам

• Занимается разработкой методологий эффективного управления проектами

• Разрабатывает шаблоны и формы, инструменты для более тщательного контроля запуска проектов (реестр проектов и обобщение информации)

• Обеспечивает обучение менеджеров проектному управлению.

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

2. Процесс создания Политики по коммерческим проектам, результат.

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

Целями политики является:

• обеспечение единых бизнес-процессов одобрения идеи, утверждения и реализации коммерческих проектов компании;

• эффективное взаимодействие работников коммерческих и технических подразделений, а также представителей других департаментов в рамках проектного процесса;

• сокращение времени, необходимого для реализации проектов от идеи до запуска;

• своевременный запуск проектов работниками компании.

Для создания Политики необходимо было выполнить следующие задачи:

1. Изучить имеющийся процесс запуска от идеи до запуска

2. Выделить четкие фазы проекта и разграничить их контрольными событиями

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

4. Декомпозировать общие процессы

5. Экспертно оценить оптимальную длительность каждого этапа проекта

6. Определить и утвердить состав группы, которой будет приниматься решение о реализации проекта.

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

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

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

• Анализ идеи;

• Утверждение идеи проекта

• Проработка и оценка требований (Prestudy);

• Утверждение результатов Prestudy и начала реализации проекта на Development Board;

• Утверждение размера инвестиций, проведение закупочных процедур и подписание контракта;

• Техническая разработка по проекту и подготовка к тестированию;

• Поставка функционала и тестирование;

• Финализация материалов по проекту;

• Запуск пилота и его анализ;

• Запуск в коммерческую эксплуатацию;

• Постанализ реализации проекта.

Анализ идеи.

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

Утверждение идеи проекта.

На данном этапе проект выносится на обсуждение Комитета в первый раз, где принимается решение о реализации проекта и ему присваивается приоритет.

Проработка и оценка требований

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

Утверждение результатов Prestudy и начала реализации проекта на Development Board.

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

Срок ответа участников РГ не должен превышать 3 рабочих дня. По результатам проработки инициатор размещает финальные согласованные требования в TFS (платформа для коммуникаций Team Foundation Server, ее мы более подробно рассмотрим в следующем разделе).

Утверждение размера инвестиций, проведение закупочных процедур и подписание контракта.

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

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

При утверждении результатов Prestudy и принятии решения о реализации проекта технический ПМ готовит материалы для утверждения IP по проекту (Investment Proposal). Утверждение IP заявок проводится согласно Политике по капитальным инвестициям с момента ее подписания.

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

С текущим поставщиком биллинговой системы заключен рамочный договор, и IP утверждается заранее.

Техническая разработка по проекту и подготовка к тестированию.

На данном этапе инициатор проекта совместно с рабочей группой составляет программу тестирования, детальные кейсы тестирования, определяет периметр тестирования и критерии его успешности.

Техническим управлением готовится тестовая среда и технические подсистемы для проведения тестирования.

Поставка функционала и тестирование.

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

В случае обнаружения ошибок в настройках, работник службы D&I сразу передает информацию в ЦБ и поставщику.

Финализация материалов по проекту.

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

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

Запуск пилота и его анализ.

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

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

• На Управляющем комитете – по проектам, связанным с изменением продуктового портфеля, или

• На Комитете по развитию – по прочим проектам, не связанным с изменением продуктового портфеля.

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

Запуск в коммерческую эксплуатацию.

Инициатор проекта совместно с рабочей группой организовывает запуск проекта в коммерческую эксплуатацию согласно плану запуска.

Постанализ реализации проекта.

Для определения фактических результатов проекта необходимо проводить постанализ реализации. План проведения постанализа и сроки разрабатываются инициатором и РГ при проработке бизнес-кейса . При этом рекомендуемые сроки проведения постанализа следующие: через 1, 2, 3, 6, 12, 24 месяца после коммерческого запуска проекта.

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

По проектам первого приоритета подготовку кейса осуществляет Служба поддержки бизнеса совместно с инициатором.

Основной сложностью при создании политики было отсутствие исторической информации о запуске проектов до внедрения КСУП, процесс пришлось восстанавливать со слов менеджеров, что значительно затянуло процесс формирования политики.

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

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

Следующим внедренным инструментом КСУП в компании стало внедрение платформы TFS – team foundation server. Данная платформа является аналогом описанных нами в главе 1 решений для строительных китайских компаний, позволяющих решить проблему коммуникации между участниками проекта.

Это продукт корпорации Microsoft, представляющий собой комплексное решение, объединяющее в себе систему управления версиями, сбор данных, построение отчётов, отслеживание статусов и изменений по проекту и предназначенное для совместной работы над проектами по разработке программного обеспечения.

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

4. Структуризация проектного процесса, создание универсального план-графика.

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

Этап проекта	Длительность (раб.дни)	Ответственный
Анализ идеи	18
Разработка идеи, подготовка заявки по проекту в виде презентации	3	Инициатор проекта
Верхнеуровневый экспресс-расчет эффекта	3	Инициатор проекта
Согласование идеи и ее предварительного приоритета с Директором направления	1	Инициатор проекта
Экспресс-оценка с Биллингом и Техническим Проектным офисом	5	Инициатор проекта, Биллинг, ТПО
Обсуждение с действующим вендором в случае необходимости	5	Инициатор проекта, Биллинг, ТПО, Поставщик
Согласование оценки с Директором направления. Внесение в RoadMap подразделения	1	Инициатор проекта
Подготовка и вынесение на DB	16
Обновление презентации по проекту для вынесения на DB	2	Инициатор проекта
Предоставление материалов в адрес Направления проектов по продуктам	1	Инициатор проекта
Предварительная сессия с Директором функции	3	Инициатор проекта
Предварительная сессия с Технической дирекцией	3	Направление проектов по продуктам
Рассмотрение и утверждение проекта на DB	1	DB
Создание рабочей группы, выделение PM	1	Инициатор проекта, ТПО
ТЗ + оценка (Prestudy)	32
Подготовка детальных требований, пользовательских сценариев	10	Инициатор проекта, Рабочая группа
Оценка требований аналитиками Поставщика (стоимость + срок), проработка вопросов с заказчиком, проработка ОФТ	15	Поставщик, Инициатор проекта, Бизнес-аналитик
Расчет бизнес-кейса с учетом затрат	49	Инициатор проекта, Рабочая группа
Согласование кейса с Директором направления	1	Инициатор проекта
Подготовка материалов PreStudy	5	ТПО, Инициатор проекта
Подготовка и предоставление материалов на DB в адрес Направления проектов по продуктам	2	ТПО, Инициатор проекта
Утверждение на DB результатов PreStudy	1	Проектный менеджер, DB
IP/Закупочные процедуры	87
Формирование IP	5	Проектный менеджер (ТПО), Инициатор проекта
Утверждение IP	1	Проектный менеджер (ТПО)
Инициация закупочных процедур	5	Проектный менеджер (ТПО)
Проведение закупочных процедур, утверждение результатов	64	Проектный менеджер (ТПО)
Подписание договора	15	Проектный менеджер (ТПО)
Подготовка к тестированию	- 2
Подготовка программы тестирования, детальных кейсы тестирования, определяет периметр тестирования и критерии его успешности	5	Инициатор, рабочая группа
Подготовка к тестированию необходимых подсистем	7	ТПО, рабочая группа
Поставка и тестирование	29
Дата отгрузки функционала
Поставка и установка на тестовую среду	2	Поставщик, ТПО
Тестирование на тестовой БД	19
Технические тестирование: регресс-тесты	3	ТПО
Исправление ошибок по результатам регресс-тестов	5	Поставщик, ТПО
Функциональное тестирование на тестовой БД и ведение протоколов тестирования. Пользовательское тестирование	4	Инициатор, рабочая группа
Эскалация ошибок Поставщику	1	Инициатор, ТПО
Исправление ошибок по результатам функционального тестирования	5	Поставщик, ТПО
Отгрузка исправлений (далее с 6.2.5. могут быть итерации)	1	Поставщик, ТПО
По результатам тестирования ошибки не зафиксированы	2	Инициатор, рабочая группа
Поставка и установка на продуктивную БД	5	Поставщик, ТПО
Разработка дополнительных материалов	10
Подготовка презентации по проекту и FAQ для пользователей	2	Инициатор проекта, Имплементация
Подготовка описания проекта для размещения на сайт в случае необходимости	3	Инициатор проекта, PR
Подготовка прочих документов в случае необходимости	5	Инициатор проекта, Обслуживание
Пилот	27
Размещение информации о старте пилота	1	Инициатор проекта
Проведение обучения участников Пилотного проекта	2	Инициатор проекта
Запуск пилота в ОКЭ	2	Инициатор проекта
Анализ Пилота	22	Инициатор проекта
Утверждение результатов пилота и дальнейших запусков на DB или УК	1	Инициатор проекта
Финализация материалов на запуск по результатам пилота	2	Инициатор проекта
Готовность к запуску в Комм.эксплуатацию = Ready for Service		Инициатор проекта, ТПО
Запуск в коммерцию, Rollout	10
Размещение информации о запуске проекта	1	Инициатор проекта
Подготовка плана запуска	2	Инициатор проекта, ТПО
Проведение обучения участников проекта	3	Инициатор проекта
Коммерческий запуск	5	Инициатор проекта, ТПО
Постанализ проекта	22
Постанализ по результатам коммерческого запуска	22	Инициатор проекта

Таблица 5. Типовой план-график выполнения проекта

5. Анализ результатов внедрения элементов КСУП: сравнение длительности реализации схожих проектов до и после внедрения элементов КСУП.

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

Визуализация выполнена с помощью схематического представления в программе Power Point. Мы не стали использовать диаграмму Гантта в качестве визуализации, так как проекты обширны и сравнение двух диаграмм не даст четкого представления о сроках.

Рис. 8 Сравнение сроков выполнения: 1 – проект, реализуемый после внедрения КСУП; 2 – проект, начавшийся до внедрения КСУП: 3 – сроки по типовому план-графику

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

Мы не стали рассматривать в качестве ключевого показателя эффективности КСУП выручку от данных проектов в следствие конфиденциальности информации. Посмотреть динамику изменения выручки во времени от других проектов не удалось в силу того, что прошло недостаточно времени с момента внедрения первых инструментов КСУП в компании и данные не отразили бы влияние непосредственно КСУП.

6. Описания инструментария контроля за коммерческими проектами.

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

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

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

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

• Даты-milestones проектов. Инструмент находится в разработке. В данном реестре проектов будут содержаться обобщенные основные вехи каждого проекта, например, дата отгрузки функционала или дата запуска пилота. С помощью инструментов MS Excel документ отформатирован так, чтобы приближающиеся даты выделялись и можно было узнать статус наступления того или иного контрольного события.

Выводы.

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

Проблема	Инструментарий
Неэффективное распределение человеческих ресурсов	Политика по коммерческим проектам, development board
Отсутствие унификации методологии расчета эффекта от проектов	Политика по коммерческим проектам, контроль направлением Проектов по продуктам, реестр бизнес-кейсов
Слабая коммуникация между разными департаментами организации и внешними партнерами	Платформа TFS, еженедельные статусные встречи
Отсутствие четко установленного жизненного цикла проектов	Политика по коммерческим проектам, реестр вех проектов, типовой план-график проектов
Слабое планирование на подготовительном этапе	Development board, roadmap
Задвоение процессов	Политика по коммерческим проектам, контроль направлением Проектов по продуктам
Слабое разграничение этапов работ	Политика по коммерческим проектам
Отсутствие контроля тайминга	Политика по коммерческим проектам, контроль направлением Проектов по продуктам, development board, реестр вех проектов, типовой план-график проектов

Таблица 6. Соответствие внедренного инструментария с выявленными проблемами

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

Заключение.

Проанализировав опыт внедрения корпоративной системы управления проектами в нескольких российских и зарубежных компаниях, а также проектный процесс в рассматриваемой нами компании сотовой связи до и после внедрения КСУП, мы можем оценить опыт внедрения КСУП в компании сотовой связи как удачный, поскольку внедрение уже показывает положительные результаты time-to-market и высвобождения человеческих ресурсов. Создание внутреннего нормативного акта, регламентирующего проектный процесс, структурировало набор проектных задач, позволило избежать неэффективного распределения ресурсов.

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

• Развитие коммуникаций с партнерами. Следует налаживать процесс коммуникаций не только с постоянным поставщиком, но и с поставщиками, выбираемыми посредством тендера. Для этого нужно развивать взаимодействие в системе TFS.

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

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

1 Н.П. Резникова, Е.В. Демина, В.Б. Булгак  и др.. Менеджмент в телекоммуникациях / Под ред. Н.П. Резниковой, Е.В. Деминой. — М.: Эко-Трендз. — 392 с.

2 Фомина Т. А. Анализ рынка операторов сотовой связи // Молодой ученый. — 2015. — №18. — С. 466-468.

3 Liyang Hou. A review of telecom markets in the EU: What did the European Commission learn or not from the past? - vol. 30. - 2014. - pp. 710-719.

4Руководство к своду знаний по управлению проектами (Руководство PMBOK). Пятое издание// Project Management Institute, 2013. – 614 с.