Разберём вашу схему перевозок и скажем, что автоматизируется в первую очередь
Откуда приходят заявки, как сейчас планируются маршруты, кто ведёт статусы и в каких программах уже лежат ваши данные.
Программное обеспечение для логистики
Заявки, маршруты, грузы и доставка в одной системе
Пока перевозок мало, их держат в голове, в таблице и в переписке. С ростом объёма это перестаёт работать: где груз, знает только водитель, кто и что кому обещал — только тот, кто принял заявку. Программа для логистики убирает этот способ работы: заявка, маршрут, груз и статус доставки становятся записями в одной системе, а диспетчер видит их на одном экране. Ниже разобрано, как это устроено — от поступления заявки до подтверждения получения.
Что такое система
управления логистикой
Система управления логистикой — программа, которая ведёт учёт перевозок: принимает заявки, собирает из них маршруты, назначает исполнителей, следит за движением груза и хранит историю того, что произошло с каждой доставкой.
Разницу видно на одном примере. Без системы заявка живёт в мессенджере, маршрут — на листе у диспетчера, а состояние груза — в голове водителя. Чтобы ответить клиенту «где мой груз», нужно позвонить трём людям. Никто не знает, сколько машин загружено на завтра, потому что эта цифра нигде не посчитана.
В системе то же самое — записи. У заявки есть номер, отправитель, получатель, срок и текущее состояние. У маршрута — список точек, порядок объезда и исполнитель. У груза — статус, который меняется не на словах, а действием в программе. Ответ на вопрос «где груз» занимает секунды и не зависит от того, кто сегодня в смене.
Пример. Клиент оставил заявку на перевозку в четверг. Оператор проверил адрес и габариты, поставил заявку в маршрут на пятницу, система назначила её водителю вместе с шестью другими точками. Утром водитель открыл список заданий, отметил забор груза, вечером — доставку. У клиента в это время менялся статус, а у компании к вечеру пятницы была готова сводка: сколько точек проехали, сколько успели в срок и по какой доставке был сбой.
Автоматизация логистики начинается там, где ответы на три вопроса перестают помещаться в голову диспетчера: сколько заявок сейчас в работе, где находится конкретный груз и почему вчера две доставки уехали на следующий день.
- 1Заявка
- 2Проверка
- 3Маршрут
- 4Исполнитель
- 5Отгрузка
- 6Движение
- 7Доставка
- 8Диспетчер
Связь двусторонняя: задание идёт слева направо, отметки исполнителя и события — обратно. Доставка считается состоявшейся не после того, как водитель уехал с адреса, а после подтверждения получения. Без этого шага система рассказывала бы о грузах то, во что верит, а не то, что произошло.
Что система знает о каждой перевозке
- Что везём — наименование груза, количество мест, вес, объём, особые условия перевозки
- Откуда и куда — адрес забора, адрес доставки, контактные лица на обеих сторонах
- Когда — срок доставки, интервал у получателя, фактическое время отправления и получения
- Кто отвечает — водитель или курьер, машина, маршрут, ответственный сотрудник в офисе
- В каком состоянии — текущий статус и вся цепочка его изменений с автором и временем
- Чем подтверждено — документы, фотографии, подпись получателя, комментарии исполнителя
Чего система не делает сама
Программа не водит машину и не заменяет диспетчера. Она убирает ручную работу вокруг решения: собирает заявки в одном месте, показывает загрузку, не даёт потерять точку и фиксирует каждое изменение. Решение о том, кому отдать срочный заказ и стоит ли ждать опаздывающего клиента, остаётся за человеком — но принимается по полной картине, а не по памяти.
Точно так же система не «знает» пробки и погоду сама по себе: любые внешние данные приходят в неё через интеграцию, и их состав определяется проектом.
С чего обычно начинают
Первым в систему переводят учёт заявок, а не маршруты и не карты. Причина простая: пока заявки живут в переписке, любой маршрут построен по неполному списку, а любой отчёт посчитан по тому, что кто-то не забыл записать.
Какие задачи решает система
Ниже — не список функций, а шесть проблем, из-за которых логистику вообще автоматизируют. Каждая формулируется одинаково: что происходит без программы и что меняется с ней.
Заявки не теряются
Без системы заявка приходит в мессенджер, на почту и по телефону, а её судьба зависит от того, записал ли её кто-то. В системе любая заявка — запись с номером, автором и сроком: она либо в работе, либо закрыта, третьего состояния нет. Потерянная заявка становится видимой сразу, а не когда позвонит клиент.
Маршрут строится из заявок, а не из памяти
Диспетчер видит все точки на завтра списком: адреса, интервалы, габариты. Точки собираются в маршруты, у маршрута появляется исполнитель и порядок объезда. Забытая точка не уезжает в следующий день незаметно — она остаётся нераспределённой и видна в отдельном списке.
Видно загрузку людей и транспорта
Сколько точек уже назначено на машину, сколько осталось свободного места по весу и объёму, кто из водителей заканчивает смену через час. Без этих цифр загрузка распределяется на глаз, и одна машина уезжает полупустой, пока вторая не успевает к вечеру.
Статус груза не нужно выяснять звонком
Состояние доставки меняет тот, кто её выполняет, в момент действия. Диспетчер, менеджер и клиент смотрят на одну и ту же запись. Вопрос «где мой груз» перестаёт быть работой для трёх человек.
Подтверждение получения фиксируется
Кто принял груз, когда и на каком основании — запись в системе, а не воспоминание. Подпись, фотография или код подтверждения привязаны к конкретной доставке. Спор «привезли — не привезли» решается открытием карточки, а не разбирательством.
Сбои разбираются по фактам
Опоздания, отмены, возвраты и неуспешные доставки становятся отдельными событиями с причиной. К концу месяца видно не «бывает всякое», а конкретный перечень: сколько сбоев, по каким направлениям и из-за чего они происходят.
Из чего состоит система
Система собирается из модулей. Не все они нужны каждой компании: службе доставки внутри города не нужен учёт межгородских рейсов, а производству с собственным транспортом — биржа заказов. Состав определяется задачей, но модули стыкуются между собой заранее, а не дописываются потом сбоку.
Приём и обработка заявок
Точка входа системы: заявка на перевозку с отправителем, получателем, составом груза, сроком и условиями. Заявки приходят от менеджера, из личного кабинета клиента или из внешней системы через API — дальше все они живут по одним правилам.
Маршруты и точки доставки
Сборка точек в маршрут, порядок объезда, назначение транспорта и исполнителя, изменение маршрута в течение дня. Маршрут — такой же учётный объект, как заявка: у него есть дата, состояние и история изменений.
Реестр грузов
Что именно перевозится: места, вес, объём, упаковка, особые условия. Груз связан с заявкой, маршрутом, документами и текущим статусом, поэтому по любой из сторон восстанавливаются остальные.
Транспорт и исполнители
Справочник машин и людей: грузоподъёмность, объём кузова, тип транспорта, график работы, зона обслуживания. Отсюда берётся загрузка — сколько ещё точек можно поставить на эту машину сегодня.
Диспетчерская панель
Рабочее место сотрудника: активные доставки, маршруты, исполнители, статусы, задержки и проблемные заказы на одном экране. Открывается в браузере, устанавливать ничего не нужно.
Статусы и события
Конечный набор состояний доставки и правила перехода между ними. Каждое изменение — событие с автором, временем и основанием; события складываются в историю, по которой потом разбирают сбой.
Связь со складом
Стык с комплектацией и отгрузкой: что собрано, что подготовлено к передаче, что фактически передано водителю. Без него склад и доставка живут в двух разных учётах и расходятся уже к обеду.
Рабочее место исполнителя
Приложение или мобильный интерфейс водителя и курьера: список заданий, адреса, порядок объезда, данные о грузе, смена статуса, подтверждение получения и доставки, связь с диспетчером.
Уведомления
Сообщения клиенту и сотруднику: заявка принята, груз забран, курьер выехал, доставка перенесена, доставка не состоялась. Каналы доставки сообщений выбираются при внедрении и подключаются интеграцией.
Роли и права
Оператор заявок, диспетчер, кладовщик, водитель, руководитель. Изменение маршрута, отмена доставки, правка адреса и доступ к персональным данным получателей — отдельные права, а не общий пакет «сотрудник».
Аналитика и отчётность
Количество доставок, доля выполненных в срок, загрузка транспорта и людей, эффективность маршрутов, перечень проблемных заказов. Отчёты выгружаются файлом и строятся по расписанию.
API и интеграции
Внешний интерфейс системы: создать заявку, узнать статус, получить маршрут, передать подтверждение доставки, забрать журнал. Через него подключаются интернет-магазин, CRM, ERP и складская система.
Управление заказами
от заявки до доставки
Заявка на перевозку — документ, который фиксирует, что и куда нужно доставить, к какому сроку, за чей счёт и на каких условиях. Всё дальнейшее — маршрут, исполнитель, статусы, документы — привязано к её номеру.
Заявка попадает в систему одним из трёх способов: её создаёт менеджер, её оформляет сам клиент в личном кабинете или её передаёт другая программа компании через API. Источник разный, дальнейший путь один — иначе у части заказов появился бы свой негласный порядок обработки.
Проверка — отдельный шаг, а не формальность. Система смотрит, заполнены ли обязательные поля, есть ли получатель в справочнике, укладывается ли груз в допустимые габариты, не выходит ли срок за пределы возможного. Спорная заявка не уходит в маршрут молча: она остаётся в списке на уточнение с понятной причиной.
Что содержит заявка:
- Номер, дата создания, автор и источник — кто и откуда её завёл
- Клиент и плательщик, если это разные лица
- Адрес забора и адрес доставки с контактными лицами
- Состав груза: наименование, количество мест, вес, объём, упаковка
- Срок доставки и интервал, удобный получателю
- Условия: оплата при получении, хрупкий груз, требуется подъём на этаж, нужен второй человек
- Связанные документы: накладная, счёт, заказ из другой системы
Назначение на доставку — момент, когда заявка перестаёт быть намерением и становится работой. Она попадает в маршрут конкретного дня, у неё появляется исполнитель, а у исполнителя — задание в его списке. С этого момента заявка видна и в диспетчерской панели, и в приложении водителя, и в истории клиента.
Часть правок меняет план дня: новый адрес может выпасть из маршрута, увеличенный вес — не поместиться в назначенную машину. Такая заявка не правится молча — она возвращается диспетчеру на перепланирование вместе с причиной.
Путь одной заявки
- СозданаМенеджер завёл заявку: два места, 46 кг, забор со склада, доставка на адрес получателя до 18:00 в пятницу
- ПроверенаАдрес найден в справочнике, габариты укладываются в тип транспорта, срок реален — заявка допущена к планированию
- Поставлена в маршрутТочка добавлена в маршрут пятницы, четвёртой по порядку объезда
- Назначен исполнительМаршрут закреплён за водителем и машиной; задание появилось в его списке на завтра
- Груз забранВодитель отметил забор на складе, система записала время отправления и перевела заявку в движение
- ДоставленаПолучатель принял груз, подтверждение приложено к заявке, время получения зафиксировано
- ЗакрытаДокументы сданы, расхождений нет; заявка уходит в историю и попадает в отчёт за период
Кадр экрана системы, данные демонстрационные. Важен пятый шаг: отметку о заборе делает тот, кто физически берёт груз. Если её ставит диспетчер «по звонку», система начинает описывать не перевозку, а рассказ о ней.
Правка назначенной заявки
Правка — управляемая операция, а не свободное редактирование. Смена адреса, срока или состава груза сохраняет предыдущую версию и оставляет след: кто изменил, когда и что именно. Иначе разбор спорной доставки упирается в вопрос «а какой адрес был изначально».
Управление маршрутами
точки, очерёдность и исполнители
Маршрут — список точек, которые один исполнитель объезжает за смену, вместе с порядком объезда. Точка — это конкретное действие по адресу: забрать груз, доставить груз, забрать возврат.
Создание маршрута начинается с нераспределённых заявок на выбранную дату. Диспетчер видит их списком: адрес, район, интервал у получателя, вес и объём. Точки собираются в маршрут вручную или по правилу — например, «все доставки этого района на завтра», — и маршрут сразу показывает суммарный вес, объём и число остановок.
Очерёдность остановок задаётся явно и остаётся видимой всем: диспетчеру в панели, водителю в приложении. Порядок меняется перетаскиванием точки, при этом система пересчитывает нагрузку маршрута и предупреждает о конфликте — например, когда точка с интервалом «до 12:00» оказалась восьмой по счёту.
Назначение исполнителя — привязка маршрута к водителю или курьеру и к транспортному средству. Система учитывает грузоподъёмность и объём кузова: маршрут, который не помещается в назначенную машину, помечается до выезда, а не обнаруживается на погрузке.
Изменение маршрута происходит в течение дня и это нормальный сценарий, а не авария. Точку можно добавить, снять, перенести на другой маршрут или на другой день. Исполнитель видит изменение в своём списке, а в истории маршрута остаётся запись: что изменилось, кто изменил и во сколько.
Контроль выполнения — сопоставление плана и факта: сколько точек из маршрута закрыто, сколько осталось, где исполнитель отклонился от порядка объезда, какие точки просрочены по интервалу. Маршрут закрывается, когда закрыты все его точки — включая те, что закончились неуспешной доставкой.
Автоматический подбор порядка объезда
Автоматическое построение оптимального маршрута — отдельный модуль, а не встроенная функция системы учёта. Его имеет смысл рассматривать как вариант реализации: он требует источника дорожных данных, правил расчёта и проверки на реальных рейсах компании.
Возможные варианты — от простого упорядочивания точек по зонам и временным интервалам до расчёта по внешнему картографическому сервису. Что именно подключается и на каких данных считается, определяется на обследовании: заранее заявлять готовую оптимизацию было бы обещанием, а не описанием.
Базовый контур работает и без него: точки, порядок, исполнитель и контроль выполнения не зависят от того, кто расставил остановки — человек или алгоритм.
Маршрут как учётный объект
У маршрута есть дата, исполнитель, транспорт, состояние и история изменений — как у заявки. Поэтому вопрос «почему вчера этот адрес уехал на сегодня» разбирается по записи маршрута, а не по памяти смены.
| № | Точка | Действие | Интервал | Мест | Вес | Состояние |
|---|---|---|---|---|---|---|
| 1 | Склад, ул. Промышленная | Забор груза | 08:00–09:00 | 14 | 310 кг | выполнено |
| 2 | Магазин «Центральный» | Доставка | 09:00–12:00 | 4 | 86 кг | выполнено |
| 3 | Офис заказчика, 4 этаж | Доставка | 10:00–13:00 | 2 | 18 кг | в пути |
| 4 | Пункт выдачи, мкр. Асанбай | Доставка | до 18:00 | 6 | 142 кг | ожидает |
| 5 | Магазин «Восточный» | Доставка + возврат | 14:00–17:00 | 2 | 64 кг | ожидает |
Порядок объезда виден и диспетчеру, и водителю, поэтому «поменялись местами» не превращается в спор. Строка 3 закрыта не будет, пока исполнитель не отметит результат: подъём на этаж — типичное место, где доставка задерживается, и система должна об этом узнать от того, кто стоит у двери.
Управление грузами
что везём, откуда, куда и кто отвечает
Груз — то, что физически перемещается. В системе это отдельная запись, связанная с заявкой: одна заявка может везти несколько грузовых мест, а один рейс — грузы нескольких заявок.
Разделение нужно не ради строгости учёта. Именно на уровне груза отвечают на вопросы, которые задают чаще всего: сколько мест уехало, все ли они доехали, какое из них повреждено, что вернулось обратно.
Каждое изменение состояния груза — событие с временем и автором. Поэтому история перевозки восстанавливается целиком: во сколько груз забрали, где он был передан между исполнителями, когда его вручили получателю и кто это подтвердил.
Передача между исполнителями — отдельная операция, а не побочный эффект. Груз, который едет со склада на сортировку, а оттуда на адрес, меняет ответственного минимум дважды. Каждая передача фиксируется явно, иначе при пропаже невозможно назвать участок, на котором груз потерялся.
Отсюда же берётся ответ на вопрос «кто виноват» — не в смысле поиска виноватого, а в смысле участка. Повреждение, обнаруженное получателем, привязывается к тому отрезку пути, на котором груз числился за конкретным исполнителем.
Связанные документы
Накладная, акт приёма-передачи, фотография упаковки, подпись получателя живут рядом с грузом. Документ привязан к грузу и к заявке одновременно, поэтому находится и от клиента, и от рейса — искать его в переписке не нужно.
Фотография при приёме и при выдаче — самый дешёвый способ закрыть спор о повреждении: она сделана в известный момент известным человеком и лежит в той же карточке, что и подпись получателя.
Груз и заявка — разные записи
Одна заявка может везти несколько мест, а один рейс — грузы нескольких заявок. Пока это одна запись, любой частичный случай — приняли три места из пяти, одно вернули — приходится описывать словами в комментарии.
- Что перевозитсяобязательноНаименование, количество мест, вес, объём, тип упаковки, особые условия — хрупкое, температурный режим, требуется два человека
- ОткудаобязательноАдрес забора, склад или площадка отправления, контактное лицо отправителя
- КудаобязательноАдрес доставки, получатель, интервал приёма, комментарий по подъезду и подъёму
- Кто отвечаетобязательноТекущий ответственный: водитель, курьер, склад или сортировочная площадка — с историей передач
- Текущий статусменяется в работеОдно из состояний контура доставки; изменяется действием исполнителя, а не правкой поля вручную
- Время отправленияфиксируется фактомМомент, когда груз принят исполнителем и физически покинул точку отправления
- Время полученияфиксируется фактомМомент вручения получателю вместе со способом подтверждения
- Документы и связипо необходимостиНакладная, акт, фотографии, подпись, номер заявки, номер заказа во внешней системе
Обязательные поля — минимум, без которого груз нельзя поставить в маршрут. Остальное настраивается: у перевозки мебели и у доставки документов разный набор существенных полей, и заставлять заполнять лишнее — верный способ получить справочник, набитый прочерками.
Контроль доставки: статусы и исключения
Статус — это не подпись на экране, а состояние, из которого следуют разрешённые действия. Набор состояний конечный: пока он не назван явно, каждый сотрудник понимает «в работе» по-своему, и отчёт собрать не из чего.
- СозданЗаявка принята и проверена. Груз ещё не собран, исполнитель не назначен, но обязательства перед клиентом уже зафиксированы
- ПодготовленГруз собран и укомплектован, места промаркированы, документы готовы. С этого момента состав груза не меняется без отдельной операции
- Передан в доставкуГруз физически принят исполнителем: отметку ставит тот, кто его забрал. Ответственность переходит от склада к исполнителю
- В путиИсполнитель едет по маршруту. Здесь появляются промежуточные события: прибыл на точку, начал выгрузку, задержался у предыдущего адреса
- ДоставленПолучатель принял груз, подтверждение приложено к доставке. Только теперь доставка считается выполненной — не в момент выезда с адреса
Порядок важен именно в этом виде. Каждый переход выполняет тот, кто совершил действие, и в момент действия — иначе система показывает не состояние перевозки, а намерение диспетчера. Промежуточные состояния («на сортировке», «передан подрядчику») добавляются под процесс компании, но набор остаётся конечным и явным.
| Что произошло | Что делает система | Состояние |
|---|---|---|
| Задержка: интервал у получателя истекает | Помечает точку как просроченную, показывает её диспетчеру отдельным списком, готовит уведомление получателю о переносе | разбор |
| Клиент отменил заказ до отгрузки | Закрывает заявку с причиной отмены, снимает точку с маршрута и возвращает груз в остатки склада | штатно |
| Клиент отменил заказ, когда груз уже в пути | Не закрывает доставку молча: переводит её в возврат и ставит обратную точку в маршрут исполнителя | разбор |
| Получателя нет на месте | Фиксирует неуспешную доставку с причиной и комментарием исполнителя, оставляет груз за ним и ставит вопрос о повторной попытке | разбор |
| Получатель принял груз частично | Разделяет доставку: принятые места закрываются, отказные уходят в возврат отдельной записью | разбор |
| Груз повреждён при перевозке | Открывает событие с фотографиями и ответственным на момент повреждения, не давая закрыть доставку как обычную | разбор |
| Исполнитель не вышел на смену | Освобождает его маршрут для переназначения и показывает диспетчеру все затронутые точки одним списком | предупреждение |
Общий принцип: неуспешный исход не исчезает и не превращается в успешный. Доставка остаётся открытой и попадает в очередь разбора — это дешевле, чем отчёт, в котором проблем нет, потому что их некуда было записать.
Какие именно исключения нужны компании, решается на обследовании. Перевозке мебели нужен возврат и разбор повреждений, доставке документов — повторная попытка и подтверждение личности получателя. Набор состояний настраивается, но правило остаётся общим: любое завершение доставки имеет причину, а причина попадает в отчёт.
Диспетчерская панель
что видит диспетчер и администратор
Диспетчерская панель — рабочее место, с которого управляют днём. Её задача не «показать данные», а собрать в одном экране всё, что требует решения прямо сейчас, и не показывать остальное.
Поэтому панель устроена как рабочий стол смены: сверху то, что горит, ниже — общая картина дня, в глубине — история и справочники. Сотруднику не нужно помнить, где что лежит, чтобы ответить на звонок клиента.
Что видно в панели:
- Активные доставки — все точки в работе прямо сейчас, с исполнителем и текущим статусом
- Маршруты дня — сколько точек закрыто, сколько осталось, где маршрут отстаёт от плана
- Исполнители — кто на смене, кто на маршруте, кто освободился, у кого заканчивается рабочее время
- Статусы — распределение доставок по состояниям одним списком, без пересчёта вручную
- Задержки — точки, у которых истекает или уже истёк интервал у получателя
- Проблемные заказы — неуспешные доставки, возвраты, повреждения, отказы получателя
- Загрузка — сколько веса и объёма назначено на машину и сколько осталось свободного
- Нераспределённое — заявки, которые ещё не попали ни в один маршрут
- История операций — что происходило с любой заявкой, маршрутом или грузом, с автором и временем
Права доступа разграничивают панель по ролям. Диспетчер видит свой регион, руководитель — все направления, оператор колл-центра — статусы и контакты, но не финансовые данные.
Разграничение задаётся ролью, а не набором галочек у каждого сотрудника. Иначе через полгода права нового человека настраиваются «как у Иванова», и никто уже не может сказать, что именно ему открыто.
Сводка смены
118доставок в работе
9точек с риском просрочки
4проблемных заказа
12заявок не распределено
Кадр экрана системы, числа демонстрационные. Порядок плиток выбран не случайно: первым идёт не общий объём, а то, что требует решения. Нераспределённые заявки стоят последними, потому что это единственная плитка, которую диспетчер закрывает сам и до конца.
История операций
История — не архив «на всякий случай», а инструмент разбора. Записи не редактируются: исправление вносится новой записью. Поэтому вопрос «кто перенёс доставку на завтра» имеет ответ, а не версии.
Смотрят её обычно с одного из трёх концов: по заявке — что с ней происходило, по исполнителю — что он делал в смену, по маршруту — как он менялся в течение дня.
Связь со складом
от комплектации до передачи в доставку
Склад и логистика — не два отдела с общим чатом, а два участка одного процесса. Груз, который «собран, но не передан», и груз, который «передан, но не отмечен», — это два разных состояния, и путать их дорого.
Единый цифровой процесс означает одно: каждый переход между складом и доставкой фиксируется действием, а не сообщением. Кладовщик отмечает комплектацию, водитель — приём груза, получатель — получение. Между этими отметками груз всегда числится за конкретным участком.
Что даёт стык складу: он видит, что уже уехало, а что стоит в зоне отгрузки вторые сутки. Что даёт логистике: маршрут не планируется на груз, который ещё не собран, а водитель не приезжает к воротам раньше, чем есть что грузить.
Полный складской учёт — приёмка, размещение, инвентаризация, партии и сроки годности — тема отдельной страницы. Здесь описан только стык: что склад передаёт логистике и что получает обратно.
- 1Заказ
- 2Комплектация
- 3Подготовка
- 4Передача
- 5Доставка
- 6Подтверждение
Четвёртый переход — единственный, где груз меняет ответственного. Именно поэтому он оформляется отдельной операцией с двумя сторонами: склад сдал, исполнитель принял. Если этот шаг пропущен, при пропаже места невозможно назвать участок, а разбор превращается в опрос смены.
Что передаётся между складом и логистикой
- Со склада в логистику — состав собранного заказа, количество мест, вес и объём, готовность к отгрузке, номера маркировки
- Из логистики на склад — плановое время подачи транспорта, кто приедет за грузом, в какой маршрут он попадает
- Обратно на склад — возвраты, отказные места и недоставленные грузы с причиной, по которой они вернулись
- Общее для обоих — история перемещений места: где оно было, кто его принял и когда сменился ответственный
Если склад работает в другой программе
Это обычная ситуация: складской учёт уже ведётся в существующей системе, менять её никто не собирается. Тогда стык строится обменом — логистика получает готовность заказов и состав мест, а возвращает статусы и подтверждения.
Состав и частота обмена определяются тем, что внешняя система умеет отдавать. Возможности конкретной программы уточняются на обследовании — заранее заявлять готовую интеграцию было бы обещанием за чужой продукт.
Заявки и маршруты
Грузы и статусы
Диспетчерская панель
Отчётность по доставкам
Как сотрудники работают с системой
У каждой роли своё рабочее место и свой набор действий. Это не ограничение ради ограничения: чем меньше лишнего на экране, тем меньше ошибок в смене и тем короче обучение нового человека.
Оператор заявок
Принимает заявки из всех каналов, проверяет адреса и состав груза, уточняет спорное у клиента. Видит очередь на уточнение и свои заявки; маршруты и загрузку транспорта не трогает.
Диспетчер
Собирает маршруты, назначает исполнителей, ведёт день: переносит точки, реагирует на задержки, разбирает проблемные доставки. Основной пользователь панели и главный источник изменений в течение дня.
Кладовщик
Отмечает комплектацию и готовность к отгрузке, оформляет передачу груза исполнителю и приём возвратов. Работает с местами и маркировкой, а не с маршрутами.
Водитель
Получает маршрут на смену, отмечает забор и доставку, фиксирует причину, если точка не закрылась. Видит только свои задания на день и данные, нужные для их выполнения.
Курьер
Тот же сценарий, но в мобильном интерфейсе и с большим числом коротких точек за смену. Подтверждает получение, прикладывает фото или подпись, пишет комментарий по адресу.
Руководитель
Смотрит не смену, а период: объём доставок, долю выполненных в срок, загрузку, перечень повторяющихся сбоев. Оперативные действия ему не нужны — нужны цифры, на которые можно опереться.
Курьеры и водители
рабочий интерфейс исполнителя
Исполнителю нужен не «доступ к системе», а короткий список того, что делать сейчас. Поэтому его рабочее место — отдельный интерфейс: мобильное приложение или адаптированная веб-страница, а не та же панель, что у диспетчера.
Что в нём есть:
- Список заданий на смену в порядке объезда
- Адреса с комментариями по подъезду, этажу и входу
- Информация о заказе: что везём, сколько мест, кто получатель, есть ли оплата при получении
- Смена статуса одним действием: приехал, забрал, доставил
- Подтверждение получения груза на точке отправления
- Подтверждение доставки: подпись, фотография или код от получателя
- Комментарий к точке, когда что-то пошло не по плану
- Связь с диспетчером из карточки задания, без поиска номера в телефоне
Важное требование к такому интерфейсу — работа при плохой связи. Отметки, сделанные вне сети, сохраняются на устройстве и досылаются, когда связь появится; повторная отправка не создаёт вторую доставку.
Подробный разбор работы исполнителя — тема отдельной страницы «Для курьеров». Здесь важно другое: отметки в этом интерфейсе — единственный источник фактических статусов, поэтому он проектируется первым, а не последним.
Что даёт компании отметка на месте
Отметка исполнителя в момент действия — это не контроль ради контроля. Из неё берутся фактическое время доставки, длительность точки и причина сбоя. Без неё все три показателя восстанавливаются по памяти в конце дня, то есть не восстанавливаются.
Второй эффект — снятая нагрузка с диспетчера: пока статусы ведёт он со слов по телефону, половина смены уходит на переписывание чужой работы в систему.
Почему это отдельный интерфейс
У исполнителя другие условия работы: телефон в одной руке, коробка в другой, экран на солнце, связь через раз. Панель диспетчера в таких условиях не используется — ей нужны крупные элементы, минимум полей и понятное поведение без сети.
Поэтому его рабочее место проектируется под смену, а не под полноту данных: на экране только текущая точка и следующая, остальное убрано вглубь.
Аналитика
какие данные можно измерить
Отчёты имеют смысл только там, где данные попадают в систему в момент действия. Если статусы проставляются вечером «по итогам дня», любой отчёт покажет аккуратную картину, не связанную с тем, что происходило.
Что считается по накопленным данным:
- Количество доставок — за день, неделю, месяц; по направлениям, клиентам и исполнителям
- Выполненные и проблемные заказы — доля доставленных в срок и перечень тех, что закончились иначе, с причинами
- Сроки доставки — фактическое время от заявки до вручения и от передачи в доставку до получения
- Загрузка — сколько точек, веса и объёма приходится на машину и на исполнителя, сколько остаётся свободного
- Эффективность маршрутов — число точек за смену, доля закрытых по плану, время между остановками
- История операций — источник для разбора конкретного случая, а не только для сводных цифр
Определения показателей задаются один раз и используются всеми отчётами. «Доставлено в срок» должно означать одно и то же в отчёте диспетчера и в отчёте руководителя — иначе две сводки за один день не сойдутся, и обе перестанут вызывать доверие.
Отчёты выгружаются файлом, строятся по расписанию и могут уходить во внешнюю систему аналитики через API — состав выгрузки определяется проектом.
Сводка за неделю
612доставок за период
27завершены не штатно
Кадр экрана системы, числа демонстрационные. Вторая плитка важнее первой: пока не разобран состав нештатных завершений — отмены, возвраты, неуспешные доставки, — общий объём говорит только о загрузке, но не о качестве работы.
Интеграции и обмен данными
Логистическая система редко стоит одна: заказы приходят из одной программы, клиенты ведутся во второй, остатки — в третьей. Ниже — направления, по которым обмен строится чаще всего. Конкретный состав интеграции определяется тем, что внешняя система умеет отдавать, и уточняется на обследовании.
Интернет-магазин
Оформленный заказ может передаваться в логистику заявкой автоматически, а статус доставки — возвращаться покупателю в личный кабинет. Как устроена сама витрина и учёт заказов, разобрано на странице электронной коммерции.
CRM
Возможна интеграция со справочником клиентов и историей сделок: заявка создаётся из карточки клиента, а результат доставки возвращается менеджеру. Обмен ведётся по идентификатору клиента, чтобы не плодить дубли контрагентов.
ERP и учётная система
Может работать совместно с учётным контуром компании: заказы, накладные, взаиморасчёты. Направление обмена и набор документов определяются тем, какой учёт признаётся основным.
Складская система
Готовность заказов, состав мест и маркировка приходят со склада, статусы и возвраты уходят обратно. Если склад ведётся во внешней программе, стык строится обменом — см. раздел о связи со складом выше.
Программа для курьеров
Рабочее место исполнителя может быть частью системы или отдельным приложением, подключённым через API: получает задания, возвращает статусы и подтверждения. Второй вариант нужен там, где приложение уже используется.
Системы оплаты
Там, где есть оплата при получении, возможна интеграция с платёжным сервисом или терминалом исполнителя: сумма к оплате приходит из заявки, результат платежа возвращается в доставку. Состав зависит от провайдера.
Внешние сервисы
Карты и геокодирование адресов, телематика транспорта, службы уведомлений, подрядчики-перевозчики. Каждое такое подключение — отдельный модуль обмена; наличие готового коннектора заранее не заявляется.
API
Собственный интерфейс системы: создать заявку, получить статус и маршрут, передать подтверждение доставки, забрать журнал операций. Через него подключается всё, для чего нет отдельного модуля.
Правила обмена везде одни: у каждой операции есть ключ, поэтому повторная передача не создаёт вторую заявку; расхождения не исчезают, а попадают в очередь разбора; каждая посылка и каждый ответ пишутся в журнал обмена. Без этих трёх правил интеграция работает ровно до первого обрыва связи.
Порядок внедрения
Логистику не переводят в систему целиком за один день: пока сотрудники ведут статусы по-старому, данные в отчётах не значат ничего. Поэтому запуск идёт участками, и каждый следующий опирается на работающий предыдущий.
1. Обследование
Как заявки приходят сейчас, кто планирует маршруты, чем ведутся статусы, какие программы уже стоят и что они умеют отдавать. Итог — описание процесса и перечень того, что автоматизируется в первую очередь.
2. Пилот на одном направлении
Один город, одна служба доставки или один склад. Заявки, маршруты, статусы и отметки исполнителей проходят полный круг на реальных перевозках — до того, как процессом накрывается вся компания.
3. Роли и правила
Кто что может менять, какие исключения нужны, как обрабатывается возврат и неуспешная доставка, кому уходят уведомления. Здесь же настраиваются права и порядок ручных изменений маршрута.
4. Развёртывание и обмен
Остальные направления по отработанной схеме, интеграции — отдельными модулями обмена. Дальше копится история, появляются отчёты за период и данные для планирования транспорта.
Наши клиенты
Обсудим вашу логистику
Свяжитесь с нами сейчас
Напишите, сколько доставок в день, откуда приходят заявки, свой транспорт или подрядчики, есть ли склад и в каких программах уже лежат ваши данные. Мы ответим, что автоматизируется в первую очередь, что можно подключить к существующим системам и с чего разумно начать пилот.
