Неизвестно, где какая машина
Двадцать автовозов выходят из разных городов в разное время. Какой откуда стартует, когда прибудет, чем загружен — всё это держалось в головах логистов и переписках.
Компания перевозит автомобили по России собственным парком: два десятка автовозов выходят из разных точек — от Дальнего Востока до Сибири. По дороге часть машин выгружается, на освободившиеся места берут новые. Обычная воронка такой процесс не описывает вообще.
Последняя цифра — то, чем мы в этом проекте гордимся больше всего. Собственник рекомендовал нас дважды, и оба раза дело дошло до договора. В нашей работе это самый честный показатель результата.
Битрикс24 у компании был: базовую версию настроили маркетологи, которые делали сайт. Работа привычная и выполненная корректно — но она заканчивается там, где начинается логистика.
Двадцать автовозов выходят из разных городов в разное время. Какой откуда стартует, когда прибудет, чем загружен — всё это держалось в головах логистов и переписках.
Автовоз выгружает часть автомобилей в промежуточном городе и догружается новыми. Значит состав перевозки не постоянный, и отследить, что именно едет сейчас, было почти невозможно.
Стоимость доставки одного автомобиля зависит от того, сколько машин ехало вместе с ним и какую часть пути. Вручную такое не посчитаешь, а без этого непонятно, выгоден ли рейс.
Автовоз — дорогой актив. Какой из двадцати зарабатывает, какой простаивает, какой съедает больше, чем приносит, — эти вопросы оставались без ответа.
Оплаты клиентов, топливо, зарплаты водителей, обслуживание техники считались вне системы. Связать конкретный рейс с его финансовым результатом было нельзя.
Сделка с клиентом существовала сама по себе, а реальная перевозка — сама по себе. Ответить клиенту, когда приедет его автомобиль, можно было только позвонив логисту.
В типичной CRM сделка — это путь от заявки до оплаты, и она движется сама по себе. В перевозке автомобилей всё иначе: сделка клиента не существует отдельно от машины, которая её везёт, а машина в один момент времени везёт несколько чужих друг другу заказов.
Одна перевозка — это пересечение трёх сущностей: заказа клиента, конкретного автовоза и участка маршрута. Ни одну из них нельзя описать сделкой.
Добавьте к этому динамику. Автовоз выходит из точки на востоке страны с полной загрузкой. В середине пути три автомобиля выгружаются, и на их места берут новые — те, что ехали не с самого начала. К моменту прибытия состав перевозки может обновиться наполовину.
Значит себестоимость доставки конкретного автомобиля зависит не только от расстояния, но и от того, сколько машин делили с ним рейс на каждом участке. Пока это не посчитано, компания не знает, зарабатывает она на конкретном заказе или везёт его в убыток.
Отсюда и решение: без отдельных сущностей под технику, очередь отправок и маршруты задача не решается. Мы поняли это на этапе разбора и сразу сказали, что типовой настройкой здесь не обойтись.
Каждая сущность отвечает за свою часть картины, а вместе они дают то, чего раньше не было ни в каком виде: связь между заказом клиента, конкретной машиной и деньгами.
Карточка на каждую единицу техники. Здесь собирается всё, что относится к конкретной машине: характеристики, вместимость, история рейсов, расходы на обслуживание и топливо, заработанное за период.
Именно эта сущность позволила считать окупаемость каждого автовоза отдельно — то есть понимать, какой актив работает, а какой требует внимания.
Планирование отправок: какая машина откуда и когда выходит, что в неё загружено, сколько мест свободно. Логист видит очередь целиком и понимает, куда поставить новый заказ, — вместо того чтобы держать это в голове.
Свободные места стали видимым ресурсом. Пустое место в автовозе — это упущенная выручка, и теперь она заметна до отправления, а не после.
Ключевая конструкция проекта. Лист создаётся из сделки и связывает её с конкретным автовозом из очереди, фиксируя весь путь: откуда вышли, где что выгрузили, чем догрузились, куда пришли. На этих данных считается себестоимость и маржинальность перевозки от начала до конца.
Это то самое место, где три сущности сходятся вместе. Без маршрутного листа заказ, машина и деньги остаются тремя не связанными между собой историями.
Отдельные контуры под движение денег. Поступления от клиентов и затраты — топливо, обслуживание, оплата водителям — привязываются к рейсам и машинам. Финансовая картина собирается автоматически, а не сводится в конце месяца вручную.
Работа с клиентом ведётся в одной сквозной воронке: обращение, расчёт, договор, погрузка, перевозка, выдача. Никакого дробления — путь клиента здесь единый, и вся сложность вынесена в смарт-процессы, где ей и место.
Показательный момент: система получилась сложной, но менеджер по-прежнему работает в одной понятной воронке. Сложность нужна там, где считаются деньги, а не там, где человек ведёт клиента.
Главный результат проекта не в порядке, а в цифрах. Компания впервые получила ответ на вопросы, которые до этого решались на глаз.
Общая выручка известна, распределение по рейсам и машинам — нет.
Маршрутный лист связывает заказ, машину и деньги — и даёт разрез по любому из них.
Процессы в этой компании оказались самыми сложными из всех, с чем мы работали. Настроить систему — половина дела; вторая половина в том, чтобы люди начали в ней работать, а не вернулись к переписке с логистами.
Поэтому после запуска три месяца выходили на связь дважды в неделю: смотрели, что не получается, где схема расходится с реальностью, какие действия оказались лишними. Правили и настройки, и порядок работы сотрудников — второе не реже первого.
Такая частота нужна не всегда. Но чем сложнее процессы, тем короче должен быть промежуток между «что-то пошло не так» и разговором об этом. Раз в месяц здесь было бы поздно.
Сколько обращений пришло и на каком этапе каждое. Работа менеджеров видна без опроса.
Понятно, сколько стоит перевозка и как цена соотносится с реальной себестоимостью маршрута.
Какие оплаты ожидаются и какие затраты предстоят. Планирование денег перестало быть догадкой.
По двадцати машинам видно, кто зарабатывает, а кто требует решения — от ремонта до продажи.
Считается из данных системы, а не собирается вручную. Спорных ситуаций стало меньше.
Загрузка, маршрут и состав перевозки видны в любой момент. Ответить клиенту можно, не звоня логисту.
Когда система стала сложной, выяснилась неприятная вещь: она даёт точные цифры только при аккуратном заполнении. Один незакрытый маршрутный лист — и себестоимость рейса посчитана неверно. Десять таких за месяц — и отчётность перестаёт отражать реальность.
Мы рекомендовали собственнику взять отдельного сотрудника на контроль качества — человека, который ежедневно проверяет, как остальные работают в системе. Он его нанял.
Это неудобная для нас рекомендация. Логичнее было бы предложить расширенное сопровождение и взять контроль на себя — за ежемесячную оплату. Но ежедневная проверка чужой работы изнутри компании подрядчику не по силам: нужно знать людей, понимать контекст и быть рядом. Внешний исполнитель этого не заменит, сколько ему ни плати.
Общий вывод, который стоит забрать из этого кейса: чем сложнее система, тем нужнее внутри компании человек, отвечающий за дисциплину данных. Не обязательно отдельная должность — в небольших компаниях это часть работы руководителя. Но роль должна быть названа, иначе цифры в отчётах со временем начнут врать, и никто не заметит, когда именно это началось.
Похожую мысль мы разбирали в кейсе диджитал-агентства, где клиент по тем же причинам взял в штат собственного специалиста по Битрикс24.
Потому что в перевозках заказ клиента и единица техники — разные сущности, которые пересекаются во времени. Одна машина везёт несколько заказов, один заказ может ехать частью пути на одной машине, частью на другой. Воронка описывает движение одной сделки по стадиям и для такой картины не приспособлена. Нужны отдельные сущности: техника, рейс, маршрут — и связи между ними.
Через маршрут, разбитый на участки. Затраты рейса — топливо, оплата водителю, амортизация — распределяются между теми заказами, которые ехали на конкретном отрезке. Автомобиль, проехавший весь путь, берёт на себя большую долю, подсевший в середине — меньшую. Считать это вручную нереально, поэтому и понадобилась отдельная сущность под маршрутный лист.
Чтобы видеть экономику актива, а не только парка целиком. Машина приносит выручку и требует расходов; без отдельной карточки эти суммы смешиваются и решение о ремонте, замене или продаже принимается вслепую. Тот же приём мы применяли для квартир в аренде и техники в сервисе — везде, где в бизнесе есть объект со своей доходностью.
Зависит от сложности. Если система считает деньги на основе того, что вносят сотрудники, кто-то должен следить за полнотой данных — иначе отчёты постепенно расходятся с реальностью. В крупной компании это отдельная роль, в небольшой — часть обязанностей руководителя. Главное, чтобы роль была названа: «за это отвечают все» на практике означает, что не отвечает никто.
В этом проекте активная фаза длилась три месяца при двух встречах в неделю. Правило простое: чем сложнее процессы, тем короче должен быть промежуток между появлением проблемы и разговором о ней. Для простой воронки достаточно встреч раз в неделю в течение месяца. Для системы, где считается себестоимость и связаны несколько сущностей, редкие встречи означают, что ошибки успевают закрепиться привычкой.
Переменную часть — да, если она зависит от показателей, которые уже есть в системе: выполненные сделки, выручка, маржинальность. Это снимает споры, потому что расчёт виден и менеджеру, и руководителю. Полный расчёт заработной платы с налогами и удержаниями остаётся задачей бухгалтерской программы — заменять её не нужно.
Если у вас собственный парк и непонятно, какая машина зарабатывает, а какой заказ выгоден — посмотрим процесс и покажем, что можно посчитать. Встреча на 40 минут, без обязательств продолжать.