Несколько лет назад я создал кампанию ко Дню всех святых, которой действительно гордился. Образовательный контент, завязанный на персонажах, призраках и ведьмах, полный набор ассетов, созданный моей командой. Она провалилась. Аудитории было все равно, насколько это креативно. Они хотели получить информацию в простом виде, и все, что я построил вокруг этого, только мешало.
Отсюда и родилось правило, которым я руководствуюсь до сих пор. Простота лучше изощренности. Корпоративное ПО для доставки — это категория с очень изощренной историей, и эта история заслоняет собой более полезную.
Изощренная история звучит примерно так. Ваша платформа устарела, наша — современна, и граница между ними проходит там, где работает программное обеспечение. Аккуратно, запоминающеся и в основном неверно.
К слову, ваша платформа, вероятнее всего, в полном порядке. Она справилась с прошлым пиком нагрузки, что является реальным доказательством, а не пустым звуком. Но она также была выбрана пять лет назад, а способность справляться с уже знакомыми объемами — это совсем не то же самое, с чем столкнетесь при обработке чего-то нового. Далее следует четкая версия этого сравнения, включая те моменты, которые нас не красят.
Что такое корпоративное программное обеспечение для доставки?
Корпоративное ПО для доставки — это мультимодальная платформа (multi-carrier), управляющая процессами обработки больших объемов посылок из единой системы, охватывающая тарификацию, генерацию этикеток, выбор перевозчика, отслеживание и отчетность на множестве складов, каналов продаж и контрактов с перевозчиками. В масштабах предприятия покупатели различают эти платформы не столько по количеству функций, сколько по тому, кто владеет интеграциями с перевозчиками и как быстро изменения попадают в продакшн.
Вы и так знали большую часть этого. Второе предложение стоит того, чтобы его озвучить, потому что именно вокруг него в этой категории ведутся ожесточенные споры. Каждый вендор здесь продает многоперевозчиковое ПО для доставки, так что это перестало быть отличительной чертой много лет назад.
Вопрос, который задают все, и лучший вопрос, скрывающийся за ним
Процесс покупки обычно начинается с того, где работает софт. На принадлежащих вам серверах или в виде облачного сервиса, к которому вы подключаетесь. Это преподносится как предпочтение ИТ-отдела, вопрос безопасности или статья расходов, за которую никто в операционном отделе не отвечал.
То, что вы чувствуете на самом деле, проявляется в определенные дни. Перевозчик меняет спецификацию этикетки. Или выпускает новый уровень сервиса, который вы хотите протестировать. Или региональный перевозчик становится выгодным для добавления в одну зону в течение шестинедельного периода. Или ваш объем утраивается по причинам, которые ваш летний прогноз не предвидел.
В такие дни вопрос заключается вовсе не в том, где работает ваше ПО для доставки. Вопрос в том, сколько времени требуется вам, чтобы изменить свое мнение, и кого для этого нужно привлечь.
Развертывание — это лишь один из факторов, причем меньший, чем вам будут говорить вендоры с любой стороны. Позвольте мне внести ясность в то, что есть что, поскольку небрежная версия этого сравнения встречается повсеместно, и опытный покупатель видит ее насквозь.
Что на самом деле определяет модель развертывания
Четыре строки. Честно говоря, это большая часть сути, и обратите внимание, что одна из четырех относится к локальной (self-hosted) системе. Если вашему складу нужно продолжать печать этикеток при сбое связи, локальная система — это реальное решение, а облачная платформа — это зависимость.
Чего развертывание не определяет, хотя покупатели продолжают приписывать это
Здесь большинство сравнений вендоров грешат неточностями, включая мои собственные, пока кто-то меня на этом не поймал.
Каждая строка из второй таблицы существует в обеих моделях развертывания. Локальная платформа может поставлять управляемые вендором обновления перевозчиков в рамках бессрочной схемы релизов (versionless release train). Облачная платформа все равно может поместить ваше изменение за тикет и календарь релизов. ProShip, если взять доминирующее решение, которым реально пользуется большинство крупных корпоративных покупателей, предлагает локальное (on-premises), облачное и гибридное развертывание с автоматическими обновлениями. Так что аргумент «мы в облаке, а они нет» не работает, и если вы недавно слышали его от вендора, включая нас самих, не принимайте его в расчет.
То, что остается, более узко и полезно. Управляемый мультимодальный слой, представляющий собой единый API доставки, переносит работу по интеграции с перевозчиками с вашей команды и превращает активацию уже поддерживаемого перевозчика в настройку вместо программирования. Это реальное преимущество, которое стоит денег. Это преимущество продукта и масштаба, а не следствие того, где что-то размещено.
Два аспекта, где это проявляется. Более 100 перевозчиков за одним подключением важны не столько из-за самого числа, сколько из-за того, как это влияет на стоимость тестирования одного из них, потому что тариф, до которого вы не можете дотянуться, — это не ваш тариф. И выбор перевозчика может либо применять правила, написанные кем-то в прошлом году, либо заново определять для каждого отправления текущую стоимость, скорость и надежность, что и делает Luma AI Select. И то, и другое — продуктовые решения. Требуйте от любого вендора продемонстрировать их, а не просто заявлять о них.
Строка, с которой я бы начал
Кто может изменить правило маршрутизации и что должно произойти в первую очередь.
Не потому, что контроль изменений — это плохо. При ваших объемах позволять кому-либо перенаправлять производственный трафик без надзора — это риск, а не функция. Но эта строка показывает ваше реальное время цикла, а время цикла определяет, является ли стратегия в отношении перевозчиков тем, чем вы управляете, или чем-то, что вы описываете в презентации.
Спросите руководителя операционного отдела, сколько рабочих дней проходит между принятием решения о добавлении перевозчика и печатью первой реальной этикетки, и большинству придется это выяснять. Вот это действительно интересная часть.
Как корпоративное ПО для доставки справляется с пиковым сезоном?
Пиковый сезон — это момент, когда строка с ресурсами перестает быть теоретической, потому что емкость, которую вы купили заранее, — это емкость, которую вы рассчитали еще в июле.
EasyPost поддерживал 99,99% времени безотказной работы (uptime) на протяжении нескольких пиковых сезонов подряд, а в 2020 году выдержал 600-процентный всплеск ежедневных объемов доставки для крупнейшего ритейлера в мире. Стоит четко понимать, что это доказывает, а что нет. Это свидетельство пропускной способности инфраструктуры под нагрузкой. Это не свидетельство того, как быстро кто-либо может добавить перевозчика.
Более сложная проблема заключается в том, что большинство операций не знают, как их собственная конфигурация ведет себя под стрессом, потому что никто не проводил тесты. Согласно индексу готовности к пиковым нагрузкам EasyPost за июль 2026 года, у 67% грузоотправителей не было проверенного ответа на внезапное повышение тарифов перевозчика или сокращение пропускной способности. План на случай непредвиденных обстоятельств, который никто никогда не тестировал, — это просто макулатура.
Во сколько обходится стареющая платформа до того, как она выйдет из строя
Видимая стоимость старой платформы — это простой системы. То, чего никто не оценивает, — это каждый обычный месяц между ними, пока все согласны с тем, что все в порядке.
Zenni Optical — отличный пример здесь, с двумя оговорками: это меньший масштаб операций, чем у вас, и их предыдущая настройка представляла собой систему для каждого отдельного рабочего места, а не то, что они называют локальной системой, поэтому воспринимайте это как историю об устаревшей платформе, а не об архитектуре. Эта система выходила из строя примерно два-три раза в год, иногда на полдня. При 12 часах простоя и 30 бездействующих сотрудниках они оценивали каждый инцидент примерно в 5400 долларов. После перехода на API EasyPost внедрение сэкономило им в среднем два часа в день на каждую смену. «Время безотказной работы критически важно», — говорит Саймон Го (Simon Goh), директор по дистрибуции и объектам компании Zenni.
Простой получил свою денежную оценку, потому что простои всегда их получают. А два часа за смену — нет, потому что это не выглядело как проблема. Это выглядело как издержки ведения бизнеса. Масштабируйте эту ситуацию на ваши объемы, и неоцененная половина обычно окажется больше.
Когда локальный хостинг (self-hosted) по-прежнему остается правильным выбором?
Иногда это так, и тот поставщик, который утверждает обратное, просто пытается вам что-то продать.
Вот три случая, когда я бы сохранил его. Если маркировка должна продолжать работать, когда ваше соединение падает, то это ситуация обрыва сети, и она является решающей. Если ваша логика доставки тесно связана с локальной WMS или ERP, в которую вложено десятилетие кастомных доработок, стоимость миграции реальна и может не окупиться. И если вы работаете в условиях требований, определяющих физическое размещение систем и данных, это ограничение не подлежит обсуждению никем из маркетингового отдела.
Вопрос в том, описывает ли одно из этих трех условий вашу работу сейчас или оно описывало ее в день покупки.
И если вы переросли эту систему, логичным продолжением будет вопрос о том, что меняет затраты. Я не собираюсь указывать временные рамки в блоге, и вам стоит с подозрением относиться к любому, кто это делает. Честная оценка зависит от четырех факторов: насколько плотно ваша логика доставки интегрирована в вашу WMS или ERP, переносятся ли вместе с вами ваши согласованные контракты с перевозчиками, можете ли вы запускать обе системы параллельно в пиковый период и чего требуют ваша собственная проверка безопасности и регламент перехода. Эти ответы и есть ваша оценка. Средние показатели от вендора — нет.
Пять вопросов, измеряющих скорость изменений
Скорость изменений — это то, насколько быстро ваша операция может реализовать новое решение по доставке. Засеките время для своих ответов. Ни один из этих вопросов не предполагает, что узким местом является ваша архитектура, и в этом суть: они показывают, где оно находится на самом деле.
- Сколько рабочих дней проходит между решением «нам нужно добавить этого перевозчика» и появлением реальной этикетки? Считайте с момента принятия решения, а не со дня, когда разработчики взяли задачу в работу.
- Из этих дней сколько ушло на софт, а сколько — на заключение договоров, согласование тарифов, организацию забора грузов или подготовку площадки?
- Когда перевозчик в последний раз менял спецификацию этикетки, кто написал исправление и как оно попало в продакшн?
- Если объем вырастет втрое в следующий вторник, что сломается первым? Вы знаете это или предполагаете?
- Когда кто-либо в последний раз пересматривал само решение о выборе платформы, а не отдельный запрос на функцию внутри нее?
Второй вопрос — это то, что вас удивит. Многие команды обнаруживают, что их программное обеспечение никогда не было слабым звеном, и это действительно полезно выяснить до подписания каких-либо документов.
Никто не планирует эту проверку заранее, поэтому ее обычно навязывают вам в середине декабря, на глазах у всех. У тренера Рассела была идея получше. Проведите тренировку во время тайм-аута, пока это еще просто неловко.
Основные выводы
- Тип развертывания определяет, кто выделяет мощности, кто устанавливает патчи на серверы, где хранятся данные и выживет ли маркировка при сбое сети. Это не определяет, кто владеет вашими интеграциями с перевозчиками.
- Доступ к тарифам, логика выбора, управление изменениями и заявленное время безотказной работы — это продуктовые, коммерческие и организационные решения. Все четыре существуют как в локальных (self-hosted), так и в облачных платформах.
- Управляемый многофункциональный уровень перевозчиков избавляет вашу команду от работы по интеграции и превращает добавление поддерживаемого перевозчика в простую настройку. Это преимущество в объеме работ, а не в архитектуре.
- Прежде чем оценивать платформы, посчитайте, сколько дней вашего последнего изменения перевозчика на самом деле ушло на программное обеспечение.
Посмотрите, как быстро ваша логика доставки может измениться на самом деле
Миграция корпоративной службы доставки — это серьезный проект, и ответ на вопрос о ней не всегда утвердительный. Предоставьте свои объемы, набор перевозчиков и ограничения по интеграции, а мы расскажем, что на самом деле будет включать в себя этот переезд.
Изучите API доставки Explore the Shipping API
