INTEBRIX Optimization Platform
On-prem • Cloud в разработке Запросить демо

INTEBRIX • Продукт-ядро

Dispatcher (Fleet Utilization) —
диспетчеризация, укомплектование и маршрутизация под ограничения

Ядро для исполнимого плана перевозок: вы формализуете заявки, сеть, парк/ресурсы и правила — и получаете рейсы и маршруты с учётом окон/SLA, вместимости/веса, сменности, совместимости и стоимости. При изменениях (срочный заказ, отмена точки, поломка, дефицит транспорта) — пересчёт и понятный ответ: что изменилось, где узкое место и почему часть заявок не помещается.

✓
Маршруты и рейсы: окна/SLA, время на точке, запреты, приоритеты
✓
Укомплектование: вес/объём/совместимость, правила загрузки, партии
✓
Парк и ресурсы: типы ТС, доступность, сменность, подрядчики
✓
Мультимодальность: авто / ЖД / река / авиа — единая логика оптимизации ресурса
Запросить демо Хаб “Диспетчеризация” →
On-prem • Cloud в разработке • Пилот 2–6 недель • Интеграции: ERP / 1C / Excel / API
Что на выходе • Мультимодальность • Гибкая настройка • FAQ

Что вы получаете на выходе

Фокус — на исполнимости, утилизации ресурса и управлении изменениями: план можно выполнять и быстро обновлять.

Исполнимый план рейсов
Рейсы с учётом окон/SLA, времени обслуживания, запретов и приоритетов.
RoutingWindows
Утилизация транспорта
Загрузка по весу/объёму, распределение по типам, сменам и базам.
FleetUtilization
KPI и trade-offs
Видно, какой KPI “покупаем” (SLA/стоимость/парк) и чем платим.
CostSLA
Перепланирование и пояснимость
Список изменений: что уехало куда, что сдвинулось и какое ограничение сработало.
RescheduleExplainability
До пилота не обещаем “проценты”: сначала считаем baseline на ваших данных, затем сравниваем сценарии и решения.

Мультимодальность: не только про автодорогу

Dispatcher моделирует транспорт как ресурс (единицы, смены, ограничения), а перемещения — как сеть плеч с временем/стоимостью. Поэтому ядро применимо к фурам, малотоннажке, вагонам/составам, баржам/судам, авиа — и смешанным мультимодальным цепочкам.

Авто: фуры и малотоннажка
Маршруты с окнами, укомплектование, парковая логика, точки и времена обслуживания.
  • окна, SLA, время на точке
  • вес/объём/совместимость
  • сменность и доступность
ЖД: вагоны и составы
Утилизация вагонов/составов: лимиты, доступность, плечи и узлы.
  • ресурс (вагон/состав)
  • узлы и плечи сети
  • тарифы и ограничения
Река/море/авиа
Баржи, суда, самолёты: те же принципы ограничений, стоимости и SLA по плечам.
  • ресурс (борт/судно)
  • время/стоимость плеч
  • правила узлов

Какие сценарии можно считать

Диспетчеризация — это про варианты. Важно не просто “посчитать”, а сравнить KPI и увидеть, что ограничивает план.

Окна и SLA
Проверить выполнимость по окнам и понять, какие точки “не помещаются” и почему.
  • штрафы/приоритеты SLA
  • время на точке
  • критические узлы/плечи
Свой парк vs подрядчик
Сравнить стоимость, SLA и лимиты подрядчиков, понять где дешевле “закрыть спрос”.
  • лимиты подрядчика
  • стоимость vs сервис
  • правила назначения
Нехватка ресурса
Добавить сменность, типы транспорта или “переразложить” рейсы без ручной перекладки.
  • сменность и доступность
  • перераспределение
  • что станет дороже
Правила загрузки
Совместимость, партии, запреты, температурные режимы — и их влияние на KPI.
  • совместимость товаров
  • партии и приоритеты
  • trade-offs
Мультимодальные плечи
Сравнить варианты “авто+ЖД”, “река+авто”, “авиа+авто” по срокам и стоимости.
  • стоимость плеч
  • ограничения узлов
  • SLA по цепочке
Срочные изменения
Срочный заказ, отмена точки, поломка — пересчёт и список изменений “что куда переехало”.
  • быстрый пересчёт
  • список изменений
  • причины отклонений

Гибкая конфигурация под ваш контур

Dispatcher — это не “одна схема на всех”. Мы настраиваем сущности, правила, KPI и ограничения под ваш регламент и логику перевозок.

Ваша модель = ваша версия ядра
Вы получаете кастомизированную конфигурацию ядра: парк, окна, правила загрузки, совместимость, стоимость и KPI — так, как это работает у вас.
ConfigurableConstraints
Итеративно: от минимума к точности
Можно стартовать с “достаточного минимума” и уточнять модель: добавлять правила, тарифы, запреты, типы транспорта и мультимодальные плечи.
Fast startIterative
Под ваш регламент
Настраиваем процесс: кто вводит заявки, кто запускает расчёт, кто фиксирует план, как обрабатываются срочные изменения.
ProcessGovernance
Связь со “сквозной цепочкой”
Можно связать диспетчеризацию с другими ядрами платформы, чтобы оптимизировать не кусок, а цепочку целиком.
Перейти к Supply Chain → Стратегические потоки →

Как это выглядит в работе

Без “магии”: фиксируем контур и KPI, загружаем данные, считаем baseline и 2–3 сценария.

1
Контур и KPI
Парк, сеть, окна/SLA, правила загрузки, KPI (стоимость/SLA/утилизация) и ограничения.
2
Данные
Заявки, точки/узлы, плечи (время/стоимость), доступность ресурса, базовые запреты/совместимость.
3
Baseline → сценарии
Сравнение вариантов по KPI и объяснение: что ограничило план и как “развязать” узкое место.

Какие данные нужны для старта

Начать можно с минимума. Если чего-то нет — берём оценки/диапазоны и уточняем модель итерациями.

Минимум
  • заявки: откуда→куда, вес/объём, дедлайн/окно, приоритет
  • точки/узлы сети и базовые адреса
  • парк/ресурс: типы, вместимость/вес, доступность (хотя бы оценочно)
  • базовые правила (например: совместимость “да/нет”)
Желательно
  • матрица время/стоимость плеч (карта/расстояния/тариф)
  • время обслуживания на точках
  • детальные правила загрузки и совместимость классов
  • стоимости: рейс/км/час, штрафы SLA
Если данных нет
  • стартуем с оценок/диапазонов
  • калибруем на истории рейсов
  • фиксируем “как принято” простыми правилами
  • повышаем точность по мере внедрения

Пилот и внедрение

Стандартная траектория: быстро считаем baseline, затем сравниваем сценарии и закрепляем регламент работы.

Шаг 1
Демо + KPI + чек-лист данных
Согласуем KPI (стоимость/SLA/утилизация), контур и формат выгрузок.
1–2 созвона • 30–60 минут
Шаг 2
Подготовка данных
Собираем минимальный набор и приводим к расчётному виду.
3–7 дней
Шаг 3
Модель ограничений
Фиксируем окна, правила загрузки, совместимость, смены, типы ресурса, стоимости и штрафы.
1–2 недели
Шаг 4
Baseline + 2–3 сценария
Сравниваем варианты по KPI и формируем выводы “что менять”.
1–2 недели
Шаг 5
Регламент и закрепление
Роли, сценарный цикл, правила перепланирования и контроль изменений.
2–5 сессий
Хотите оценить на ваших данных?
Расскажите, что “болит”, или пришлите пример выгрузки — предложим формат пилота.
Запросить демо Как внедряем →

FAQ по Dispatcher

Коротко: про оптимизацию, мультимодальность, старт с минимума и интеграции.

Это “маршруты на карте” или полноценная оптимизация?

Это оптимизация в рамках ограничений. Вы задаёте окна/SLA, вместимость/вес, совместимость, сменность, стоимость и KPI — а система подбирает исполнимый план рейсов и маршрутов, показывая trade-offs и причины отклонений.

Подходит ли ядро для ЖД/барж/авиа?

Да. Транспорт задаётся как ресурс (единицы и ограничения), а сеть — как плечи с временем/стоимостью и правилами узлов. Поэтому логика переносима на вагоны/составы, баржи/суда, авиа и смешанные мультимодальные цепочки.

Можно начать, если часть правил/данных не формализована?

Да. Часто стартуем с “достаточного минимума” (заявки, парк, окна, базовые правила), добавляем оценки и калибруем на истории, затем итеративно повышаем точность модели.

Какие интеграции возможны?

Обычно начинаем с выгрузок из ERP/1C/Excel, затем автоматизируем обмен через API/таблицы там, где это экономит время.

Хотите обсудить ваш контур перевозок?
Согласуем KPI и ограничения, посчитаем baseline и 2–3 сценария, покажем узкие места и эффект.
Запросить демо Хаб решения →
Made on
Tilda