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