Описание проектного процесса в компании сотовой связи до внедрения корпоративной системы управления проектами

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

По доработкам биллинговой системы после получения основных функциональных требований и коммерческого предложения проекта от поставщика инициатор и бизнес-аналитик в течение 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. Структуризация проектного процесса, создание универсального план-графика.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

Размещено на Allbest.ru