Распределение заявок между исполнителями: модели, правила и типовые ошибки

Почему назначение — самое дорогое решение дня

В выездном сервисе, доставке и дистрибуции цена ошибки при назначении не видна сразу. Заявка ушла свободному сотруднику — формально всё в порядке. Но «свободный» и «подходящий» — разные вещи: он может оказаться в другом конце города, без нужного инструмента или без допуска на объект. Результат виден только вечером, когда одна бригада закрыла четыре адреса вместо семи, а вторая просидела полдня в дороге.

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

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

Данные, без которых назначать нельзя

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

О работе нужно знать:

• Точный адрес и координаты — «Ленина 5» без корпуса и подъезда превращается в потерянные двадцать минут на месте.
• Тип работ и требуемую квалификацию — монтаж, ремонт, замер и плановое обслуживание требуют разных людей и разного оснащения.
• Временное окно и срок — согласованный с клиентом интервал и крайний срок по договору, это два разных ограничения.
• Плановую длительность — норматив по типу работ, а не среднее «примерно час на всё».
• Потребность в материалах и оборудовании — что должно быть с собой, чтобы закрыть визит с первого раза.
• Приоритет — авария, гарантийный случай, плановая работа.

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

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

Пять моделей распределения и когда какая уместна

На практике встречается несколько устойчивых схем. Они не конкурируют напрямую — у каждой свой диапазон применимости.

• Ручное назначение. Диспетчер сам решает, кому отдать задачу. Максимальная гибкость и учёт неформальных нюансов, полная зависимость от одного человека. Работает, пока в день десятки работ и один дежурный.
• Зонное закрепление. Город делится на районы, за каждым закреплён сотрудник или бригада. Пробег минимален, специалисты знают территорию и объекты. Слабое место — неравномерность: в одном районе завал, в соседнем простой, а перебросить нагрузку без ручного вмешательства нельзя.
• По очереди и по загрузке. Задача уходит тому, у кого меньше занятых минут в смене. Справедливо и прозрачно для команды, но география при этом игнорируется: равная загрузка легко достигается ценой лишних километров.
• По компетенции и приоритету. Сначала отбираются те, кто вообще может выполнить работу (навык, допуск, оснащение), и только среди них выбирается ближайший или наименее загруженный. Обязательная схема там, где есть сложное оборудование и допуски.
• Алгоритмическая оптимизация. Все работы дня раскладываются целиком с учётом географии, временных окон, компетенций и ограничений транспорта, а порядок объезда строится вместе с назначением. Это уже задача маршрутизации, и вручную она не решается: комбинаторика растёт лавинообразно.

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

Как формализовать логику диспетчера в правила

Главный риск ручной диспетчеризации — не в том, что человек ошибается, а в том, что логика нигде не записана. Пока она в голове, её нельзя проверить, передать сменщику и улучшить. Формализация начинается с разделения условий на три уровня.

• Жёсткие ограничения. Нарушать нельзя: квалификация и допуск, временное окно клиента, график и выходные сотрудника, зона доступа, грузоподъёмность и объём.
• Приоритеты. Что важнее при конфликте: аварийная заявка вытесняет плановую, договорной срок важнее удобной географии, повторный визит к тому же клиенту закрепляется за тем же специалистом.
• Критерии оптимизации. Что улучшаем в допустимых вариантах: суммарный пробег, число работ на человека, равномерность минут, доля закрытых в срок.

Полезное упражнение — выписать десять последних спорных назначений и объяснить каждое одним правилом. Обычно выясняется, что реальных правил пять-семь, а остальное — исключения, которые тоже стоит назвать вслух: «этого клиента ведёт только Петров», «на объект с пропуском едет тот, у кого он оформлен».

Такой свод правил ценен сам по себе, даже до автоматизации: он снимает половину вечерних споров и делает работу нового диспетчера предсказуемой с первого дня. А когда правила уже описаны, перенести их в систему — вопрос настройки, а не изобретения процесса заново.

Изменения в течение дня: перепланирование вместо тушения пожаров

Утренний план живёт до первого отклонения. Клиент не открыл дверь, работа оказалась вдвое дольше, приехала аварийная задача, сотрудник заболел или встал в пробке. Вопрос не в том, случится ли это, а в том, сколько времени займёт пересборка остатка дня.

Что помогает пережить такие ситуации без ручного обзвона:

• Резерв в расписании. Загружать смену на сто процентов — гарантированный срыв: любое отклонение сразу выталкивает последние адреса за рабочий день.
• Понятная точка отсечения. Заранее решено, до какого часа срочная работа ставится на сегодня, а после — переносится на завтра с уведомлением клиента.
• Актуальный статус на карте. Диспетчер видит, кто где находится и что уже выполнено, и отдаёт срочную задачу ближайшему подходящему сотруднику, а не первому, кто взял трубку.
• Пересчёт остатка, а не всего плана. Меняется только невыполненная часть; закрытые визиты трогать не нужно.
• Фиксация причин отклонений. Не дозвонились, нет доступа на объект, не хватило материалов, задержка предыдущей работы. Через месяц это готовый список того, что нужно чинить в процессе, а не в людях.

Хорошая проверка зрелости процесса: сколько минут занимает перевод трёх задач с одного сотрудника на другого. Если больше десяти — процесс держится на телефонных звонках, и в пиковые дни он предсказуемо разваливается.

Переход от телефона и таблицы к системе

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

Что меняется в результате. Задачи принимаются и распределяются по сотрудникам в одном окне вместо переписки и звонков; маршруты видны на карте в реальном времени; порядок объезда считает движок оптимизации на базе OR-Tools с учётом окон и ограничений; исполнитель работает в мобильном веб-интерфейсе с фотоотчётами и чек-листами, без обязательной установки приложения; выполнение подтверждается прямо на месте, а заказчик видит статусы в личном кабинете. Подробнее о том, как это устроено для выездных команд — Управление выездным сервисом.

Данные при этом не нужно перебивать руками: itlogist обменивается с 1С, AmoCRM, Bitrix24 и Excel, так что заявки попадают в работу из привычных источников. Запуск занимает 7 дней, без долгосрочных контрактов; решение рассчитано на команды от 5 до 100 исполнителей. То есть проверить новую схему распределения можно на живом потоке работ, а не на бумаге — и сравнить с зафиксированной базой через месяц.