Меню

Кейс: Ресурсное планирование на Project Server

RMИстория об успешном внедрении ресурсного планирования на платформе MS Project Server. В статье рассмотрены цели и задачи внедрения, возникшие трудности и пути их разрешения, а также полученное решение.

Задачи ресурсного планирования

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

Ситуация до внедрения

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

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

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

Процесс до внедрения

Рассмотрим подробнее процесс обеспечения проекта ресурсами, как он выполнялся до внедрения системы. Процесс начинается с того, что руководитель проекта планирует работы по проекту. Для планирования он применяет продукт MS Project Professional. На основе плана руководитель проекта выявляет потребность в ресурсах. Эта потребность может выражаться в виде требуемых для проекта специальностях (например, 3 бизнес аналитика или 5 инженеров 2-ой категории). Руководитель проекта может запросить и конкретного сотрудника. Указать, что для проекта требуется именно Петр Иванов.

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

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

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

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

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

Стандартный сценарий Project

В базовом функционале Project Server сценарий выделения ресурсов на проект выглядит следующим образом. Существует корпоративный пул ресурсов, куда включены все сотрудники компании. Планируя проект, руководитель проекта выбирает из этого пула необходимые для проекта ресурсы. Вновь добавленные ресурсы получают статус резервирования «Proposed» («Предложенный»). Пока установлен такой статус, выделение ресурса в проект считается не одобреным. Если назначить такой ресурс на задачу и опубликовать проект, то исполнители не получат задач к исполнению. Назначения такого ресурса в проекте не отразятся на его загрузке и доступности в пуле ресурсов. Логика Project предполагает, что вне системы происходит процесс согласования выделения ресурсов в проект. По его итогу руководитель проекта сам заходит в проект и меняет статус резервирования ресурса с «Proposed» на «Commited («Выделенный»). Ресурсам, получившим статус «Выделенный» приходят задачи к исполнению, а их загрузка учитывается в корпоративном пуле ресурсов. Изменение статуса резервирования ресурсов с «предложенного» на «выделенный» и наоборот можно произвести только из самого проекта. И не иначе.

На рисунке показана стандартная форма комплектования проектной команды (в англ. версии Build Team). В правой части формы находится перечень ресурсов, которые добавлены в команду проекта. У этих ресурсов есть поле, в которое руководитель проекта проставляет статус выделения ресурса — «выделенный» или «предложенный».

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

Поставленные задачи

Ниже перечислены задачи, которые поставил перед нами заказчик:

  • Задача №1. Процесс запроса подбора и выделения ресурсов должен был согласованно выполняться в рамках ИСУП Project Server. Мы разработали специальное расширение, которое позволило выполнять этот процесс непосредственно в системе Project Server.
  • Задача №2. Обеспечить такую функциональность, при которой только линейные руководители обладали бы функцией выделения ресурсов на проекты. При этом руководители проектов не возможности вручную менять статус выделения ресурсов. Мы разработали расширение, которое исключало возможность ручной установки статуса выделения ресурсов в обход формализованного процесса.
  • Задача №3. В ИСУП не было актуальных данных сотрудниках. Данная информация велась в кадровой учетной системе организации. Мы разработали модуль интеграции Project Server с кадровой системой.

Решение

В основе разработанного нами решения лежит расширенный процесс ресурсного планирования проектов (Project Stuffing). Рассмотрим, как он был реализован.

Расширенный процесс ресурсного планирования мы интегрировали непосредственно в функционал Project Server. При этом штатный сценарий одобрения ресурсов Project был заменен. Руководитель проекта теперь не может самостоятельно изменять статус резервирования ресурса. За это отвечает специальное программное расширение для Project. В систему были добавлены две роли – «Менеджер назначений ресурсов» и «Руководитель ресурсов». Обе эти роли участвуют в процессе подбора и согласования ресурсов для проекта.

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

Автоматизированный процесс запроса ресурсов был реализован на базе технологии Windows Workflow Foundation, в виде расширения, интегрированного в функционал Project Server и веб-клиент PWA. Пользовательский интерфейс расширения мы сделали внешне максимально приближенным к базовому функционалу Project, сохранив пользовательский опыт.

Расширенный процесс ресурсного планирования

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

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

Чтобы одобрить использование ресурсов руководитель проекта должен инициировать процесс запроса. Для этого он нажимает на панели расширения «Ресурсное планирование» кнопку «Запросить ресурсы».

 

В открывшемся окне система отображает список всех неутвержденных ресурсов, которые имеются в проекте. Можно просмотреть требуемые сроки использования этих ресурсов.

Ресурсы могут быть как ролевыми (например, Бизнес-аналитик). Так и именными (например, Иван Петров). Руководитель проекта выбирает, какие ресурсы он хочет включить в запрос, при необходимости оставляет комментарий и отправляет запрос.

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

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

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

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

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

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

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

Ход подбора ресурсов руководитель проекта может видеть в форме непосредственно из Project Professional. Зеленым цветом отмечены ресурсы, которые одобрены для включения в проект. Красным цветом отмечены три ресурсы, которые были отклонены. Серым — те ресурсы, по которым ответ еще не получен.

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

Утвержденные ресурсы автоматически меняют статус в проекте. Значение поля ресурса «Тип резервирования» изменяется на «Выделенный». Причем, поменять это поле в ручную теперь невозможно — система это контролирует.

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

Интеграция с данными HR

Чтобы в системе была актуальная информация по ресурсам мы разработали специальный модуль интеграции Microsoft Project Server с кадровой системой.

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

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

На рисунке ниже показана схема синхронизации оргструктуры и данных о сотрудниках. Мы разработали специальный модуль интеграции, объединяющий данные о сотрудниках из Active Directory (AD) и кадровой HR-системы. Для ускорения процесса синхронизации была использована промежуточная база данных, хранящая изменения.

 

На схеме ниже показана общая архитектура полученного решения. Желтые блоки означают разработанные нами модули.

Выводы

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

  1. планомерно обеспечивать проекты требуемыми ресурсами в нужные сроки,
  2. при этом контролировать и оптимизировать загрузку своих ресурсов.

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

Актуальность решения

В части ресурсного планирования функционал Project / Project Server 2013 не претерпел кардинальных изменений относительно версий 2007 и 2010. Поэтому реализованное нами решение принципиально остается актуальным и для версии Project 2013.

Смотрите подробное видео про это внедрение на нашем youtube-канале: