Статья

Операционная система перевозчика: как превратить фрагментированный транспортный бизнес в единую систему

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

В жизни почти каждого растущего перевозчика наступает определённый момент.

Сначала всё просто.

У собственника несколько машин. Он лично знает водителей. Он знает, где находятся автомобили. Он знает, какой клиент ждёт груз. Он примерно представляет, сколько стоит топливо и когда машине нужно на сервис.

Потом бизнес растёт.

Десять машин.

Тридцать.

Пятьдесят.

И внезапно собственник перестаёт видеть сам бизнес. Он видит его фрагменты. Заявки — в одном месте. Машины — в другом. Документы — где-то ещё. Топливо учитывается отдельно. У техобслуживания своя история. У шин своя. Лизинговые платежи живут в бухгалтерии. GPS выдаёт ещё один поток информации.

А в конце месяца возникает знакомый вопрос:

Через компанию прошли миллионы рублей. А сколько мы на самом деле заработали?

Именно эту проблему мы и решаем.

Мы строим операционную платформу перевозчика — систему, которая сводит коммерческую, операционную, парковую и экономическую стороны транспортного бизнеса в одну связную модель.

Её задача — не просто автоматизировать отдельные задачи.

Её задача — помочь перевозчику понимать и вести бизнес как единое целое.

Перевозчик — это один бизнес, а не десять программных модулей

Сегодня перевозчик может использовать одну систему для поиска грузов, другую — для GPS, третью — для электронных документов, бухгалтерскую программу — для денег, электронные таблицы — для расходов автопарка, мессенджеры — для повседневной координации.

Каждый инструмент сам по себе может работать прекрасно.

Проблема возникает между ними.

Заявка становится рейсом.

Рейс использует конкретную машину.

Машина расходует топливо.

Водитель выполняет рейс.

Автомобиль накапливает километры.

Километры создают износ.

Износ создаёт техобслуживание.

Техобслуживание создаёт расходы и простои.

Рейс создаёт выручку.

Выручка и расходы вместе создают маржу.

Клиент в итоге платит.

Все эти события — части одной экономической истории.

Но перевозчик часто воспринимает их как разрозненные куски информации.

Наш подход начинается с другого принципа:

Программное обеспечение должно сначала отражать бизнес, и только потом — отдельные функции.

Это применение нашего общего подхода к проектированию предприятий на транспортной отрасли.

Вместо вопроса:

«Какие модули нужны транспортной компании?»

мы задаём другой вопрос:

«Что на самом деле существует в бизнесе, как эти вещи связаны между собой и как бизнес создаёт экономическую ценность?»

Ответ на этот вопрос даёт структуру продукта.

Начинаем с реальности предприятия

У перевозчика есть:

  • предприятие;
  • люди;
  • роли;
  • автомобили;
  • полуприцепы;
  • клиенты;
  • поставщики;
  • грузы;
  • заказы;
  • маршруты;
  • рейсы;
  • водители;
  • объекты инфраструктуры;
  • документы;
  • топливо;
  • шины;
  • техобслуживание;
  • страхование;
  • финансирование;
  • расходы;
  • выручка;
  • платежи;
  • операционные события;
  • риски;
  • провозная способность.

Это не просто таблицы в базе данных.

Это реальные объекты, из которых состоит бизнес.

И они связаны между собой.

Компания владеет машинами.

Компания нанимает людей.

Водитель управляет автомобилем.

Клиент создаёт заказ.

Заказ касается груза.

Заказ превращается в рейс.

Рейс использует машину и водителя.

Рейс следует по маршруту.

Рейс создаёт километры.

Километры создают операционные расходы.

Рейс создаёт выручку.

Выручка минус расходы даёт экономический результат.

Как только эти связи выражены явно, происходит важная вещь. Система перестаёт быть набором экранов.

Она становится моделью бизнеса перевозчика.

Центральный объект: рейс

В перевозках много важного.

Но операционно всё сходится в одной точке:

в рейсе.

Рейс связывает:

Заказ → Груз → Машину → Водителя → Маршрут → Документы → Исполнение → Расходы → Выручку → Маржу

До рейса у нас есть план.

Во время рейса мы собираем факты.

После рейса мы знаем результат.

Так у платформы появляется естественный операционный жизненный цикл:

Возможность → Найден груз → Создан заказ → Заказ принят → Рейс запланирован → Машина назначена → Водитель назначен → Документы подготовлены → Погрузка → В пути → Выгрузка → Документы закрыты → Рейс завершён → Взаиморасчёты → Платёж

Но параллельно этому операционному циклу идёт второй — экономический:

Плановая экономика → Фактические километры → Фактическое топливо → Фактические расходы → Фактическая себестоимость → Выручка → Маржа → Отклонение от плана → Обучение

Именно этот второй цикл и делает систему принципиально другой.

Платформа знает не только что произошло.

Она знает, что произошло экономически.

Экономический жизненный цикл рейса
Операционный контур
Заявка найденаЗаказ созданЗаказ принятРейс запланированМашина назначенаВодитель назначенДокументы подготовленыПогрузкаВ путиВыгрузкаДокументы закрытыРейс завершён
Экономический контур
Плановые километрыФактические километрыФактическое топливоФактические расходыСебестоимостьВыручкаМаржаОтклонение от планаОбратная связь

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

У автомобиля своя жизнь

Перевозчик управляет не только рейсами.

Он управляет активами.

И эти активы поглощают огромные деньги.

У грузовика есть:

  • стоимость приобретения или лизинга;
  • топливо;
  • шины;
  • техобслуживание;
  • ремонты;
  • запчасти;
  • страхование;
  • амортизация;
  • простои;
  • расходы на водителя.

Поэтому управление автопарком нельзя сводить к отдельной GPS-функции.

Мы хотим напрямую связывать управление парком с экономикой перевозок.

У машины есть история.

Она накапливает километры.

Она расходует топливо.

Она изнашивает шины.

Она входит в эксплуатацию.

Она выходит из эксплуатации.

Она переживает отказы.

Она простаивает.

Она выполняет прибыльные и убыточные рейсы.

Её экономические показатели меняются во времени.

Платформа должна сохранять всю эту историю целиком.

Значит, управляющий парком может спросить не только:

«Где сейчас машина 184?»

но и:

«Сколько мне стоит километр на машине 184, почему он стоит именно столько и здорова ли её экономика прямо сейчас?»

Это гораздо более сильный вопрос.

Километр становится мостом между операциями и экономикой

Здесь наш подход приводит к одной важной идее.

Грузовик — это производственный актив.

Рейс — это производственная операция.

Но километр — это фундаментальная экономическая единица перемещения.

Каждый километр несёт в себе комбинацию:

  • стоимости топлива;
  • стоимости шин;
  • стоимости техобслуживания;
  • стоимости финансирования;
  • амортизации;
  • стоимости водителя;
  • страхования;
  • дорожных расходов;
  • накладных;
  • прочих операционных расходов.

Поэтому платформа должна уметь строить реальную себестоимость перемещения.

Не просто:

Топливо: 34 000 ₽

а:

Сколько на самом деле стоили эти 820 километров рейса?

И не только для одного рейса.

Для машины.

Для маршрута.

Для клиента.

Для типа груза.

Для месяца.

Для всего парка.

Это превращает платформу из инструмента управления перевозками в систему экономического управления перевозчиком.

Система одновременно следит за деньгами и за машиной

Представим, что перевозчик получил заказ Москва — Санкт-Петербург.

Система создаёт рейс.

Подбирается подходящая машина.

Назначается водитель.

Планируется маршрут.

Рассчитывается ожидаемый пробег.

Оценивается ожидаемый расход топлива.

Учитывается текущее состояние автомобиля.

Считается ожидаемая себестоимость.

Ожидаемая выручка уже известна.

Поэтому ещё до того, как машина тронется, перевозчик видит экономическую картину.

Затем рейс начинается.

Приходят фактические километры.

Приходят операции по топливу.

GPS даёт данные о перемещении.

Закрываются документы.

Появляются дополнительные расходы.

Возможно, возникает время ожидания.

Возможно, машина идёт в объезд.

Возможно, обратный рейс будет пустым.

Возможно, после рейса потребуется незапланированный ремонт.

Система записывает эти факты против одного и того же объекта.

Когда рейс закрывается, перевозчик получает не набор несвязанных отчётов.

Он получает экономическую историю рейса.

План против факта.

И эта разница становится ценной информацией.

Что произошло с километром?

Это один из тех вопросов, на которые платформа должна отвечать непрерывно.

Предположим, две машины прошли один и тот же маршрут.

Выручка у них почти одинаковая.

Но одна дала заметно больше маржи.

Почему?

Возможно, она израсходовала меньше топлива.

Возможно, у её шин была лучше экономика.

Возможно, у неё ниже расходы на техобслуживание.

Возможно, у неё меньше порожних километров.

Возможно, она меньше времени провела в ожидании.

Возможно, меньше финансовая нагрузка.

Возможно, водитель работал иначе.

Возможно, машина просто лучше подходила под этот маршрут.

Система не должна заставлять менеджера открывать пять разных отчётов, чтобы разобраться вручную.

Связи должны уже существовать.

В этом и заключается практическая ценность базовой модели.

Платформа создаёт единую экономическую историю

Одна из главных идей системы — информация не должна исчезать в ведомственных «колодцах».

Операция по топливу должна быть привязана к машине.

Машина должна быть привязана к своим рейсам.

Рейсы должны быть привязаны к своим километрам.

Километры должны быть привязаны к выручке и расходам.

Событие техобслуживания должно быть привязано к машине.

Простой машины должен влиять на её операционную доступность.

Доступность должна влиять на её способность выполнять рейсы.

Рейсы должны влиять на выручку компании.

Выручка в итоге должна встречаться с расходами.

Так платформа создаёт непрерывную цепочку:

Предприятие → Автопарк → Машина → Рейс → Километр → Расход → Выручка → Маржа

Эта цепочка — экономический каркас системы.

Техобслуживание становится частью управления бизнесом

Простой пример.

У машины было техобслуживание на 85 000 ₽.

Традиционная программа для автопарка просто фиксирует событие.

Наша система должна идти дальше.

Она знает:

  • какая машина прошла обслуживание;
  • что именно ремонтировалось;
  • сколько километров машина прошла к этому моменту;
  • какие узлы были заменены;
  • сколько составил простой;
  • какие рейсы были затронуты;
  • какой была себестоимость километра до этого события;
  • какой она стала после.

Со временем компания накапливает собственное операционное знание.

Она может обнаружить, что у конкретной машины необычно высокие расходы на обслуживание.

Или что конкретный узел выходит из строя раньше ожидаемого.

Или что плановое обслуживание дешевле повторяющихся аварийных ремонтов.

Или что после определённого пробега машина становится экономически невыгодной.

Платформа не обязана диктовать ответ.

Она делает связь видимой.

Шины становятся экономикой

Тот же принцип работает и для шин.

Шина — это не просто складская позиция.

У неё есть:

Цена покупки → Установка → Пробег → Износ → Замена → Себестоимость километра

Это законченный экономический жизненный цикл.

Поэтому платформа может отвечать на такие вопросы:

  • какие шины дают наименьшую себестоимость километра?
  • какие машины «съедают» шины быстрее?
  • как тип маршрута влияет на срок службы шин?
  • сколько шины внесли в себестоимость машины за год?
  • какие практики обслуживания продлевают жизнь шин?

Важен не отдельный отчёт.

Важна связь между событиями.

Топливо становится интеллектом

С топливом та же логика.

Система знает:

  • машину;
  • дату;
  • место;
  • количество топлива;
  • цену;
  • пробег;
  • маршрут;
  • загрузку;
  • водителя;
  • условия работы.

Со временем это складывается в реальную операционную картину.

Перевозчик может сравнить фактический расход с ожидаемым.

И, что важнее, топливо становится частью полного расчёта себестоимости километра.

Вопрос перестаёт звучать так:

«Сколько мы потратили на топливо?»

Он звучит так:

«Как топливо повлияло на экономику наших перевозок?»

Система понимает и постоянные расходы

Лизинг — ещё один пример.

Ежемесячный лизинговый платёж никуда не исчезает, даже если машина стоит.

Поэтому использование имеет значение.

Если машина проходит слишком мало экономически полезных километров, постоянные расходы распределяются на меньший объём производства.

Именно поэтому платформе необходимо связывать:

Лизинг → Машину → Доступность → Пробег → Рейсы → Выручку → Себестоимость километра

Тот же принцип применим к страхованию и другим постоянным или условно-постоянным расходам.

В результате возникает гораздо более реалистичная картина экономики актива.

Перевозчик наконец видит всю машину целиком

Когда эти связи соединяются, у собственника появляется возможность задавать вопросы, на которые раньше было трудно ответить.

Какая машина на самом деле прибыльна?

Какая лишь создаёт выручку?

Какой маршрут даёт хорошую маржу?

Какой клиент выглядит привлекательным по выручке, но слаб экономически?

Сколько нам стоит порожний пробег?

Какой эффект даёт простой?

Какую долю в себестоимость километра вносит техобслуживание?

Сколько километров эта машина должна экономически проходить в месяц?

В какие машины стоит вкладывать деньги?

Какие пора менять?

Какие грузы стоит брать?

А от каких — отказываться?

Платформа превращает эти вопросы в нормальные управленческие вопросы.

Здесь наш подход становится видимым в продукте

Применение нашей методологии проектирования предприятий — это не то, что клиент обязан видеть.

Ему не нужно знать, что мы начали с проектирования онтологии.

Он просто чувствует последствия.

Он видит один бизнес.

Он видит одну операционную историю.

Он видит согласованные связи.

Он вводит информацию один раз.

Он находит её там, где она логически находится.

Он может двигаться по цепочке:

Клиент → Заказ → Рейс → Машина → Себестоимость → Маржа

не теряя контекста.

Он может двигаться по цепочке:

Машина → Техобслуживание → Пробег → Себестоимость

не восстанавливая историю вручную.

Он может двигаться по цепочке:

Расход → Машина → Рейс → Клиент

и понимать, куда ушли деньги.

Эта связность и есть продукт.

От модулей к системе

Традиционное проектирование ПО часто начинается с модулей:

Автопарк.

Заказы.

Бухгалтерия.

GPS.

Техобслуживание.

Документы.

Аналитика.

Каждый модуль затем развивает свои данные и свои процессы.

Наш подход начинается с предприятия.

Модули вырастают вокруг связей.

Это даёт другую архитектуру.

Та же машина — это не «объект автопарка» в одном месте и «объект бухгалтерии» в другом.

Это одна и та же машина.

Тот же рейс — это не один объект в диспетчерской и другой в финансах.

Это один и тот же рейс.

Тот же расход — это не просто финансовая операция.

Это факт об операционной деятельности предприятия.

Это звучит как техническое различие.

На практике оно создаёт нечто гораздо более важное:

одну версию реальности.

Один перевозчик. Одна модель.

Перевозчику с тремя машинами и перевозчику с семьюстами не нужны принципиально разные бизнес-модели.

У них разный масштаб.

В компании с тремя машинами один человек выполняет пять ролей.

В компании с семьюстами машинами сотни сотрудников выполняют специализированные роли.

Но в основе лежат одни и те же объекты.

Одни и те же связи.

Одна и та же экономическая логика.

Именно поэтому наша система может расти вместе с перевозчиком.

На трёх машинах собственник может работать в ней сам.

На тридцати появляются отдельные пользователи — диспетчеры и механики.

На трёхстах возникают подразделения и региональные структуры.

На семистах руководству нужна консолидированная аналитика.

Но базовая модель остаётся неизменной.

Система должна делать сложность управляемой, а не прятать её

Транспорт по своей природе сложен.

Слишком много переменных, чтобы их устранить.

Цель не в том, чтобы делать вид, будто бизнес прост.

Цель — упорядочить его сложность.

Поэтому мы разделяем пять уровней:

Operate — Оперировать

Вести компанию.

Управлять клиентами, грузами, заказами, машинами, водителями, рейсами, документами и платежами.

Maintain — Поддерживать

Держать производственные активы в форме.

Управлять топливом, шинами, техобслуживанием, ремонтами, страхованием, лизингом и доступностью.

Understand — Понимать

Видеть, что происходит.

Понимать расходы, маржу, пробег, загрузку, простои, клиентов и маршруты.

Decide — Решать

Выбирать, что делать дальше.

Какой груз взять.

Какую машину назначить.

Когда провести сервис.

Где искать обратный рейс.

Где бизнес теряет деньги.

Learn — Учиться

Использовать историю.

Сравнивать план и факт.

Понимать закономерности.

Улучшать будущие решения.

Это не отдельные продукты.

Это разные уровни одной операционной системы.

И со временем система начинает думать вместе с перевозчиком

Когда у компании появляется структурированная история, искусственный интеллект становится гораздо полезнее.

AI уже не смотрит в пустой диалог.

Он понимает предприятие.

Он знает машины.

Он знает их историю.

Он знает маршруты.

Он знает расходы.

Он знает клиентов.

Он знает завершённые рейсы.

Он знает текущее операционное состояние.

И тогда разговор становится практическим.

«Брать ли этот рейс Москва — Санкт-Петербург?»

Система может ответить:

Выручка — 180 000 ₽.

Ожидаемый общий пробег — 820 км.

Ожидаемый порожний пробег — 120 км.

Машина 24 показывает повышенный расход топлива на этом маршруте.

До планового ТО — 1 200 км.

Ожидаемая себестоимость рейса — 112 000 ₽.

Ожидаемая маржа — 68 000 ₽.

У двух альтернативных машин исторически ниже себестоимость километра.

Теперь AI не выдаёт общие советы.

Он рассуждает в рамках реальной операционной модели перевозчика.

Но интеллект приходит после дисциплины

Мы намеренно не начинаем с AI.

Мы начинаем с реальности.

Сначала:

Что существует?

Потом:

Как это связано?

Потом:

Что происходит?

Потом:

Сколько это стоит?

Потом:

Что произошло в реальности?

Потом:

Чему мы можем научиться?

И только затем:

Что делать дальше?

Этот порядок важен.

Хороший интеллект требует хорошей памяти.

Хорошая память требует структурированных операций.

Структурированные операции требуют согласованной модели предприятия.

Поэтому первый продукт гораздо проще финального замысла

Нам не нужно решать весь транспортный рынок в первый день.

Первая версия может делать нечто очень ценное.

Перевозчик создаёт свою компанию.

Добавляет автопарк.

Добавляет водителей.

Подключает источники заявок.

Создаёт и ведёт заказы.

Превращает заказы в рейсы.

Планирует и выполняет рейсы.

Управляет документами.

Фиксирует топливо и расходы.

Отслеживает техобслуживание и шины.

Фиксирует выручку и платежи.

И в конце:

видит реальную экономику бизнеса.

Особенно экономику машины.

Особенно экономику километра.

Этого достаточно, чтобы создать фундамент.

От одного перевозчика — к сети

Долгосрочная возможность начинается после того, как организован отдельный перевозчик.

Представим тысячи независимых перевозчиков. Каждый работает сам по себе. Но каждый производит структурированные операционные данные.

Со временем платформа сможет видеть закономерности, которые не увидит ни один отдельный перевозчик.

Где доступна провозная способность.

Где накапливается порожний пробег.

Какие маршруты дорожают.

Где растёт спрос.

Как меняется фактическая себестоимость.

Какие направления стабильно привлекательны.

Где возникают задержки.

Где провозной способности структурно не хватает.

Это не требует централизации перевозчиков.

Скорее наоборот.

Перевозчики остаются независимыми.

Но у отрасли появляется цифровой слой, через который её распределённая активность становится более видимой.

От программного обеспечения — к промышленной инфраструктуре

Это и есть то, что мы в итоге строим.

Не очередное приложение для диспетчеров.

Не ещё одну GPS-систему.

Не просто ещё один TMS.

Не ещё одну биржу.

Мы строим операционный слой для предприятия-перевозчика.

Слой, который связывает:

Рынок → Коммерческую возможность → Заказ → Рейс → Машину → Водителя → Маршрут → Документы → Километры → Топливо → Шины → Техобслуживание → Финансирование → Себестоимость → Выручку → Маржу → Решение → Обучение

Это перевозчик как связная система.

Более крупная идея

За этим продуктом стоит нечто большее.

У небольших перевозчиков уже есть машины.

У них уже есть водители.

У них уже есть опыт.

У них уже есть отношения с клиентами.

У них уже накоплены огромные объёмы операционного знания.

Чего многим из них не хватает — это системы, которая сводит эти ресурсы в ясную операционную модель.

Мы хотим дать им такую модель.

Чтобы компания с тремя машинами могла работать с дисциплиной и прозрачностью куда более крупной организации.

Чтобы компания с тридцатью машинами могла масштабироваться, не теряя контроля.

Чтобы компания с семьюстами машинами могла управлять сложностью, не дробя операционное знание.

И чтобы со временем накопленная операционная история множества независимых перевозчиков создала новый слой интеллекта для отрасли.

Обещание

Обещание звучит не так:

«Мы дадим вам больше программного обеспечения.»

Оно звучит так:

Мы поможем вам увидеть и вести транспортный бизнес как единую систему.

Вы будете знать, где ваши машины.

Что они делают.

Сколько они стоят.

Сколько они зарабатывают.

Что даёт каждый рейс.

Сколько стоит каждый километр.

Где теряются деньги.

Где деньги зарабатываются.

И, всё чаще, какое решение должно быть следующим.

Потому что в конечном счёте бизнес перевозчика — это не перемещение грузовиков по карте.

Это преобразование:

машины + люди + километры + капитал + топливо + время

в:

надёжные перевозки и устойчивую экономическую ценность.

Именно такую систему мы строим.

И идея в её основе удивительно проста:

Перевозчик выигрывает, когда способен стабильно производить перевозку по себестоимости, оставляющей место для здоровой маржи.

Наша задача — сделать эту экономику видимой, управляемой и постепенно — всё более интеллектуальной.

Три машины или семьсот.
Одно предприятие.
Одна операционная модель.
Одна экономическая история.
Одна система.

Операционная система перевозчика: как превратить фрагментированный транспортный бизнес в единую систему