FESCO (входит в контур управления «Росатом») — крупная транспортно-логистическая группа с разветвлённой инфраструктурой и широкой географией перевозок. Автомобильная логистика для компании — полноценная часть транспортной цепочки, которая связывает морские, железнодорожные и терминальные операции.
В этой части бизнеса задействован как собственный автопарк, так и подрядные перевозчики. Каждый рейс — набор взаимосвязанных действий: планирование маршрута, подбор транспорта, работа с терминалами, контроль сроков и оформление документов.
Когда таких рейсов становится тысячи, устойчивость всей цепочки начинает зависеть от того, насколько управляем процесс.
Изначально управление автоперевозками строилось вокруг нескольких разрозненных инструментов.
Заявки жили в TMS на базе 1С и были доступны только внутренним диспетчерам (на самом деле и продолжают там жить для сохранения всех существующих связок с документооборотом, ЭДО и другими сервисами, но обо все по порядку). Подрядчики работали вне системы — коммуникация с ними шла через почту, звонки и мессенджеры. Водители получали инструкции теми же каналами. Это означало постоянные уточнения, риск потерять информацию и зависимость от человеческого фактора. При этом команды были распределены по часовым поясам — от Москвы до Владивостока.
Такая рабочая модель не успевала адаптироваться к росту количества рейсов. Чтобы понять, что происходит с конкретной заявкой, диспетчеру приходилось собирать данные вручную. Контроль становился реактивным: отследить статус всех перевозок в моменте было практически невозможно.
Отдельной задачей была работа с подрядчиками. Не хватало прозрачности и единых правил взаимодействия. При этом FESCO стремилась активнее привлекать небольших перевозчиков, поэтому процессы аккредитации и выбора подрядчика требовали автоматизации, что позволило бы снизить нагрузку на диспетчеров и ускорить работу.
Стало очевидно: FESCO нужна единая среда, в которой все участники процесса — . диспетчеры ФЕСКО Транс, собственные водители, диспетчеры партнёров и их водители — работают синхронно и видят актуальные данные. Так появилась система TRUCKS
В FESCO работала и продолжает успешно работать TMS на базе 1C-Axelot, но это внутренняя система, которую неправильно «выставлять в интернет». Плюс нужно решение с удобными интерфейсами и мобильным приложением, а это только веб-технологии. Как строится рабочий процесс диспетчера и водителей в новой системе? Посмотрим на примере обработки новой заявки.
Владимир Апалихин, FESCO
Ядро системы — оперативная работа с заявками. Все заявки поступают из TMS и формируют единый реестр: статус, маршрут, местоположение транспорта, последнее действие.
Диспетчер работает одновременно с 30–50 заявками. Фактически, он принимает решение каждые 20–30 секунд. Система должна направлять внимание диспетчера: акцентировать важные данные, подсвечивать проблемные точки, формировать выборки за счёт быстрого поиска и гибкой фильтрации, запускать процесс перевозки с минимальным количеством кликов. А работа диспетчеров и водителей подрядчика в этой же системе позволяет обмениваться информацией мгновенно. На рабочем месте оператора встречает реестр всех заявок. Статусы сразу подсказывают, какое действие нужно совершить с той или иной заявкой.
Алексей Зайцев, FESCO

Первый шаг выполнения заявки клиента — назначение перевозчика. Процесс проходит внутри заявки.

Выбор перевозчика может развиваться по трём сценариям:
Система помогает диспетчеру понять, какого пути придерживаться через календарь текущей загрузки ресурсов (водителей и транспорта). Это таблица с наглядным отображением занятости:

График перевозок помогает равномерно распределять работу и быстрее находить свободный транспорт. Это фундаментальная функция для развития в сторону «рекомендательной системы»: предложение вариантов «с колёс», объединение «близких» заявок. Внутри заявки есть сокращённый вариант отображения загрузки ресурсов (авто и водителей), из которого можно перейти в полноценный календарь для более комплексного рассмотрения.
Павел Мелдажис аккаунт-директор Ареал
Если доступны свои водители или для перевозки нужен специфичный транспорт, который есть у определённого подрядчика, то диспетчер через соответствующие фильтры быстро подбирает исполнителя. Если календарь подсказывает что свои водители и ТС недоступны, но свободны несколько подрядчиков, то диспетчер переходит к торгам.
В TRUCKS заложены разные типы торговых процедур:
Диспетчер FESCO инициирует процедуру, задаёт параметры: период, список участников, формат аукциона, правила выбора победителя. Перевозчики, подпадающие под условия процедуры, подают предложения, в процессе могут их корректировать.

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

Механизм торговых процедур повысил прозрачность работы с подрядчиками, создал конкуренцию и дал компании рыночную цену на перевозку — без долгих переговоров и ручного сравнения. После выбора перевозчика вся информация сразу же уходит в мобильное приложение водителя, при это не важно, это водитель FESCO или водитель подрядчика. Начинается второй этап — процесс перевозки.
Екатерина Мочалова менеджер проекта Ареал
Мобильное приложение TRUCKS для водителей переводит фрагментарную работу с заявкой в систему.
Водитель видит:

Когда водитель приезжает на терминал или стоянку, где оборудован и подключён принтер для печати, ему помогает сервис «печать документов». Водитель в приложении выбирает что печатать, сколько печатать и отправляет на печать. Так же для водителя, диспетчера доступен сервис печати через любое устройство (ПК, планшет, телефон) с доступом в интернет и подключённым принтером. Водитель, диспетчер передаёт специальную ссылку сотруднику терминала для поиска и печати документов. Авторизация для печати происходит по номеру телефона водителя и PIN-коду.
С введением ЭТрН процесс сильно не изменится. ЭТрН — это ещё один документ, с которым будет настроено взаимодействие через приложение СБИС.
На пути следования водитель отмечает прибытие и убытие с контрольных точек одним действием (система предусматривает автоматический контроль прибытия/убытия через сервис геолокации), загружает фотографии, передаёт данные по грузу, завершает рейс. Вся информация сразу же видна диспетчеру на рабочем месте. Система Trucks сама отслеживает отклонения. Если водитель не успевает к точке, диспетчер получает сигнал. Trucks рассчитывает опоздания по отметке водителя на маршруте или по геолокации.
Кроме слежения за отклонениями, диспетчер внутри заявки:

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

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

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

Система отслеживает статусы и сроки. Когда аккредитация подходит к концу, перевозчик получает сигнал и продлевает её онлайн, обновляя данные.
В результате подключение новых партнёров перестало быть «ручным» процессом. Компания получила управляемую и актуальную базу перевозчиков, готовых к работе.
Возникает закономерный вопрос: если с бумажными документами и отсутствуем единого цифрового пространства с поставщиками система была нужна, то с появлением ГИС ЭПД и обязательным обменом через ЭДО, зачем нужна подобная система типа Trucks, ведь всё сейчас централизованно?
На самом деле ответ на поверхности: документ в ЭДО — это финальный штрих, который фиксирует предыдущие внутренние процессы и договорённости с партнёрами. ЭДО не заменяет процессы выбора машины/водителя, не отыгрывает аукционы, не агрегирует/анализирует информацию из разных источников (не только ГИС ЭПД, но и внутренние системы, мобильного приложения водителя
И главное, ЭДО — это не система для планирования, это система для фиксации результатов.
Если у вас 1С и ЭДО фиксируются все заключённые договоры, счета и акты оказанных услуг, вы же не задаётесь вопросами: «Зачем нам CRM?» или «Зачем нам TMS?»
Система TRUCKS работает на платформе Wapps, приложения:
Переход к единой системе изменил не отдельные операции, а саму логику управления автоперевозками. Снизилось влияние человеческого фактора, ускорилось принятие решений, упростилось масштабирование.
Компания FESCO получила:
FESCO Trucks — шаг к автономной системе, где выработка и подбор лучшего решения ложится на цифрового помощника, а за диспетчером остаётся финальное решение.