Диспетчер в транспортной компании на 40 машин за смену принимает 25–30 заявок: часть по телефону, часть в WhatsApp, часть письмом на почту. К концу дня в Excel-файле «Заявки_октябрь.xlsx» лежит 27 строк, а в трёх чатах — ещё 14 сообщений с уточнениями: «перенесли погрузку на 14:00», «водитель Иванов не выйдет, ищите замену», «клиент просит ТТН на другой адрес». Сверить это в одну картину к вечеру стоит примерно 40 минут, и каждый пропущенный статус — это звонок от клиента на следующее утро.
Ниже разбираем три варианта, как такая компания может вести цепочку «заявка → рейс → водитель → статус». Сравниваем по критериям, которые реально всплывают на обследовании, и показываем, в какой ситуации какой вариант разумен.
Что должно происходить с заявкой от звонка до закрывающих
Прежде чем выбирать инструмент, стоит зафиксировать сам процесс. В грузоперевозках и экспедировании он почти всегда состоит из одних и тех же шагов:
- Заявка от клиента: маршрут, тип груза, вес и объём, дата и время погрузки, требования к машине (фура, реф, изотерм), ставка.
- Проверка: есть ли свободная машина, подходит ли водитель по документам, хватает ли пропусков на объект.
- Назначение перевозчика или своего водителя, подтверждение ставки.
- Рейс: погрузка, документы (ТТН, транспортная накладная, доверенность на водителя), движение по маршруту.
- Выгрузка, получение отметок в накладных, скан-копии.
- Закрывающие: счёт, акт, УПД, оригиналы ТТН и транспортной накладной для клиента, сверка с перевозчиком.
На каждом шаге есть статус. Если статус живёт в голове диспетчера или в переписке, система заявок превращается в телефонный справочник. Задача любой системы — держать статус в одном месте и показывать его тем, кому он нужен: клиенту, логисту, бухгалтеру.
Вариант А: Excel плюс чаты — как это работает сегодня
Самый частый стартовый сценарий в МСБ до 30–40 машин. Есть файл, где диспетчер ведёт строки заявок, есть общий чат в Telegram или WhatsApp с водителями и отдельный чат с клиентами. Бухгалтерия получает данные по факту, когда диспетчер присылает выгрузку или пересылает письмо.
Что здесь работает: скорость старта. Ничего не надо внедрять, диспетчер уже умеет. Что ломается:
- Двойной ввод. Одна и та же заявка живёт в Excel, в чате и в письме. При 25 заявках в день это 25–30 минут на сверку, при 60 — уже полтора часа.
- Потеря статуса. Клиент звонит «где машина», диспетчер ищет в трёх местах. В среднем 3–5 минут на один такой запрос, а их за день бывает 10–15.
- Ошибки в закрывающих. Если рейс не отмечен как выполненный, счёт уходит позже, дебиторка растёт. Задержка на 3–5 дней по 10 рейсам в месяц — это ощутимая дыра в кассе.
- Отсутствие истории. Через месяц никто не вспомнит, почему ставка по этому клиенту была ниже обычной.
Excel держится до определённого объёма. Как только заявок становится больше 40 в день, а машин больше 25, диспетчер начинает работать на пределе и ошибаться.
Вариант Б: доработка 1С под заявки и рейсы
Если в компании уже стоит 1С:УТ 11 или 1С:ERP и в ней ведётся учёт, логично попробовать доработать её. В 1С есть документы реализации, счета, УПД, и бухгалтерия уже там. Добавляем справочник рейсов, статусы, печатные формы транспортной накладной — и вроде бы всё.
Плюсы очевидны: данные не дублируются, закрывающие формируются из той же базы, интеграция с Диадок или СБИС уже настроена. Минусы проявляются на практике:
- Интерфейс 1С для диспетчера тяжёлый. Чтобы внести заявку, надо открыть документ, заполнить 15–20 полей, часть из них не нужна на этапе приёма. Диспетчер тратит 4–6 минут на одну заявку вместо 1–2.
- Мобильного кабинета водителя в типовой 1С нет. Статусы «погрузился», «в пути», «выгрузился» всё равно собираются по телефону.
- Любая доработка 1С — это обновления, которые надо поддерживать. При следующем релизе конфигурации часть дописанного ломается, и нужен человек, который это чинит.
- Стоимость доработки под полноценную диспетчерскую сопоставима с отдельной системой, но гибкость ниже.
Доработка 1С разумна, когда заявок немного (до 20–25 в день), а главная задача — не потерять связь с бухгалтерией и закрывающими. Если же узкое место в диспетчерской, 1С его не разгружает.
Вариант В: заказная диспетчерская система
Отдельная система, написанная под процесс конкретной компании. В ней есть карточка заявки, карточка рейса, справочник водителей и перевозчиков, статусы, мобильное приложение для водителя и интеграции с 1С и ЭДО. Диспетчер работает в лёгком интерфейсе, водитель отмечает статусы в приложении или через Telegram-бот, бухгалтерия получает данные в 1С.
Что это даёт на цифрах. На одном из проектов в транспортной компании на 35 машин после запуска такой системы время на приём заявки сократилось с 5 до 2 минут, количество звонков «где машина» упало примерно вдвое, а закрывающие стали уходить на 2–3 дня раньше. При 30 заявках в день экономия времени диспетчера — около 1,5 часа за смену, это почти полноценная ставка на приёмке.
Ограничения тоже есть. Заказная система требует обследования процесса, описания статусов и справочников, времени на разработку и запуск. Обычно это 6–10 недель до первой рабочей версии, если процесс понятен. И она требует дисциплины: если диспетчер продолжит писать в чат «на всякий случай», система не заработает.
Сравнение по критериям
| Критерий | А: Excel и чаты | Б: доработка 1С | В: заказная система |
|---|---|---|---|
| Время на приём одной заявки | 3–5 минут плюс сверка | 4–6 минут из-за тяжёлой формы | 1–2 минуты |
| Статус рейса | В чате и в голове диспетчера | В документе 1С, обновляется вручную | В карточке рейса, обновляет водитель |
| Мобильный кабинет водителя | Нет | Нет в типовой | Есть, приложение или Telegram-бот |
| Связь с бухгалтерией | Ручная выгрузка | Прямая, в одной базе | Через интеграцию с 1С |
| Закрывающие документы | Собираются вручную, задержки 3–5 дней | Формируются из 1С | Формируются из 1С по данным рейса |
| Стоимость запуска | 0 ₽, но растущие потери времени | От 150 000 ₽ за доработку плюс поддержка обновлений | От 400 000 ₽ в зависимости от объёма |
| Гибкость под процесс | Высокая, но руками | Низкая, ограничена конфигурацией | Высокая, пишется под компанию |
| Срок запуска | Сразу | 4–8 недель | 6–10 недель |
В какой ситуации что выбирать
Excel и чаты остаются разумными, пока в компании до 15–20 машин и до 20 заявок в день. Диспетчер один, объём он держит в голове, потери времени терпимые. Как только появляется второй диспетчер или объём переваливает за 30 заявок, файл начинает трещать.
Доработка 1С подходит, если главная боль — разрыв между диспетчерской и бухгалтерией, а не внутри диспетчерской. Например, заявок 20 в день, но закрывающие документы гуляют по почте и теряются оригиналы ТТН. Здесь достаточно добавить в 1С справочник рейсов и статусы, а мобильный кабинет водителя не критичен.
Заказная диспетчерская система нужна, когда узкое место — сама диспетчерская: много заявок, много перевозчиков, статусы собираются по телефону, клиенты звонят «где машина», а бухгалтерия ждёт данные. В этом случае отдельная система с мобильным кабинетом водителя и интеграцией с 1С разгружает диспетчера и ускоряет закрывающие.
На обследованиях мы часто видим одну и ту же картину: компания уже купила CRM или доработала 1С, но диспетчер всё равно ведёт параллельный Excel, потому что в системе неудобно принимать заявку за 2 минуты. Пока этот разрыв не закрыт, любая система остаётся надстройкой над чатами.
Если хотите понять, хватит ли доработки текущей 1С или нужна своя диспетчерская, пришлите описание процесса в Telegram @automationdev24. Разберём, где именно теряются заявки и статусы, и скажем, какой из трёх вариантов ближе к вашей ситуации.
Узнали свою ситуацию?
Опишите в Telegram, как у вас сейчас идут заявки и учёт. Скажем, хватит ли доработки вашей CRM или лучше собрать свою систему. Первая консультация бесплатная.
Написать в Telegram