Манифест из Excel в CRM: как ТЭК Аструм собрала грузы, места и рейсы в одном портале

Как это выглядело в реальной жизни

• Манифест рейса собирался в Excel. У каждого из восьми менеджеров была своя таблица со своими клиентами. Общей картины по рейсу не существовало до момента, пока кто-то не сводил файлы руками.
• Заявка переносилась в таблицу вручную. Клиент присылал заявку, менеджер переносил из неё отправителя, получателя, адреса, количество мест, вид услуги, условия оплаты — десятки полей на каждую отправку.
• Пять документов делались руками в Word. Договор-заявка, счёт, акт, договор и CMR набирались заново по каждой отправке. Реквизиты клиента запрашивались и вбивались снова, даже если этот клиент отправлял груз не первый раз.
• Наклейки печатались по одной. Маркировка мест делалась в отдельном приложении, и каждая наклейка создавалась отдельно. На партию из двадцати мест уходило двадцать одинаковых действий.
• Статус груза выясняли по цепочке. Клиент звонил или писал менеджеру. Менеджер сначала определял, в каком рейсе едет груз, потом смотрел машину по карте, потом перезванивал клиенту.
• Одни и те же данные жили в нескольких местах. Информация о грузах была и у менеджеров, и у руководителей, версии расходились, и на сверку уходило время.

Ни один из этих шагов сам по себе не выглядит проблемой. Проблемой их делает количество: при сотне рейсов в месяц и сотнях грузов ручные операции перестают масштабироваться раньше, чем компания успевает это заметить.

Что стало триггером

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

Сначала в ТЭК Аструм искали партнёра, который закроет задачу, и начали с систем учёта. Компания вышла на iWeb через каталог официальных партнёров МойСклад — iWeb работает с этой системой и указана в нём. Первая консультация была по складскому учёту.

После неё стало понятно, что задача сформулирована не до конца, и iWeb предложила провести подробный аудит процессов. Аудит показал, что узкое место у перевозчика не на складе: время терялось между заявкой, документами и рейсом. Так проект из складского стал внедрением CRM на Битрикс24.

Три сущности вместо одной воронки

Основа всей конструкции — три связанные сущности, каждая со своими полями, стадиями и своим ответственным:

• Груз — отправка клиента: кто отправляет, кому, куда, на каких условиях, сколько стоит. Ведут менеджеры.
• Место — то, что физически лежит на складе: конкретная коробка, мешок или паллета внутри груза. Ведёт склад.
• Рейс — машина с водителем и маршрутом, которая всё это везёт. Ведёт логистика.

Разделение выглядит очевидным на бумаге, но именно оно решает исходную проблему. Менеджер работает со своим грузом и не лезет в машину. Заведующий складом принимает места и не открывает коммерческие условия. Логист собирает рейс из готовых грузов. При этом все трое смотрят в одну базу, и данные не расходятся.

Груз: заявка, деньги и документы в одной карточке

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

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

Место: складской учёт и этикетки на термопринтер

Место — это отдельная запись на каждую физическую единицу внутри груза. У неё свой номер, свой склад, свой адрес доставки и свой ответственный. Заведующий складом принимает и отгружает именно места, а не абстрактный груз, поэтому расхождение «отправили двенадцать, приехало одиннадцать» видно на конкретной строке, а не на уровне всей отправки.

К местам iWeb сделала печать складских этикеток прямо из портала — на термопринтер, формат 60 × 60 мм. На этикетку выводятся склад, компания-клиент, ответственный менеджер, количество мест, адрес доставки, вид услуги и телефон. Нумерация идёт в формате «3 из 12»: числитель на каждой этикетке свой, знаменатель подставляется из карточки. Кладовщик задаёт нужное количество и печатает партию одним заданием вместо двадцати отдельных действий в стороннем приложении.

Рейс: машина, водитель, маршрут

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

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

Пять документов одним нажатием

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

• договор-заявка на перевозку
• счёт на оплату
• акт выполненных работ
• договор
• международная товарно-транспортная накладная CMR

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

CMR — отдельная история: накладную не рисовали заново, а взяли исходный бланк клиента и встроили поля прямо в него. Международный документ остался тем же самым, только заполняется теперь из портала.

Манифест рейса

Манифест — список всех грузов, которые едут в конкретном рейсе. Раньше он собирался в Excel из таблиц восьми менеджеров. Сейчас это настроенное представление списка грузов внутри портала: те же колонки, что были в таблице, но данные берутся из карточек и обновляются сами. Отдельную систему под манифест не делали — она не нужна, потому что манифест это и есть список грузов, а не самостоятельный объект.

Отслеживание груза на сайте

На сайте компании работает отслеживание по трек-коду. Клиент вводит код своей отправки и видит статус груза и точку машины на карте, не звоня менеджеру. Данные о положении машины приходят из мобильного приложения водителя и попадают в карточку рейса, а с неё — на публичную страницу.

Это единственный модуль, который работает на людей вне компании, и он же сильнее всего разгружает менеджеров: типовой вопрос «где мой груз» клиент закрывает сам.

Мобильное приложение

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

BI-аналитика

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

Документ печатался пустым и не выдавал ошибки

Самая дорогая по времени находка. Шаблоны документов в Битрикс24 подставляют значения по кодам полей, и код можно записать в двух похожих формах. Одна из них — та, что выглядит логичнее и совпадает с тем, как поле называется в настройках, — не работает. При этом генератор не показывает ни ошибки, ни предупреждения: документ собирается, открывается, выглядит нормально, и просто в нём пустые строки там, где должны быть данные.

Пока это не выяснилось опытным путём, каждый неудачный шаблон выглядел как проблема самого поля, а не его записи. После того как формат подтвердили, все пять документов перебрали и привели к одной записи. Вывод простой: печатные формы в Битрикс24 нельзя принимать по факту «сгенерировалось» — их надо проверять по каждому полю на реальной, а не тестовой карточке.

Печать и подпись не появлялись на счёте

Факсимиле в Битрикс24 требует трёх условий одновременно, и отсутствие любого из них даёт один и тот же результат — пустое место на бумаге. Картинки подписи и печати должны быть загружены и в реквизиты компании, и в саму карточку компании. В шаблоне место под них размечается не текстовым кодом, а самой картинкой-заглушкой, у которой код прописан в описании изображения. И при генерации должна быть включена галка «Печать и подпись».

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

Поле, которое нельзя переименовывать

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

Сто страниц этикеток ради одной

Термопринтер печатает страницу 60 × 60 мм, и стандартная печатная форма под такой формат не рассчитана. Задача звучала просто: кладовщик указывает количество мест и получает ровно столько этикеток, пронумерованных «1 из 12», «2 из 12» и так далее.

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

Люди, а не система

Технически портал был готов раньше, чем им начали пользоваться все. Часть менеджеров подключилась к обучению позже остальных, поэтому переход на новый процесс растянулся: какое-то время часть работы по привычке шла в старых таблицах. iWeb начала обучение со второго месяца внедрения, не дожидаясь готовности всех модулей, — и это правильный порядок. Учить людей после сдачи всей системы дольше, чем по мере её появления.