Логика запросов на ресурсы

Обновлено: 03.10.2025

Связь между Ресурсным планом и БронированиемСвязь между Ресурсным планом и Бронированием

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

Другими словами:

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

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

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

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

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

Организация бизнес-процессаОрганизация бизнес-процесса

Настройка системыНастройка системы

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

Использование Универсальных ресурсовИспользование Универсальных ресурсов

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

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

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

Предварительные настройки для работы с Запросами на подборПредварительные настройки для работы с Запросами на подбор

1. Заполните справочник Роли. Подробнее: Роли. Роль — это минимально необходимая характеристика для определения ставки себестоимости Универсального ресурса.
2. Назначьте роли пользователям. Подробнее: Управление пользователями.
3. Создайте Матрицу ставок себестоимости с необходимой структурой и утвердите её. Подробнее: Матрицы ставок.

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

Типы ресурсов в команде проектаТипы ресурсов в команде проекта

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

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

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

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

Типы Запросов ресурсовТипы Запросов ресурсов

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

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

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

Рекомендуемый рабочий процессРекомендуемый рабочий процесс

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

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

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

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

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

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

Делегирование запросовДелегирование запросов

Запросы на подбор можно делегировать в другой ресурсный пул.

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

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

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