Какие классы программ использует транспортный экспедитор?
Транспортный экспедитор обычно сочетает CRM для клиентских отношений, TMS для управления перевозкой, биржи для поиска спроса и исполнителей, ЭДО и ЭПД для документов, бухгалтерскую систему для расчётов и каналы связи с внешними участниками. Эти классы не являются взаимозаменяемыми: каждый хранит собственный контекст и должен передавать дальше только согласованные данные.
| Класс | Что решает | Главный объект | Типичное ограничение |
|---|---|---|---|
| CRM | Клиенты, лиды, коммуникации и коммерческие договорённости | Продажи и клиентский контекст | Обычно не подтверждает фактическое исполнение рейса |
| TMS | Заявки, планирование, ставки, маршруты, исполнение и аналитика | Операционный процесс перевозок | Может быть ориентирована на одну организацию |
| FMS | Автопарк, ТО, ремонты, ГСМ, путевые листы и технические показатели | Транспортные средства и эксплуатация | Не заменяет коммерческий и документарный lifecycle рейса |
| Биржа / marketplace | Поиск грузов, транспорта, ставок и контрагентов | Спрос, предложение и конкурентный выбор | После сделки нужен отдельный контур исполнения |
| ЭДО / ЭПД | Юридически значимый обмен, подписи, титулы и статусы документов | Документарные доказательства | Не обязательно владеет коммерческим объектом перевозки |
| Цифровой рейс | Участники, факты, документы, расхождения и готовность к расчёту | Межорганизационная история перевозки | Требует интеграций со специализированными системами |
Как разделить CRM и TMS в работе экспедитора?
CRM должна отвечать на вопросы о клиенте, договорённостях, коммерческом предложении и истории коммуникаций, а TMS — о конкретной перевозке, маршруте, назначениях, фактических событиях и исключениях. Граница проходит в момент, когда согласованная потребность становится исполняемым рейсом с устойчивым идентификатором, участниками и контролируемым жизненным циклом.
Практическая схема может выглядеть так: продажа и запрос фиксируются в CRM, подтверждённые условия создают рейс, а результат исполнения и расчётный статус возвращаются в клиентский контекст. Повторный ручной ввод одних и тех же реквизитов означает, что граница систем спроектирована не до конца.
Зачем экспедитору цифровой рейс?
Цифровой рейс связывает коммерческие условия, перевозчика, водителя, точки маршрута, события, документы и основания для расчёта без превращения всех данных в одну общую таблицу. Экспедитор получает проверяемую историю изменений и может отделить обещание клиенту от фактического исполнения, а также понять, какое действие или документ ещё блокирует закрытие перевозки.
Такой объект особенно важен при смене исполнителя, переносе окна, простое, отмене, расхождении в документах или повторной отправке события. Исключение становится частью процесса, а не потерянным сообщением в переписке.
Какие интеграции важны для экспедиторской компании?
Приоритет обычно получают бухгалтерская система, справочник контрагентов, ЭДО и ЭПД, биржи, уведомления, мониторинг и клиентский контур. Интеграция должна иметь точный контракт, идемпотентность, таймаут, журнал ошибок и безопасное повторение операции. Прямая запись в чужую базу или универсальный прокси создают зависимость, которую трудно контролировать и восстанавливать.
Каждый источник должен сохранять происхождение данных. Ставка с биржи, реквизиты из справочника, подпись оператора ЭПД и геопозиция водителя имеют разную юридическую и операционную силу, поэтому не должны сливаться в один безымянный статус.
Как оценить программу до внедрения?
До демонстрации интерфейса зафиксируйте пять–десять реальных сценариев: создание перевозки, назначение перевозчика, смена водителя, простой, работа без связи, подпись ЭТрН, закрывающие документы и спорное расхождение. Затем проверьте владельцев данных, роли, ограничения, API, восстановление после сбоя и полную стоимость владения, включая внедрение и поддержку.
Критерии для экспедитора
- 01 Один источник статуса Заявка, назначение, фактические события и документы должны связываться устойчивым идентификатором.
- 02 Внешние участники Перевозчик, водитель, грузоотправитель и грузополучатель получают ограниченный доступ без покупки полного рабочего места.
- 03 Маржа и расчёты Коммерческие условия видны только разрешённым ролям, а готовность к оплате отделена от фактического платежа.
- 04 Документы Система различает обычные файлы, ЭДО, ЭПД и титулы ЭТрН, не смешивая их владельцев.
- 05 Интеграции Нужны проверяемые контракты с 1С, операторами ЭДО/ЭПД, биржами, мониторингом и уведомлениями.
- 06 Исключения Смена перевозчика, отмена, простой, расхождение и повторная доставка должны быть частью процесса, а не ручной перепиской.