В новом релизе мы завершили переход к новой концепции ресурсного планирования. Предстоит реализовать еще ряд функций, но это уже будет углубление возможностей и их оптимизация.
Чего хотели добиться, почему считаем текущий подход правильным и как это всё работает? Постараемся объяснить.
Большинство наших клиентов стремятся сделать свой бизнес гибче. Это не новый тренд, но, с ростом неопределённости, рвение в этом направлении явно выросло.
Существует такой документ — манифест Agile, популярного фреймворка для гибкого управления проектами. В нем оговорены базовые ценности и первым пунктом идет следующее: «Люди и взаимодействие важнее процессов и инструментов».
Что это означает на практике в Timetta? Что нужно меньше формализма и больше прав командам проектов. Однако не стоит забывать, что Timetta, во многом, — учетная система, и подходящая, в том числе, крупным компаниям, а это означает, что совсем без правил и «порядка в делах» не обойтись.
Поэтому исходим из того, что у нашего клиента активно развиты горизонтальные связи и там, где необходимо взаимодействие, мы не пытаемся формализовать процесс.
Отсюда решение отдать предпочтение более гибкой схеме бронирования ресурсов — гибридной.
В централизованной схеме бронирования ресурсов есть центральное звено — ресурсный менеджер. Когда и если менеджеру проекта требуется забронировать ресурс на свой проект или изменить бронируемую емкость — он обращается к ресурсному менеджеру:
PM (Project Manager) — проектный менеджер.
RM (Resource Manager) — ресурсный менеджер.
Плюс такого подхода — порядок. Ресурсный менеджер может контролировать овербукинг, «разруливать» конфликты за ресурсы, влиять на состав команд проектов. Но есть и минус — это долгий процесс. Проекты часто требуют быстрого старта или перепланирования, а ресурсный менеджер становится «бутылочным горлышком».
Децентрализованная схема работы убирает ресурсного менеджера. Менеджеры проектов сами подбирают ресурсы в команду проектов и бронируют необходимую емкость:
Плюсы и минусы зеркальны централизованной схеме — бронирование становиться проще, но порядка меньше. Главный минус — невозможно контролировать овербукинг, он неизбежно случится и команде нужно будет взаимодействовать для решения конфликтов.
(1) Права доступа
Теперь права на бронирование доступны для наборов прав роли «Управление проектами», т.е. менеджерам проектов, менеджерам программ и другим участникам процесса:
Например, менеджерам проектов можно разрешить бронировать ресурсы на свои проекты, при этом видеть полные сведения о бронировании по всем проектам.
(2) Доступ к плану бронирования
Ссылка на план бронирования вынесена в приложение «Проекты». Другими словами, работа с бронированием стала частью функциональных обязанностей менеджера проектов:
(3) Актуализация брони по команде проекта
Быстро открыть план бронирования по проекту теперь можно с помощью команды в карточке проекта:
Менеджер проекта, сформировав команду, должен открыть план и забронировать необходимую емкость по каждому члену команды. Аналогично, если по ходу проекта произойдут изменения, то необходимо перейти в план и актуализировать бронь.
(4) Корреляция ресурсного плана проекта и брони
Одна из проблем планирования — расхождения между бронью и планом проекта. Например, менеджер проекта запланировал работы, но к моменту старта проекта выделить ресурсы в соответствии с планом уже не получается. В таком случае менеджера проекта должен перепланировать работы. В этом ему помогает интерфейс в ресурсном плане проекта, показывающий забронированную емкость и запланированные часы, в идеале эти значения должны совпадать:
Проектный менеджер не всегда может самостоятельно подобрать ресурс в команду своего проекта. В таком случае требуется обращение к ресурсному менеджеру и это уже централизованная схема бронирования.
Часто процесс планирования проекта выглядит следующим образом:
(1) В команде создаем дженерики (универсальные ресурсы)
Команда проекта может включать пользователей или универсальные ресурсы, которые создаются прямо в команде. Универсальному ресурсу всегда назначается одна роль. В данном случае в команде создано два дженерика:
(2) Планируем проект
Ресурсный план проекта позволяет спланировать требуемые трудозатраты в разрезе ресурсов, ролей и временных периодов. В данном случае запланируем работы на «Консультант SAP»:
(3) Создаем запрос ресурса
Запрос ресурса создает из команды проекта. Карточка отрытого запроса выглядит следующим образом:
Запрос описывает потребность в конкретном ресурсе. Из плана проекта передается период запроса и требуемая емкость, ресурсный пул, роль. Менеджер проекта может дополнить запрос своим комментарием.
Изначально запрос создается в состоянии «Черновик». После оформления менеджер проекта «открывает» запрос и в этот момент ресурсный менеджер получает запрос на исполнение. Менеджер проекта может отменить запрос в любой момент.
Менеджеры проектов создают запросы ресурсов, а вот исполняют их, хоть и не всегда, — ресурсные менеджеры.
Подобрать оптимальный ресурс — дело непростое. Требований может быт очень много — период запроса, запрашиваемая емкость, роль с навыками, указание на предпочитаемые ресурсы. При этом надо не забывать о важной задаче ресурсного менеджера — как можно «плотнее» распределить ресурсы на проекты, чтобы удерживать высокую утилизацию.
Для облегчения работы ресурсного менеджера мы добавили ассистента бронирования.
Ассистент доступен по кнопке «Найти ресурсы» в карточке запроса ресурса:
Дальше работаем уже с ассистентом:
В интерфейсе выделяются две секции: верхняя — это уже подобранные ресурсы, и нижняя — это доступные ресурсы.
Ассистент сразу подбирает ресурсы под требования запроса и показывает доступную для бронирования ёмкость. Фильтр можно сузить для более точного поиска, но, если подходящих ресурсов нет, то можно наоборот — расширить. Лучше подобрать не совсем подходящий ресурс, чем вовсе оставить проект без команды.
Для замены универсального ресурса можно выбрать одного или несколько работников. Цель ресурсного менеджера — покрыть ресурсную потребность в указанный период и помогает в этом индикатор «исполнения» запроса — он показывает сколько еще часов необходимо выделить, чтобы исполнитель запрос.
Можно просто добавить ресурс и вручную отредактировать бронируемую емкость. Но быстрее использовать методы автоматического бронирования. Сейчас доступен только один метод— «Фронтальное планирование». Его суть — выбрать всю оставшуюся емкость подобранного ресурса как можно быстрее. Это может привести к тому, что менеджеру проекта придётся перепланировать работы, «уплотнив» их, но это самый эффективный метод для повышения утилизации.
После подбора ресурсов запрос помечается как «Завершенный», и менеджер проекта получает уведомление об исполнении его запроса.
В новой версии реализована гибридная схема бронирования ресурсов. С одной стороны, менеджеры проектов могут самостоятельно подбирать ресурсы в команды и бронировать их емкость. С другой — могут воспользоваться запросами ресурсов и подобрать нужных специалистов при помощи ресурсного менеджера.
В целом мы хотим, чтобы менеджер проекта формулировал потребность проекта так — «Мне нужен Консультант, который знает фин. процессы на уровне 3 и выше, на 120 часов на следующий месяц. Если возможно — пусть это будет Иванов или Петров». А ресурсный менеджер с помощью ассистента планирования быстро и эффективно подобрал нужного человека.
Также же реализуется полноценное прогнозирование потребности в ресурсах. Запросы ресурсов будут выстраиваться в очереди, и мы хотим, чтобы система сообщала менеджменту — «Через 2 месяца вам потребуется еще 3 консультанта, которые должны знать фин. процессы.»
И чуть позже мы реализуем профессиональные модели для поиска исполнителей, работы с внешними ресурсами и планирования потребности. Чтобы система сама подсказывала — «Скоро вам потребуются Архитекторы SAP, но сейчас их нет. Но есть свободные консультанты и если вы их обучите тому-то, то получите как раз Архитекторов SAP».