Управление ресурсами

Обновлено: 05.12.2024

Зачем нужно приложение Управление ресурсами?Зачем нужно приложение Управление ресурсами?

Для организации процесса бронирования ресурсов под проекты.

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

Какие есть подходы к бронированию ресурсов?Какие есть подходы к бронированию ресурсов?

В общем случае есть два подхода: централизованный и децентрализованный.

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

При таком подходе у всех Менеджеров проектов должны быть права на редактирование Календаря бронирования, а решения о перераспределении ресурсов (например, в случае, если два и более менеджера претендуют на бронирование одного сотрудника) должны приниматься коллективно, на регулярных ресурсных встречах.

Централизованный подход более строгий и предполагает взаимодействие между Менеджерами проектов и Ресурсными менеджерами. Менеджеры проектов в таком случае выступают в качестве «потребителей ресурсов», а Ресурсные менеджеры — в качестве «владельцев». Взаимодействие между ними реализуется с помощью Запросов ресурсов.

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

Базовый и Детальный режим бронирования. В чем разница?Базовый и Детальный режим бронирования. В чем разница?

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

В базовом режиме бронирование выполняется с помощью «плашек»:

У плашки есть несколько параметров:

• Период (с по);
• Проект;
• Процент от емкости ресурса, забронированный под указанный проект на указанный период.

Плашка может быть в двух состояниях:

• Hard — подтвержденное бронирование;
• Soft — предварительное бронирование.

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

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

В детальном режиме Календарь бронирования выглядит как таблица:

В детальном режиме нет плашек, а часы бронирования явно указываются на каждый таймслот. Детальный режим гораздо более подробный и позволяет более точно бронировать ресурсы. При этом он сложнее для восприятия и, так как в нём нет плашек, не поддерживает Hard и Soft бронирования.

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

Зачем нужен Календарь бронирования если есть Ресурсный план?Зачем нужен Календарь бронирования если есть Ресурсный план?

Эти компоненты предназначены для разных ролей и разных целей.

Ресурсный план — инструмент для Менеджера проекта. В первую очередь, Ресурсный план нужен для оценки трудозатрат и себестоимости проекта. Ресурсный план может быть очень детальный, с декомпозицией до отдельных задач. Ресурсный план может быть составлен не для конкретных сотрудников, а с использованием Универсальных ресурсов (ролей) — особенно актуален такой подход на этапе первоначальной оценки проекта, когда нет гарантий, что проект в принципе стартует в указанные даты.

Календарь бронирования — это инструмент для коллективной работы (в случае децентрализованного подхода), или инструмент для Ресурсных менеджеров (в случае централизованного подхода). Календарь бронирования нужен для:

• Долгосрочного распределения сотрудников по проектам;
• Контроля ожидаемой утилизации каждого сотрудника;
• Выявления конфликтов за ресурсы, потенциального овербукинга;
• Балансировки загрузки, предотвращения простоев и перегрузов;
• Оптимального распределения ресурсов по проектам, с учетом их навыков и предпочтений.

Какая связь между Ресурсным планом и Календарем бронирования?Какая связь между Ресурсным планом и Календарем бронирования?

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

Другими словами, сотрудник может быть запланирован на проект в Ресурсном плане но не забронирован (Менеджера проекта добавил оценку, но не зарезервировал сотрудника) или сотрудник может быть забронирован под проект, но оценки еще нет (Менеджера проекта зарезервировал ресурс, но еще не успел сделать Ресурсный план).

При децентрализованном подходе к бронированию рекомендуемый процесс такой:

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

При централизованном подходе к бронированию рекомендуемый процесс такой:

1. Менеджера проекта делает оценку в Ресурсном плане, желательно не для конкретных сотрудников, а с использованием Универсальных ресурсов.
2. С помощью Запросов ресурсов Менеджера проекта обращается к Ресурсным менеджерам, чтобы они подобрали подходящих сотрудников взамен Универсальных ресурсов или подтвердили резервирование конкретных сотрудников под проект.

Когда не стоит использовать Календарь бронирования?Когда не стоит использовать Календарь бронирования?

Если компания маленькая или если не предусмотрен процесс взаимодействия между Менеджерами проектов и Ресурсными менеджерами.

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

У нас централизованный подход к бронированию. Как организовать процесс?У нас централизованный подход к бронированию. Как организовать процесс?

Во первых, нужно настроить Timetta:

1. При использовании централизованного подхода рекомендуется использовать детальный режим работы с календарем бронирования.
2. Выделить Ресурсные пулы — команды, за которые отвечают Ресурсные менеджеры. Для Ресурсных пулов поддерживается иерархия — может быть ведущий пул, включающий в себя несколько подчиненных (например, пул Аналитики, включающий в себя несколько под пулов: Аналитики SAP, Аналитики CRM и так далее).
3. Для каждого пула следует назначить Ресурсного менеджера. Это тот человек, который будет обрабатывать запросы от Менеджеров проектов. Дополнительно, для каждого ресурсного пула можно назначить со-менеджеров — помощников основного Ресурсного менеджера.
4. Всех сотрудников следует распределить по пулам. Пул, к которому относится сотрудник, указывается в карточке Пользователя на вкладке Профиль (реквизит Ресурсный пул).

При централизованном подходе рекомендуется использовать Универсальные ресурсы (роли). Универсальные ресурсы позволяют:

1. Делать оценку проекта оперируя в Ресурсном плане не конкретными сотрудниками, а ролями.
2. Делать запросы на подбор сотрудников взамен Универсальных ресурсов.

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

Чтобы можно было пользоваться Запросами на подбор необходимо предварительно:

1. Наполнить справочник Роли. Подробнее — Роли.
2. Назначить Пользователям роли. Подробнее — Управление пользователями.
3. Наполнить справочник Уровни. Подробнее — Уровни.
   Уровень — минимально необходимая характеристика для определения ставки себестоимости Универсального ресурса.
4. Присвоить Пользователям уровни. Подробнее — Управление пользователями.

Для более точного определения ставки себестоимости Универсального ресурса можно настроить справочники Грейды и Локации. Подробнее о порядке определения ставки себестоимости Универсального ресурса — Уровни, грейды и локации ресурсов.

В команде проекта может быть два типа ресурсов:

1. Универсальный ресурс — «заглушка» для оценки. Ресурс без конкретной фамилии, но с определенными характеристиками. Как минимум, для Универсального ресурса должны быть определены Роль и Уровень. Дополнительно можно указать Грейд, Локацию, Ресурсный пул.
2. Именованный ресурс — конкретный сотрудник.

На стадии предварительной оценки проекта рекомендуется пользоваться Универсальными ресурсами по следующим причинам:

1. На данной стадии могут быть не определены точные даты старта проекта.
2. Нет гарантий, что Именованный ресурс в указанные даты будет свободен и сможет принять участие в проекте.
3. Нет гарантий, что Ресурсный менеджер подтвердит выделение Именованного ресурса под данный проект.

В Timetta есть два типа Запросов ресурсов:

1. Запросы на подбор — запрос на подбор подходящего исполнителя взамен Универсального ресурса.
2. Запрос на актуализацию — запрос на изменение бронирования по Именованному ресурсу.

Лучше формировать команду из Универсальных ресурсов, а когда проект будет близок к старту (или когда вероятность старта и точность сроков проекта будет высокой), делать Запросы на подбор. В Запросе на подбор предусмотрена возможность указания предпочитаемых ресурсов. Таким образом, можно добавить в команду проекта Универсальный ресурс, например «Программист», а на этапе формирования Запроса на подбор указать, что предпочитаемым Программистом является конкретный сотрудник (один или несколько). При обработке запроса Ресурсный менеджер увидит ваши предпочтения и, по возможности, зарезервирует взамен Универсального ресурса нужного вам сотрудника.

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

1. Менеджер проекта формирует команду проекта из сотрудников и/или Универсальных ресурсов.
2. Менеджер проекта делает оценку трудозатрат по проекту в Ресурсном плане, тем самым формулируя потребность проекта в ресурсах.
3. На вкладке Потребность в ресурсах в карточке проекта Менеджер проекта создает Запросы ресурсов: Запросы на подбор для Универсальных ресурсов и Запросы на актуализацию брони по сотрудникам.
4. После формирования Запросов на подбор и Запросов на актуализацию Менеджер проекта стартует воркфлоу (бизнес-процесс) по каждому запросу, тем самым направляя свои запросы на рассмотрение Ресурсному менеджеру.
5. Далее запросы поступают на обработку Ресурсному менеджеру. В конечном счете запросы переходят в состояние «Завершен», а результаты обработки запроса отражаются в Календаре бронирования.

Как устроен бизнес-процесс обработки Запросов на ресурсы?Как устроен бизнес-процесс обработки Запросов на ресурсы?

Стандартный воркфлоу обработки Запроса на подбор или Запроса на актуализацию:

1. Менеджер проекта стартует воркфлоу запроса. Подробнее — Воркфлоу.
2. Ресурсный менеджер получает задачу на обработку ресурса (подбор или актуализацию). Есть два варианта:
   а. Отклонить — Ресурсный менеджер возвращает запрос Менеджеру проекта с комментариями или замечаниями.
   b. Завершить — Ресурсный менеджер подбирает ресурсы или актуализирует бронирование и завершает работу над запросом. Изменения бронирования отражаются в Календаре бронирования после завершения работы над запросом.

Дополнительно можно настроить шаг подтверждения результатов исполнения запроса со стороны Менеджера проекта. Например, так:

Можно ли делегировать запросы? Например, если Менеджер проекта ошибся ресурсным пулом?Можно ли делегировать запросы? Например, если Менеджер проекта ошибся ресурсным пулом?

Да, можно. Это актуально для Запросов на подбор.

Например, могут быть следующие кейсы:

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

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