Обзор систем управления доставкой: какие бывают и чем отличаются

Что относят к системам управления доставкой

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

• приём и распределение заявок по исполнителям;
• маршруты на карте в реальном времени;
• мобильное приложение исполнителя с фотоотчётами и чек-листами;
• личный кабинет заказчика со статусами;
• оптимизация маршрутов с учётом окон доставки и ограничений;
• подтверждение выполнения работ на месте.

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

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

Пять классов решений и предел каждого

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

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

itlogist относится к последнему классу: это система управления курьерами и выездными сотрудниками для команд от 5 до 100 исполнителей — Возможности itlogist собраны в одном диспетчерском контуре, включая распределение заявок, маршруты на карте, мобильную работу исполнителя и статусы для заказчика.

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

Оси сравнения: по чему смотреть, а не по чему верить

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

• Покрытие цикла. Система ведёт заявку от поступления до подтверждения выполнения — или закрывает только один этап, а остальное собирается из нескольких сервисов.
• Полевая часть и порог входа. Насколько просто исполнителю начать работать. В itlogist это мобильный веб-интерфейс без обязательной установки приложения: курьер открывает ссылку и видит свои заявки и маршрут.
• Маршрутизация. Есть разница между простой сортировкой адресов и настоящей оптимизацией. В itlogist работает движок на базе OR-Tools, который учитывает окна доставки и ограничения.
• Интеграции. Заявки должны попадать в систему из привычного источника: поддерживаются 1С, AmoCRM, Bitrix24 и Excel.
• Прозрачность для заказчика. Личный кабинет со статусами снимает с диспетчера поток звонков «где мой заказ».
• Условия старта. Запуск за 7 дней и без долгосрочных контрактов — это возможность проверить систему на своих заявках, а не многомесячный проект внедрения.

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

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

Чего не видно в сравнительных таблицах

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

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

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

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

Что подходит под ваш сегмент

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

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

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

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

Короткий алгоритм выбора

Соберём обзор в последовательность шагов, с которой удобно идти к решению без лишних кругов сравнения.

• Опишите узкое место. Что именно съедает время сейчас: ручное распределение, обзвон исполнителей, потерянные заявки или спорные результаты визитов.
• Отсеките неподходящий класс. Если нужны факт выполнения и мобильная работа в поле, таблицы и навигаторы отпадают сразу — они этот слой не закрывают.
• Проверьте интеграцию с источником заявок. 1С, CRM или Excel — заказы должны попадать в систему без ручного переноса.
• Проведите пилот на своих данных. Одна-две реальные смены целиком показывают больше, чем любая презентация.
• Оцените условия входа. Короткий запуск и отсутствие долгих контрактов означают, что цена ошибки невелика.

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

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