Диспетчер открывает помощник по планированию, чтобы найти исполнителя для срочного ремонта, и видит единственный вариант: сертифицированного техника в двух часах езды. Его коллега, который находится в десяти минутах от объекта, имеет ту же сертификацию, но её никто не привязал к его записи ресурса — поэтому помощник его так и не предложил. Планирование в Dynamics 365 Field Service работает ровно настолько хорошо, насколько качественны данные о ресурсах, требованиях и бронированиях, на которые оно опирается. В этом руководстве — что именно смоделировать ещё на этапе внедрения, до запуска любого инструмента планирования.

В Microsoft Dynamics 365 Field Service планирование разделено на два уровня. Field Service определяет, что нужно сделать и где; Universal Resource Scheduling — кто может выполнить работу и когда. Каждый наряд на работу (work order) автоматически создаёт требование к ресурсу (resource requirement), и именно это требование бронируется на конкретного техника.

У диспетчеров есть три способа сопоставить требования с людьми. Доска планирования (Schedule Board) предназначена для ручного бронирования и подходит для аварийных работ или несложных задач. Помощник по планированию (Schedule Assistant) предлагает время и ресурсы для отдельной задачи, а диспетчер выбирает один из вариантов. Для больших объёмов есть надстройка Resource Scheduling Optimization: она планирует сразу много задач в соответствии с ранжированными целями. Scheduling Operations Agent, который пока доступен в preview, оптимизирует расписание одного или нескольких техников прямо с доски планирования или из боковой панели Copilot.

Все три способа работают с одними и теми же записями. Качество планирования в Field Service определяется тем, как смоделированы ресурсы, требования и правила бронирования, — и происходит это задолго до того, как кто-то выбирает между ручным и автоматизированным бронированием.

Требование наследует от наряда название, местоположение, длительность и другие атрибуты, а последующие изменения в наряде автоматически переходят и в него. Отдельного внимания заслуживает длительность. Если в наряде нет сервисной задачи (service task) или типа инцидента (incident type), он получает длительность бронирования по умолчанию, однако требование не переносит это значение в собственное поле Duration. Типы инцидентов работают как шаблоны нарядов, поэтому реалистичная длительность в их настройках — это часть работы по планированию, а не наведение порядка в справочнике.

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

Бронируемые ресурсы (bookable resources) содержат поля, на основе которых инструменты планирования выполняют расчёты. У каждого ресурса свой часовой пояс (Time Zone), а поля Start Location и End Location сообщают системе, где начинается и где заканчивается его рабочий день. Если выбрать значение Location agnostic, время в пути до первого бронирования и от последнего не рассчитывается вовсе. Маршрутизация, оценка времени в пути и отображение на карте тоже зависят от корректных геокодированных адресов.

Доступность определяют рабочие часы. Помощник по планированию показывает только ресурсы со свободной мощностью в пределах рабочих часов и пропускает любой ресурс, у которого параметр Enable for Availability Search имеет значение No. Мощность (Capacity) по умолчанию равна 1; значение 0 исключает ресурс из поиска доступности.

Навыки хранятся в той же записи. Характеристики бывают двух типов: Skill — навык, который оценивается по модели рейтинга, и Certification — подтверждённая квалификация, которую ресурс получил. В нарядах указаны характеристики, необходимые для работы, и диспетчеры сопоставляют их с тем, чем располагает каждый техник. Расширенные характеристики (enhanced characteristics), которые пока в preview, добавляют к сертификации дату выдачи и дату окончания действия. Профиль ресурса дополняют назначенные территории.

Автоматизированное планирование добавляет правила, без которых ручное бронирование вполне обходилось. Для Scheduling Operations Agent у каждого статуса бронирования есть параметр Optimization Method — он описан в документации по настройке Scheduling Operations Agent. Значение Optimize позволяет агенту переносить или удалять бронирования с этим статусом, Do Not Move сохраняет время прибытия, а Ignore позволяет агенту бронировать поверх него — именно его Microsoft рекомендует для отменённых бронирований. Если оставить поле пустым, агент будет считать каждое бронирование с таким статусом как Do Not Move, поэтому при ненастроенных статусах ему почти нечего менять.

Приоритеты требуют такого же внимания. Агент считывает Priority Value в диапазоне от 1 до 100 и не учитывает поле Level of Importance. Microsoft советует задавать значения, которые чётко различаются, но лежат в узком диапазоне: если Low равен 1, Medium — 10, а Emergency — 100, аварийные работы попадут в результат почти независимо от того, насколько неэффективным окажется такое размещение.

Кроме того, агенту нужны включённые настройки местоположения и карт, значение Yes в поле Display on schedule board для каждого ресурса, который он должен учитывать, и две назначенные роли безопасности.

Microsoft рекомендует внедрять планирование в Dynamics 365 Field Service поэтапно: сначала ручное планирование на доске, чтобы выстроить бизнес-процессы; затем помощник по планированию; потом — Resource Scheduling Optimization, начиная с оптимизации для одного ресурса. На каждом этапе данные сначала проходят через диспетчера и только потом от них начинает зависеть автоматический запуск.

Агент меняется быстро. Публичная preview-версия расширила его возможности до 5 ресурсов с доски планирования и до 30 — через план оптимизации (Microsoft 365 Message Center, MC1392246, июнь 2026 г.); 30 сентября 2026 года появились регулярные запуски, которые применяют расписание автоматически (MC1476008). Microsoft указывает, что функции в preview не предназначены для рабочей среды, поэтому пилоты стоит планировать с учётом этого.

Отличается и модель оплаты. Стоимость Resource Scheduling Optimization зависит от количества оптимизируемых ресурсов, тогда как Scheduling Operations Agent расходует кредиты Copilot Studio, и их количество растёт вместе с числом ресурсов в каждом запросе.

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

OntargIT внедрила Dynamics 365 Field Service и Dynamics 365 Customer Service для KTS Engineering — инжиниринговой компании, работающей с распределённой генерацией, и автоматизировала планирование выездов и обработку сервисных обращений. Как Microsoft Solutions Partner — AI Business Solutions, OntargIT реализовала 150+ проектов для 140+ клиентов в 24 странах.

Выбранный инструмент планирования значит меньше, чем записи, с которыми он работает. Прежде чем покупать лицензии Resource Scheduling Optimization или запускать пилот Scheduling Operations Agent, убедитесь, что у каждого ресурса есть часовой пояс, геокодированная начальная локация и его реальные характеристики, а у каждого статуса бронирования и приоритета — явно заданное значение. Заложите эти проверки в этап настройки при внедрении CRM.