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

Размещено на http://www.allbest.ru/

Содержание

Введение

Глава 1. Обзор внедрения корпоративной системы управления проектами в российских и зарубежных компаниях

1.1 Целесообразность внедрения КСУП в проектно-ориентированных компаниях

1.2 КСУП в российских компаниях

Глава 2. Описание проектного процесса в компании сотовой связи до внедрения КСУП

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

Заключение



Введение

Тема работы «Внедрение корпоративной системы управления проектами в компании сотовой связи» была выбрана нами по причине отсутствия в России развития методов управления проектами, которые учитывали бы специфику отрасли сотовой связи, так как продукты данной отрасли можно отнести к сфере товаров повседневного спроса, однако для их производства и внедрения необходим тесный контакт с поставщиками высокотехнологичного функционала Н.П. Резникова, Е.В. Демина, В.Б. Булгак  и др.. Менеджмент в телекоммуникациях / Под ред. Н.П. Резниковой, Е.В. Деминой. -- М.: Эко-Трендз. -- 392 с..

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

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

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

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

· Компаниям необходим более точный процесс бюджетирования, используя КСУП можно наиболее реалистично спрогнозировать денежные потоки, а также операционные и капитальные затраты Руководство к своду знаний по управлению проектами (Руководство PMBOK). Пятое издание// Project Management Institute, 2013. - 614 с..

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

Объектом исследования нашей работы является российская компания сотовой связи. Предметом исследования являются процессы запуска новых продуктов в указанной компании на соответствующем рынке.

Задачи для достижения целей данной работы:

· Изучение опыта внедрения КСУП в российских и зарубежных компаниях различных отраслей

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

· Проведение интервью с инициаторами-руководителями проектов с целью выявления имеющихся проблем проектного процесса

· Изучение проектного процесса после внедрения КСУП

· Сравнение ключевых показателей компании до и после внедрения элементов КСУП.

В ходе работы нами будут использованы следующие методы научного исследования:

1. Обзор релевантных источников литературы

2. Глубинное интервью с инициаторами проекта

3. Уникальный эксперимент.

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

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

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

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

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



Глава 1. Обзор внедрения корпоративной системы управления проектами в российских и зарубежных компаниях

1.1 Целесообразность внедрения КСУП в проектно-ориентированных компаниях

Для обоснования внедрения корпоративной системы управления проектами в проектно-ориентированных компаниях мы используем данные исследования, который проводила фирма по разработке и внедрению КСУП PM Expert.

В 2012 году компания провела опрос сотрудников 34 компаний следующих секторов экономики: Информационные технологии/телекоммуникации 14, строительство/девелопмент 5, производство 4, компании ТЭК 2, государственные компании 2, металлургия 2, финансы 1, консалтинг 1, реклама 1, 2 компании со смешанным видом деятельности.

21% компаний составили крупные компании свыше 5000 человек, 15% большие компании от 1000 до 5000 человек, 18% средние компании от 300 до 1000 человек, 24% небольшие компании от 100 до 300 человек, 21% малые компании менее 100 человек.

Из 34 компаний в 30 компаниях внедрена КСУП.

Основные причины улучшений после внедрения КСУП, представлены в следующем списке

(по убыванию приоритета):

1. Появилась актуальная общая картина проектов,

2. Повысилась эффективность распределения ресурсов между проектами,

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

деятельности,

4. Повысилась удовлетворенность заказчика результатами проектов,

5. Сократились превышения бюджетов проекта,

6. Сократились временные задержки в выполнения проектов.По результатам опроса 14 компаний, в которых была внедрена КСУП, ответили, что в процессе запуска проектов заметны значительные улучшения, 13 компаний не заметили каких-либо изменений, 3 компании пожаловались на ухудшение ситуации: применение КСУП стало занимать больше времени при реализации проекта.

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

В статье «Тенденции развития управления проектами» автор описывает конкретные показатели, которые улучшились после внедрения в компании КСУП.

На основе опроса более 100 компаний в 2011 году, были получены следующие результаты:

Таким образом, внедрение корпоративной системы управления проектами положительно влияет на ключевые показатели эффективности компании, из чего мы делаем вывод, что КСУП целесообразно для проектно-ориентированной компании. http://cyberleninka.ru/article/n/tendentsii-razvitiya-upravleniya-proektami

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

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

КСУП в зарубежных компаниях

Внедрение элемента КСУП в китайских строительных компаниях.

Мы перевели название статьи Implementation of web-based construction project management system in China projects by Hong Kong developers как Внедрение системы управления проектами, основанной на использовании веб-конструкций в китайских проектах гонконгкскими девелоперами.

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

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

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

Также в статье упоминается инструмент Intelligent construction project management system. Мы перевели это определение как интеллектуальная система управления проектами. Согласно статье, данный инструмент является полноценной коммуникационной платформой для всех участников процесса строительных компаний в Китае и обеспечивает непрерывный процесс коммуникации на протяжении всего проекта между главным офисом, стройплощадками и консалтинговыми агентствами. Также данная платформа позволяет контролировать этапы выполнения проекта, сроки, бюджет, безопасность и даже влияние на окружающую среду, позволяя оперативно реагировать на отклонения.

Внедрение КСУП в бразильских телекоммуникационных компаниях.

В статье Project management best practices implementation: critical issues in telecommunication companies автор рассматривает практику внедрения системы управления проектами в трех крупнейших бразильских телекоммуникационных компаниях: компании стационарной телефонной связи, компании сотовой связи и вендором технических решений для телеком-отрасли.

Компания А. Оператор проводной связи.

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

Компания В. Оператор беспроводной сотовой связи.

Обоснование внедрения КСУП во второй компании такое же, как и в первом случае: увеличившееся количество проектов побудило руководство к более эффективному управлению проектами. Внедрение КСУП в данной компании началось в 2001 году с отбора 50 сотрудников, которым предстояло получить сертификат по стандарту PMP. К концу 2002 года в компании было 22 сертифицированных проектных менеджера, из которых сформировался проектный офис. Проектный офис, в свою очередь, стал подчиняться коммерческому вице-президенту, что в очередной раз доказывает, что участие высшего руководства компании в управлении проектами является одним из ключевых факторов успеха реализации проектов. В отличие от остальных двух компаний, в данной фирме для проектного менеджера более ценными были технические, нежели управленческие навыки.

Компания С. Вендор технических решений для телеком-отрасли.

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

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

1.2 КСУП в российских компаниях

Внедрение КСУП в нефтедобывающей компании ООО «ЛУКОЙЛ-ПНОС». Внедрение КСУП в данной компании было обусловлено необходимостью реализации нескольких комплексных программ по добыче и переработке нефтепродуктов, защиты окружающей среды и технологического обновления оборудования в 1998 году. Первым шагом к внедрению корпоративной системы управления проектами стало посещение руководством обучения по проектному процессу стандарта PMBoK. После чего в 1999 году был создан координационно-методический совет, цель которого была поддержка нового строя управления процессами, т.е. внедрение КСУП проводилось «сверху». В процессе разработки методологии были созданы «Положение о порядке управления процессом решения проблем ООО «ЛУКОЙЛ-ПНОС» в форме проектов» и «Методическое руководство по осуществлению процесса решения проблем ООО «ЛУКОЙЛ-Пермнефтеоргсинтез»в форме проектов».

В 2004 году в компании внедрили три стандарта проектного управления, которые регламентировали фазы жизненного цикла проектов, а также были введены шаблоны управленческих документов и классификация проектов. Большую роль сыграл раздел «Форма организации проекта», в связи с чем команда проекта могла существовать как временное структурное подразделение в составе предприятия, или, в зависимости от проекта, как отдельная творческая группа с регламентированными задачами и ограничениями.

Внедрение КСУП в дорожной отрасли.

В 2006 г. Государственное учреждение «Дорожное агентство Пермского края» начало внедрение инструментария поддержки проектного процесса с создания проектного офиса и внедрения информационной системы управления проектами ПО Microsoft Project. Отличие данного процесса заключается, прежде всего в том, что компания государственная, и если в случае с «ЛУКОЙЛ» не было выявлено негативного отношения сотрудников к внедрению новых процессов управления, то в данном случае консультантам пришлось учесть некое сопротивление в процессе внедрения: организовать семинары для вовлечения персонала в предстоящие изменения.

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

Внедрение КСУП на производственно-инжиниринговом предприятии.

В компании ЗАО «Пермспецнефтемаш» в качестве инструмента управления проектами был разработан регламент, четко описывающий порядок действий на каждом этапе жизненного цикла проекта, причем каждый сотрудник может выступать в любой роли проектной группы, при наличии достаточного количества знаний и квалификации. Также в компании был создан Проектный комитет - высший коллективный регулирующий орган, ответственный за принятие решений по содержанию портфеля проектов, а также за ход исполнения проектов. Он утверждает основные требования к развитию КСУП, а также приоритезирует проекты и принимает решение о перераспределении имеющихся ресурсов. Председателем Проектного комитета стал генеральный директор ЗАО «Пермспецнефтемаш», а участниками ПК выступило высшее руководство компании. Также в ПК могут входить приглашенные участники, разнящиеся, в зависимости от обсуждаемого проекта, например, представители сторонних компаний. В качестве информационной поддержки было выбрано программное обеспечение Project Server 2007, которое доступно через MS Project, и подходит как для решения разовых работ, так и для управления комплексными программами.

В статье «Особенности управления IT проектами в России» автор конкретизирует те аспекты проектов, на которых чаще всего возникают проблемы (как во время, так и после окончания проекта), а также дает рекомендации, как можно снизить влияние этих проблем.

Высокий уровень рисков IT проектов.

Около 50% проектов в негосударственном секторе и порядка 70% проектов в государственном секторе не соответствуют срокам, бюджету или техническим ожиданиям заказчиков. Причиной этому является высокий уровень неопределенности таких проектов на начальной стадии, так как невозможно предсказать, в каком именно функционале может случиться ошибка. Управлением рисками в IT проектах могут справиться только сотрудники, обладающие опытом запуска проектов в данной сфере, которые смогут учесть хотя бы те риски, которые они уже встречали на своей практике.

Сильное влияние человеческого фактора.

В данном разделе автор иллюстрирует возможность неэффективной работы в рабочей группе, или даже наличие конфликтов. Если на каждого человека в команде из n человек, приходится n(n-1)/2 рабочих связей, то при неграмотной работе HR-специалиста, большой процент этих связей может оказаться неэффективным в плане производительности. Немаловажным фактором влияния автор называет изменение количества специалистов, работающих на проекте, приводя в пример закон Брукса: «Увеличение числа специалистов, работающих над проектом, который уже не укладывается в запланированные сроки, лишь приводит к тому, что этот проект завершается

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

Отсутствие эффективных коммуникаций между бизнесом и IT.

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

Вовлечение исполнителей в реализацию нескольких проектов.

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

Изменение содержания работ в ходе его выполнения.

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

Внедрение ИСУП в компании на примере ПАО «ГМК «НОРИЛЬСКИЙ НИКЕЛЬ».

Так как для отрасли телекоммуникаций характерно инновационное развитие, мы провели обзор данной статьи. По мнению автора, в России реализация инновационных проектов связана с высоким уровнем рисков, прежде всего, из-за отсутствия в России собственного стандарта управления инновационными проектами, несмотря на то, что в компаниях сейчас «модно» внедрять инновационное развитие. Несмотря на поддержку со стороны государства, зачастую в фирмах инновационное развитие не использует весь потенциал данного направления, управление неэффективно, проекты не окупаются. Также звучит утверждение, что внедрение КСУП в компании возможно, только если компания уже проектно-ориентирована, то есть, проектная деятельность уже существовала в том или ином виде. Таким образом, на 2014 год внедрение системы управления проектами был возможно только в 12% российских компаний.

Механизмы, которые, по мнению автора, повышают эффективность таких проектов следующие:

· Непрерывное инновационное развитие

· Внешняя внутренняя интеграция производства

· Консолидация и рост инновационных проектов.

Внедрение КСУП на примере ООО «ГАЗПРОМ ТРАНСГАЗ ТОМСК».

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

Также автор выделяет 10 этапов внедрения управления проектами в ООО «Газпром Трансгаз Томск»:

1) Анализ текущего состояния системы управления проектами

2) Разработка и утверждение будущей модели КСУП

3) Согласование плана процесса внедрения КСУП

4) Подготовка и обучение кадров

5) Изучение опыта внедрения КСУП ПАО «Газпром» и дочерних предприятий

6) Создание внутреннего стандарта СТО ГТТ по управлению проектами

7) Создание проектной инфраструктуры (проектный комитет, проектный офис)

8) Внедрение информационной системы управления проектами MS Project

9) Тестирование внедренной системы на пилотных проектах

10) Доработка и корректировка ведренных инструментов по результатам пилота (по необходимости).

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

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

Таблица 1. Требования к методологиям управления IT-проектами в телекоммуникационной отрасли

Особенности IT-инфраструктуры телекоммуникационной отрасли	Специфика требований к методологиям управления проектами	Ключевые показатели проекта
Высокая цена ошибки сбоя системы	Повышенные требования к качеству продукции	Качество
Интеграция с большим количеством внешних IT-систем, затрагиваются разные бизнес-процессы	Управление активностями, связанными с интеграцией с внешними системами	Качество, сроки
Высокая нагрузка (большой объем трафика, количество абонентов, сложность реализуемого функционала) при ограниченном бюджете	Управление разработкой масштабными сложными системами	Качество, стоимость
Высокая скорость реализации и внедрения новой функциональности и устаревание существующей при ограниченном бюджете	Управление разработкой на основе декомпозиции функциональной архитектуры и на данной основе локализация и ограничение вносимых изменений	Сроки, стоимость
Непрерывный цикл производства, предоставления услуг, ограниченный бюджет для нововведений	Обеспечение планомерного итеративного развития	Сроки, стоимость

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

Факторы успеха внедрения системы управления проектами и причины неэффективного действия КСУП

В ходе анализа литературы мы выделили следующие основные факторы успеха внедрения КСУП в компаниях:

Где по оси абсцисс количество компаний, выбравших фактор ключевым. корпоративный проектный интервью менеджер

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

Таблица 2. Факторы неэффективной работы КСУП

Причина неэффективной работы корпоративной системы управления проектами	% ответивших компаний
Не проводилось полное обучение участников проектной деятельности	44%
Сопротивление изменениям сотрудников, вовлеченных в проектную деятельность	38%
Процессы управления проектами не соответствуют организационной структуре и корпоративной культуре компании	35%
Недостаточная степень детализации процесса управления проектами	32%
Руководство компании не соблюдает внедренную методологию	32%

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

Проанализировав актуальные источники по управлению проектами, мы выделяем основные причины внедрения КСУП и инструментарий КСУП, который используется в проектной деятельности компании (Таблица 3).

Обобщая инструментарий КСУП можно выделить три основных составляющих эффективной системы управления проектами:

· Наличие организационного подразделения, отвечающего непосредственно за КСУП (при условии подготовки прочих сотрудников)

· Информационное обеспечение управления проектами (Проектное ПО)

· Наличие внутренней документации, регламентирующей проектный процесс запуска проектов (в статусе внутреннего нормативного акта).



Таблица 3. Итоги внедрения КСУП в российских и зарубежных компаниях

Название/отрасль деятельности компании	Страна	Причина внедрения КСУП	Внедренный инструментарий КСУП
Китайская строительная компания	Китай	Для оптимизации деятельности с поставщиками и подрядчиками, координация действий одновременно в нескольких местах: головной офис, стройплощадка, внешними консультантами	Единая платформа коммуникаций со всеми участниками проекта; платформа создаются отдельно для каждой строительной компании
Оператор проводной связи	Бразилия	Инвестирование в КСУП как «реклама» эффективности бизнеса в компании; сокращение времени запуска новых продуктов; достижение стратегических целей компании	Создание оценочного комитета, проектного офиса, обучение сотрудников
Оператор сотовой связи	Бразилия	Аналогично предыдущей компании	Сертификация будущих проектных менеджеров, проектный офис
Технический вендор телеком-отрасли	Бразилия	Управление проектами напрямую влияет на выручку, зависящую от заключенных контрактов и их выполнения	Основной упор на управление логистикой
ООО «ЛУКОЙЛ-ПНОС».	Россия	Необходимость одновременной реализации нескольких крупных комплексных программ по добыче и переработке нефти и защите окружающей среды	Создание регламентирующих документов: «Положение о порядке управления процессом решения проблем ООО «ЛУКОЙЛ-ПНОС» в форме проектов»; создание координационно-методологического совета; регламентация жизненного цикла проекта; классификация проектов; введение шаблонов проектной документации
ГУ «Дорожное агентство Пермского края»	Россия	По результатам диагностики внешнего консультанта	Внедрение ИСУП (MS Project), корпоративное обучение «Управление проектами»; внедрение внутреннего стандарта управления проектами
ЗАО «Пермспецнефтемаш»	Россия	Управление разными типами проектов: проектировка и технологический консалтинг	Регламент управления проектами; проектный комитет; ИСУП (Project server 2007)
ООО «ГАЗПРОМ ТРАНСГАЗ ТОМСК»	Россия	Выполнение стратегии компании до 2020 года	Внутренний стандарт СТО ГТТ; проектный офис; проектный комитет; ИСУП (MS Project) обучение сотрудников



Глава 2. Описание проектного процесса в компании сотовой связи до внедрения КСУП

1. Описание организационной структуры компании

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

· Москва

· Центр

· Северо-Запад

· Черноземье

· Волга

· Юг

· Урал

· Сибирь

· Байкал и Дальний Восток.

В свою очередь каждому макрорегиональному представительству подчиняется несколько регионов. В общей сложности компания ведет деятельность в 65 регионах РФ.

В качестве примера приведем схему организационной структуры Центральной Функции компании (Рис. 6)

Основным источником выручки для компании являются продуктовые проекты. Необходимо дать определение понятию «продукт» в рамках компании сотовой связи.

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

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

Внутренние единицы.

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

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

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

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

Внешние единицы.

Вендоры - это поставщики самих технических устройств. В случае нашей компании ими являются Nokia, Ericsson, Huawei.

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

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

Описание структуры продуктовой функции.

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

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

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

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

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

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

2. Классификация проектов в компании.

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

Классификация продуктовых проектов по эффекту.

· Проекты с денежным эффектом. Проекты, которые приносят компании непосредственную выручку компании

· Проекты экономии. Проекты, обеспечивающие снижение OPEX

· Проекты, направленные на сокращение плохой дебиторской задолженности

· Проекты, направленные на увеличение притока абонентской базы

· Проекты лояльности.

Классификация проектов по значимости.

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

· Проекты с денежным эффектом:

o Крупные (более 100 000 000 рублей выручки за 12 месяцев)

o Средние (от 30 000 000 до 100 000 000 рублей выручки за 12 месяцев)

o Небольшие (менее 30 000 000 рублей за 12 месяцев)

· Проекты экономии:

o Крупные (экономия OPEX более 50 000 000 рублей за 12 месяцев)

o Средние (экономия OPEX от 10 000 000 до 50 000 000 рублей за 12 месяцев)

o Небольшие (экономия OPEX менее 10 000 000 рублей за 12 месяцев)

Классификация по партнерам.

· Проекты с основным поставщиком функционала по постоянному контракту

· Проекты с прочими поставщиками функционала по разовому контракту

· Проекты с партнерами-поставщиками контента по разовому контракту

· Проекты с партнерами-поставщиками контента по упрощенному контракту CPA (cost per action)

3. Описание проектного процесса до внедрения КСУП.

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

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

Этап 1. Разработка идеи

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

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

Этап 2. Верхнеуровневая оценка эффекта

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

Недостатки этапа 2: не было единой методологии и формата результатов проводимой оценки, а обращение в смежные функции и новое обсуждение с директором отодвигало начало проекта на неопределенный срок.

Этап 3. Подготовка начала реализации проекта.

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

· Проекты с основным поставщиком функционала по постоянному контракту.

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

· Проекты с прочими поставщиками функционала по разовому контракту и проекты с партнерами-поставщиками контента по разовому контракту.

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

· Проекты с партнерами-поставщиками контента по упрощенному контракту CPA (cost per action). Для реализации небольших контентных проектов применялась схема упрощенного выбора поставщика посредством процедуры request for information (RFI). После выбора поставщика заключался договор CPA по расчетам, и начиналась реализация.

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

Этап 4. Тестирование.

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

Недостатки этапа 4: не учитывалось время продуктовых менеджеров на тестирование, которое, в зависимости от сложности проекта, может продолжаться от 1 дня до 2-3 месяцев. При наличии у инициаторов других проектов, могли сдвинуться сроки не только текущего, но и смежных проектов.

Этап 5. Корректировки (опционально)

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

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

Этап 6. Пилотный запуск или опытно-коммерческая эксплуатация (опционально)

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

Недостатки этапа 6: на данном этапе низкий уровень неопределенности, пилот длится определенный срок и проблем в его ходе не возникает.

Этап 7. Запуск в коммерческую эксплуатацию и rollout (опционально)

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

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

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

4. Выделение проблематики конкретных проектов на основе интервью с инициаторами проектов.

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

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

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

· Неэффективное распределение человеческих ресурсов

· Отсутствие унификации методологии расчета эффекта от проектов

· Слабая коммуникация между разными департаментами организации и внешними партнерами

· Отсутствие четко установленного жизненного цикла проектов

· Слабое планирование на подготовительном этапе

· Задвоение процессов

· Слабое разграничение этапов работ

· Отсутствие контроля тайминга

· Отсутствие хранения проектной документации и данных о выполнении прошлых проектов.



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

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

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

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

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

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

Согласно классификации офисов управления проектами, описанной в PMBoK 5th 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, ее мы более подробно рассмотрим в следующем разделе).

...