Программное обеспечение управления проектами»

Содержание:

Введение

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

Цель курсовой работы – изучить программное обеспечение управления проектами. Задачи исследования:

- описать понятие и модели программного обеспечения управления проектами;

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

- рассмотреть опыт внедрения программного обеспечения управления проектами в компаниях ПАО «ГМК «Норильский никель» и ООО «Газпром Трансгаз Томск»;

- провести анализ проектного процесса в компании сотовой связи ООО «МТС»;

- оценить эффективность внедрения программ и корпоративной системы управления проектами в компании «МТС».

Объектом данного исследования выступает компания ООО «МТС». Предметом исследования являются элементы программного обеспечения управления проектами.

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

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

1.1. Понятие программного обеспечения управления проектами

В организациях с различным уровнем зрелости, рано или поздно возникает внедрение единых средств и инструментов программного управления проектами. Корпоративная система управления проектами - это комплекс методических, организационных, информационных и технических средств, позволяющих организовать, поддерживать и повышать эффективность процессов планирования проектного управления в компании [6, c.28].

При построении системы управления проектами необходимо четко определить полномочия менеджера проекта, основные принципы формирования команды проекта, которая, в свою очередь, должна быть согласована и утверждена [11, c.67]. Также необходимо разработать и утвердить планы выполнения работ проекта и определить процедуры УП, включая планирование, организацию исполнения, контроля и управления изменениями, сдачи-приемки результатов.

Структура КСУП включает в себя 4 основных компонента [12, c.91]:

• Методологию;
• Офис управления проектами (ОУП);
• Информационную систему управления проектами (ИСУП);
• Персонал.

«Методология управления проектами – набор регламентно-нормативной документации по управлению проектами в компании» [4, c.37]. То есть, это основные правила и стандарты, ориентируясь на которые происходит управление проектами в организации. На сегодняшний день существует несколько методологий УП, которые считаются базовыми и типовыми. Наиболее часто используемые из них:

• PMI PMBOK: Основывается на процессном подходе. Включает в себя 5 ключевых этапов управления проектами: инициация, планирование, исполнение, мониторинг и контроль, завершение, которые разделены еще на 47 процессов [10];
• PRINCE2: Фокусируется на достижении бизнес целей. Является пошаговым алгоритмом управления проектами. Изначально была разработана для ИТ-проектов [6, c.51];
• IPMA: В России получила название «СОВНЕТ». Основана на модели, состоящей из 3 компонентов: индивидуальные компетенции, организация, и проекты;
• P2M: Основывается на системном подходе. Сконцентрированные уроки японских компаний с 1980 года, сформировавшие методологию управления ценностью. Акцент на выработку инновации как подхода к Управлению проектами и стейкхолдерами.

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

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

Основными программными продуктами являются [12]:

• Microsoft Office Project - это комплексное решение по управлению корпоративными проектами, состоящее из семейства программных продуктов.
• Spider Project Professional – пакет УП, созданный с учетом практического опыта, потребностей, особенностей и приоритетов Российского рынка.
• Primavera Project Planner Professional – предназначен для автоматизации процессов УП в соответствии с требованиями PMI (Project Management Institute) и стандартами ISO.

Персонал, который осуществляет управление проектами, играет решающую роль в успехе проекта. Изучение работников в аспекте КСУП происходит по двум направлениям: наличию у них необходимых знаний в сфере УП и системе мотивации. Система мотивации делает возможным сокращение сроков реализации проекта в совокупности с повышением качества и заинтересованности в успехе проекта [2, c.84].

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

Рассмотрим 5 основных моделей оценки зрелости проектного управления, целью которых является измерение достигнутого уровня зрелости и составление рекомендаций на будущее:

1. Project Management Maturity Model Г. Керцнера. Модель состоит из пяти основных уровней зрелости: Общий язык, Общие процессы, Единая методология, Бенчмаркинг, Непрерывное улучшение [14, c.71]. Основное внимание уделяется стратегическому планированию в УП для достижения устойчивых конкурентных преимуществ бизнеса. Содержит тесты для оценки каждого из уровней зрелости.
2. Berkeley PM Maturity Model – модель представляет собой ряд ступеней отражающих эволюцию процессов УП и оценивает восемь областей знаний, акцентируясь на рекомендациях для перехода с одного уровня на другой. Всего предполагается 5 ступеней (уровней): Бессистемный, Плановый, Управление на уровне проекта, Управление на корпоративном уровне, Совершенствование [5, c.19-20]. Модель Фокусируется на управлении проектами в стратегическом аспекте. Для оценки уровня зрелости организации используется опросник, который содержит 162 вопроса.
3. Capability Maturity Model. Разработана Институтом программного инжиниринга (Software Engineering Institute SEI). Прародитель моделей оценки зрелости. Была создана для оценки зрелости процессов разработки и проектирования программных систем. Целью данной модели являлась разработка методики, которая позволила бы крупным правительственным организациям США выбирать наилучших поставщиков Программного Обеспечения. Всего включает 5 уровней: Начальные процессы, Повторяющиеся процессы, Определенные процессы, Управляемые процессы, Процессы оптимизации.
4. Project Management Maturity Model, разработанная PM Solutions. Данная модель позволяет измерить уровень зрелости культуры УП в масштабе целой организации и показывает перспективу для перехода на более высокие уровни. Всего предполагается 8 уровней зрелости: Неосведомленность, Начальные процессы, Базовые процессы, Повторяющиеся процессы, Передовые процессы, Хорошо определённые процессы, Управляемые процессы, Процессы оптимизации. Основана на PMI PMBOK. Разработана как руководство для организаций, которые хотят повысить уровень ПУ.
5. Organizational Project Management Maturity Model (OPM3) – модель, построенная на взаимосвязи стратегии компании и применении практики управления проектами. Рассматривает понятие зрелости в разрезе объектов УП. Модель основана на трех базовых элементах: Знание, Оценка и Улучшение. В модели выделены основные «контрольные точки», используя которые компания может оценить текущее положение в модели зрелости: Не регламентированная стадия, Фундаментальная стадия, Управляемая стадия, Объединенная стадия и Оптимизационная стадия. Определение текущей зрелости и области улучшения происходит с помощью опросника для самостоятельной оценки, который включает 150 вопросов.

1.2. Риски, факторы успеха, стратегии внедрения программного обеспечения управления проектами

Внедрение корпоративной системы управления необходимо для поддержания процессов управления стратегически важными проектами [10, c.34]. Практический опыт показывает, что успешная реализация проектов в запланированные сроки, в рамках установленного бюджета и в соответствии с техническими спецификациями и требованиями к качеству возможна только в рамках формализованной проектной среды, которая поддерживается ясной и четко определенной методикой управления проектами – в качестве такой среды и рассматривается КСУП.

В целом, внедрение КСУП относится к «открытым» проектам (Полковников, 2006) – это такие проекты, которые достаточно сложно спланировать с высокой степенью точности на первоначальной стадии. То есть процессы планирования и реализации проекта выполняются по этапам, учитывая достигаемые в ходе работы результаты.

Согласно мнению ряда авторов, наиболее часто возникающими рисками внедрения КСУП являются:

• Ошибки целеполагания, как следствие - отсутствие сбалансированного подхода к стратегии внедрения;
• Неадекватные ожидания участников проекта;
• Недостаточность поддержки проекта его ключевыми участниками;
• Ошибки при создании команды проекта;
• Недостаточно учтенных данных: параметры компании, доля проектов в бизнесе, характер проектов;
• Недостаточная квалификация и мотивация персонала;
• Неверно или в принципе не определен уровень зрелости существующей системы управления проектами в компании [5, c.87];
• Попытки внедрить КСУП в полном объеме за короткое время;
• Внедрение «чужой» методологии, без учета собственного опыта организации [1, c.55];
• Сопротивление сотрудников, а как следствие – затягивания сроков внедрения или даже отмена внедрения КСУП [7, c.28].

Критические факторы успеха - это критерии, характеристики или условия, которые могут оказать существенное влияние на успешность проекта [7].

Однако, некоторые исследователи различают успех проекта, который измеряется в сравнении с общими задачами проекта, и успех управления проектом, который измеряется в сравнении с традиционными показателями эффективности, такими как качество, стоимость и время [3, c.66].

В качестве основных факторов успеха проекта принято рассматривать как «классические», то есть актуальные для большинства проектов, так и специфические, которые характерны только для проектов по внедрению КСУП [4, c.90].

Так, «классическими» факторами, например, могут являться:

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

В свою очередь, помимо уже названных выше, модель критических факторов успеха проекта, направленного на внедрение КСУП, включает следующие утверждения [11, c.31-32]:

• Создание нормативно-регламентного и методологического обеспечения (стандарта);
• Учет требований пользователей;
• Достаточная квалификация участников и пользователей проекта;
• Система коммуникаций, контроля и управления изменениями;
• Апробация на пилотном проекте;
• Использование соответствующих информационных технологий.

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

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

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

Таблица 1

Стратегии внедрения КСУП [8]

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

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

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

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

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

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

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

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

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

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

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

• бизнес-процессы;

• регламентную базу;

• организационную структуру и роли;

• ИТ-составляющую (программное обеспечение).

Глава 2. Анализ практики внедрения программного обеспечения управления проектами в российских компаниях

2.1. Опыт внедрения программ в компаниях ПАО «ГМК «Норильский никель» и ООО «Газпром Трансгаз Томск»

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

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

• Непрерывное инновационное развитие
• Внешняя внутренняя интеграция производства
• Консолидация и рост инновационных проектов [9].

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

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

1. Анализ текущего состояния системы управления проектами
2. Разработка и утверждение будущей модели КСУП
3. Согласование плана процесса внедрения КСУП
4. Подготовка и обучение кадров
5. Изучение опыта внедрения КСУП ПАО «Газпром» и дочерних предприятий
6. Создание внутреннего стандарта СТО ГТТ по управлению проектами
7. Создание проектной инфраструктуры (проектный комитет, проектный офис)
8. Внедрение информационной системы управления проектами MS Project
9. Тестирование внедренной системы на пилотных проектах
10. Доработка и корректировка ведренных инструментов по результатам пилота (по необходимости).

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

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

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

2.2. Анализ проектного процесса в компании сотовой связи ООО «МТС»

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

• Москва
• Центр
• Северо-Запад
• Черноземье
• Волга
• Юг
• Урал
• Сибирь
• Байкал и Дальний Восток.

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

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

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

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

Управляющие офисы

Внутренние

Внешние

Рис. 1. Внешние и внутренние единицы взаимодействия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Проекты с денежным эффектом:
• Крупные (более 100 000 000 рублей выручки за 12 месяцев)
• Средние (от 30 000 000 до 100 000 000 рублей выручки за 12 месяцев)
• Небольшие (менее 30 000 000 рублей за 12 месяцев)
• Проекты экономии:
• Крупные (экономия OPEX более 50 000 000 рублей за 12 месяцев)
• Средние (экономия OPEX от 10 000 000 до 50 000 000 рублей за 12 месяцев)
• Небольшие (экономия OPEX менее 10 000 000 рублей за 12 месяцев)

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

• Проекты с основным поставщиком функционала по постоянному контракту
• Проекты с прочими поставщиками функционала по разовому контракту
• Проекты с партнерами-поставщиками контента по разовому контракту
• Проекты с партнерами-поставщиками контента по упрощенному контракту CPA (cost per action)

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

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

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

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

2.3. Оценка эффективности внедрения программного обеспечения управления проектами и в компании «МТС»

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

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

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

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

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

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

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

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

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

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

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

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

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

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 месяца после коммерческого запуска проекта.

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

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

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

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

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

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

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

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

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

Таблица 2

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

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

Из проведенного в таблице 2 анализа видно, что внедренный инструментарий решил проблемы, выявленные до внедрения КСУП в ООО «МТС», настолько, насколько это возможно на начальном этапе.

Заключение

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

Корпоративная система управления проектами (сокращенно КСУП англ. CPMS - Corporate Project Management System) - это комплекс методических, административных и информационных средств, позволяющих организовать и поддерживать процессы управления проектами в компании. КСУП является комплексным подходом, который направлен на стандартизацию, автоматизацию и поддержку проектной деятельности компании. Данный подход внедряется с целью повышения качества планирования и, как следствие, более эффективного исполнения проектов и программ при действующих ограничениях по ресурсам, финансам и т.д.

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

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

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

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

Список литературы

1. PMI – Свод знаний по управлению проектами (Пятое издание). – М.: Олимп-Бизнес, 2014. – 614 с.
2. Агафонов А.В. Особенности внедрения корпоративных систем управления проектами // Наука и Бизнес: пути развития. – 2012. – №8(14). – C.79-83.

Балашов А. И. Управление проектами: учебник / А. И. Балашов, Е. М. Рогова, М. В. Тихонова, Е. А. Ткаченко. – М.: Юрайт, 2014. – 383 с.

1. Березина О.С., Чусавитина Г.Н. Анализ стратегий внедрения корпоративных информационных систем управления проектами // Сборник научных трудов III Международной научной конференции. – 2016. – C. 116-120.
2. Богданов, В. В. Управление проектами. Корпоративная система — шаг за шагом. – М.: Манн, Иванов и Фербер, 2012. – 248 c.
3. Зенкина О.В. Основы построения корпоративной системы управления проектами // Статистика и экономика. – 2012. – №6. – C. 44-45.
4. Керцнер Г. Стратегическое планирование для управления проектами с использованием модели зрелости: Пер.с англ. – М.: ДМК Пресс, 2013. – 320 с.
5. Козлов А.С. Портфель программ и проектов как инструмент реализации стратегии // Управление проектами и программами. – 2017. – №1. – C. 16-29.
6. Куликов А.А. Корпоративная система управления проектами // Актуальные проблемы реформирования экономики. Сборник материалов Международной научно-практической конференции. – 2014. – C. 152-154
7. Мазур И.И., Шапиро В.Д., Ольдерогге Н.Г. Управление проектами: Учебное пособие / Под общ. ред. И.И. Мазура, 2-е изд. – М.: Омега-Л, 2014. – 405 c.
8. Полковников А.В., Дубовик М.Ф. Внедрение корпоративной системы управления проектами // Управление проектами и программами. – 2016. – №1. – C. 42-49.
9. Полковников А.В., Дубовик М.Ф. Управление проектами. Полный курс MBA. – М.: Олимп бизнес, 2013. – 552 c.
10. Рассел Д. Управление высокотехнологичными программами и проектами. – М: ДМК, 2014. – 462 с.
11. Ципес Г.Л. Внедрение управления проектами: заблуждения, риски, иллюзии // Управление проектами и программами. – 2015. – №4. – C. 334-335.

Приложения

Приложение 1

Структура продуктовой функции