Когда говорят про сквозную видимость запасов, создается ощущение, что речь идет о некой единой системе, где все данные синхронизированы и доступны в реальном времени. Но если посмотреть на это не в теории, а на практике, картина оказывается гораздо сложнее.
Меня зовут Николай Чумаков, я CEO IT-компании е-комЭКСПЕРТ. Мы занимаемся разработкой e-commerce платформ, и в этой статье разберу, как это работает в реальности, на примере нашего клиента, крупного дистрибьютора автозапчастей.
Задача выглядит просто: пользователь на сайте должен видеть понятный статус — «в наличии» или «под заказ 2 дня». Но за этим стоит вся цепочка: от поставщиков до склада и логистики, где данные постоянно меняются, обновляются с задержкой и не всегда совпадают.
В автозапчастях это особенно критично. У нашего клиента каталог более трех миллионов SKU, при этом около 95% ассортимента физически находится на складах поставщиков. В момент оформления заказа система должна быстро ответить на несколько вопросов: есть ли деталь прямо сейчас у себя на складе или, у какого из 100+ поставщиков, по какой цене и можно ли доставить её в срок.
Именно в этой точке и возникает ключевая сложность: система работает не только со своим наличием, но и последней доступной версий остатков поставщиков.
Давайте разбираться по порядку.
Цепочка поставок и ИТ-архитектура
Если сильно упростить, цепочка почти всегда состоит из трех уровней: поставщик, дистрибьютор и точка продаж. И не важно это магазин, склад для онлайн-заказов или маркетплейс.
На каждом уровне работает свой набор систем:
- ERP отвечает за учет и заказы,
- WMS за систему управления складом,
- TMS за доставку.
- Рис 1
Проблема в том, что ни одна из этих систем не видит картину целиком. ERP может показывать, что товар «есть», потому что он заказан или уже учтен. В WMS в этот момент еще происходит процесс приемки и размещения. А поставщик вообще прислал остатки утром и с тех пор у него всё поменялось.
И если посмотреть на это в комплексе, то мы имеем корректные остатки внутри каждой системы, которые не отражают реальность общей картины.
При этом важно понимать: даже если все системы формально настроены правильно, итоговая картина зависит не только от IT, но и от того, насколько корректно процессы выстроены у каждого участника цепочки.
Как работают закупки, склад и логистика внутри этой модели
Закупки
Если разбирать глубже, управление запасами в такой модели строится на наборе правил и допущений.
Как правило:
- считаются минимальные и максимальные товарные запасы (min/max),
- учитывается реальная потребность к моменту заказа,
- заказы распределяются между поставщиками с учетом цены, наличия и рейтинга надежности (уровня сервиса).
Практически это выглядит так: сначала выбираются поставщики с лучшими условиями по цене и наличию. Затем недостающий объем распределяется на альтернативных, с учетом допустимого роста стоимости.
Важную роль в этом процессе играет надежность поставщиков. Под ней обычно понимается не просто факт подтверждения заказа, а уровень сервиса в целом: соблюдение сроков поставки, процент отгрузки без брака и пересорта, точность комплектации и стабильность работы. У топ-10 поставщиков количество подтверждений держится на уровне 90-100%, у остальных колеблется в диапазоне 85–90%.
Но даже при правильно настроенной логике это не гарантирует выполнение заказа. Потому что дальше система сталкивается с реальными процессами на стороне поставщика.
Вот пример ситуации, которая показывает влияние человеческого фактора на рейтинг поставщиков: дистрибьютор получил от поставщика заказ с несколькими ошибочными позициями. Сразу связался с менеджером для принятия возврата и замены.
Менеджер, возможно, был занят, закрывал заказ или просто не захотел в моменте решать проблему и ответил: "Разберу позже, сейчас не до этого". Дистрибьютор принял товар под условием последующей замены, но сразу снизил поставщику рейтинг в своей системе.
Итог: поставщик потерял приоритет в подборе заказов не из-за технической ошибки, а из-за того, что менеджер не нашел 15 минут для оперативного решения.
При одинаковых ценах и сопоставимых условиях начинают играть роль уже не только технические параметры системы, но и скорость реакции, качество коммуникации, лояльность и доверие между сторонами. И это тоже отдельная зона работы для бизнеса.
Но есть и обратная ситуация, когда менеджеры на стороне дистрибьютора искусственно завышают рейтинг отдельных поставщиков, исходя из личных интересов. В таком случае уже может начать страдать репутация самой площадки. Поэтому подобные процессы важно отслеживать и контролировать, чтобы правила работы были понятны и одинаковы для всех участников цепочки.
Склад
Складская логика реализуется через WMS: адресное хранение, управление размещением, пополнение. Топология склада фактически «зашита» в WMS: от того, как она настроена, напрямую зависит скорость подбора и отгрузки.
Как правило, к этому приходят не сразу — сначала все пытаются жить на ERP, но при росте объемов это перестает работать. После внедрения меняется сама операционная скорость: если до внедрения WMS склад клиента обрабатывал порядка 25 000 строк в сутки, то с ней этот показатель изменился до 40 000, что привело к увеличению скорости доставки, повышению выручки и снижению количества ошибок. Выше скорость - выше лояльность - выше LTV.
Но даже при внедренной WMS фактор физического склада остается: пересорты, недостачи, ошибки при подборе. Например, в одной ячейке часто хранится несколько товаров. Если подбор идет в ручном формате без сканирования, кладовщик может просто взять не ту позицию — особенно если детали визуально похожи или сотрудник не разбирается в номенклатуре. В этот момент возникает ключевая проблема: система продолжает считать, что нужная деталь на складе есть, хотя фактически её уже нет — её отгрузили другому клиенту.
Дальше ситуация развивается сразу по двум сценариям. С одной стороны, клиент, который получил не ту деталь, оформляет возврат. Это не только занимает время, но и бьет по репутации дистрибьютора: рекламации, негативные отзывы, потеря доверия. С другой — по исходному заказу начинается поиск. Среднее время разбора такой ситуации от 4-6 часов, в сложных случаях до 2 дней. Если быстро решить не удается — позицию вычеркивают, заказ уходит с неполной комплектацией и клиент вынужден искать товар заново.
Важно еще отметить: вычерк может возникнуть не только из-за отсутствия товара, но и из-за низкого уровня комплектации, невалидного кода маркировки или ошибками при проверке в системе «Честный знак».
Например, некоторые позиции не проходят проверку «Честного знака» и осознанно не отгружаются — клиент всё равно не сможет их принять. То есть товар физически есть, но с точки зрения процесса он становится “недоступным”. У ряда поставщиков это дает до −10% к фактической отгрузке (примерно у 1-2 фур из 50 появляется такая ошибка).
Наш клиент решил эту проблему через изменение самого процесса: клиент внедрил обязательное сканирование через ТСД в связке с WMS и усилил контроль на этапе подбора и проверки. Это позволило снизить количество ошибок, уменьшить вычерки и повысить фактическую отгрузку. Опыт накапливался хронологически и зашивался в программный продукт, поэтому дальнейшее повторение ошибок исключалось.
Логистика
Транспортная часть (TMS) управляет доставкой, маршрутизацией и планированием рейсов. Например, у ряда компаний TMS интегрирована с сервисами вроде Яндекс.Маршрутизации и позволяет в режиме online перестраивать маршруты с учетом пробок, загрузки транспорта и изменений по заказам.
При этом роль TMS не ограничивается только построением маршрутов. Система также участвует в подборе транспорта под конкретный рейс: рассчитывает необходимый объем машины с учетом ВГХ товара, упаковки и параметров загрузки. Это особенно важно при больших объемах поставок, где ошибка в расчетах напрямую влияет на сроки доставки.
Например, если на этапе комплектации или погрузки выясняется, что часть товара физически не помещается в машину, цепочка начинает сдвигаться дальше: требуется замена транспорта, перенос рейса или догрузка отдельной машиной. В результате возникают опоздания и смещение сроков доставки уже для клиента.
Но даже при автоматизированной логистике часть проблем остается вне самой TMS. На практике сбои часто связаны с операционными процессами и человеческим фактором: водитель не вышел на рейс, некорректно оформили документы, возникли ошибки при комплектации или загрузке товара.
Поэтому даже при выстроенной логистике стабильность всей цепочки по-прежнему сильно зависит не только от самой TMS, но и от качества данных, складских процессов и взаимодействия между участниками поставки.
Как это работает в реальности
Теперь давайте посмотрим туда, где возникает самый большой рассинхрон данных — на обмен между поставщиком и дистрибьютором.
Чаще всего используются простые механизмы. Например:
- файлы (Excel, почта, FTP),
- регулярные выгрузки несколько раз в день,
- иногда API, но не везде и не для всего.
Если обсуждать это с участниками рынка, почти все сходятся в одном: поставщики редко обновляют остатки в реальном времени. Обычно это 1–4 раза в день. У нашего клиента: основные поставщики обновляют прайсы 4 раза в сутки (в 7:00, 12:00, 15:00 и 18:00), остальные — 1 раз в день. С одной стороны, можно увеличить частоту обновлений. С другой — высок риск нагрузки системы ERP и серверной инфраструктуры.
Из-за этого возникает базовое ограничение: данные всегда приходят с задержкой и частично теряют актуальность. Средняя задержка составляет от 4 до 24 часов — именно столько времени проходит между реальным изменением остатка у поставщика и появлением этой информации на сайте. Мы не раз видели ситуации, когда даже при обновлении несколько раз в день часть заказов не подтверждается. По данным клиента, от 2-15% заказов поставщики не подтверждают полностью (надёжные до 10%, если свыше - клиент ухудшает рейтинг данного поставщика). Просто потому, что между выгрузкой и реальным движением товара проходит время, за которое фактическое наличие меняется.
В результате один заказ может распределяться между несколькими поставщиками. Причем часть позиций уходит к менее выгодным по цене вариантам. У нашего клиента, система допускает перераспределение в пределах заданного порога — в среднем это до +3% к закупочной цене. Если в этот диапазон уложиться не получается, заказ не подтверждается, чтобы не ломать экономику (это уже контролируется на уровне ERP, например 1С).
И если разложить это на простой сценарий, становится понятнее, где именно возникает разрыв. Поставщик показал наличие в прайсе, система его запомнила, клиент оформил заказ, а к моменту обработки на стороне поставщика этого товара уже нет. И это самая частая причина отказов - 95%. Но также причинами являются: внутренние пересорты - 2,5%, порча товара, обнаруженная при подборе- 2,5% (например: вытекает масло, портится упаковка).
Маркетплейсы, кроссдокинг и возвраты
Дополнительно все усложняют внешние факторы и на базовую модель накладываются процессы:
- кроссдокинг (поставка без хранения на складе дистрибьютора),
- интеграция с маркетплейсами,
- маркировка,
- ограничения по возвратам.
Но при этом, кроссдокинг не просто история про поставку без хранения. На практике, это целая логистическая схема, при которой большая часть товара идет через стандартный складской цикл, но часть потока обрабатывается через отдельную зону быстрого перегруза. Условно 90% проходит через склад как обычно, а оставшиеся 10% фактически перегружаются «с фуры на фуру».
Так, у нашего клиента около 10% позиций идут по этой схеме, но бывают и бизнес-модели, где эта цифра выше. Это частично снижает управляемость и предсказуемость.
С возвратами тоже не все просто: не все позиции можно вернуть, часть товара зависает неликвидом, и фактическая картина запасов начинает отличаться от планируемой (у нашего клиента это примерно 0,5-1%).
Кроме того, один и тот же товар может двигаться по разным сценариям, и контролировать это становится все сложнее.
Где возникают основные проблемы
Если обобщить весь наш опыт и опыт коллег, ключевые проблемы почти всегда одни и те же и повторяются от проекта к проекту: данные приходят с задержкой, остатки в разных системах не совпадают, поставщики не всегда подтверждают заказы полностью, интеграции плохо масштабируются.
Отдельная боль — расхождения между тем, что подтвердили, и тем, что реально отгрузили. Поставщик может изменить состав заказа уже после подтверждения, что приводит к сбоям в дальнейшей цепочке. Это происходит примерно в 1-2% подтвержденных заказов.
Есть и менее очевидная, но частая проблема — качество данных. Например, различия в артикулах: латиница и кириллица, и даже уровень регистра, лишние символы, разные форматы записи. В нашем кейсе менее 1% артикулов имеют проблемы сопоставления. В результате системы просто не соотносят одни и те же позиции, и часть остатков «теряется». Это очень важный момент, потому что без нормализации и синхронизации справочников с поставщиком, контроля форматов никакие интеграции не дают результата.
По оценкам клиента, до 10% случаев связаны именно с проблемами данных, а не с реальным отсутствием товара.
Что в итоге значит «сквозная видимость»
Если обобщить все вышесказанное, то сквозная видимость на практике — это точно не единая и не централизованная база данных.
Правильнее будет сказать, что это управляемая модель, которая собирает разрозненные данные, учитывает их задержки и погрешности и на их основе принимает решения.
За 8 лет развития нашего клиента он смог построить именно такую модель процессов: она собирает разрозненные данные из ERP, WMS, TMS, учитывает их задержки и на этой основе принимает решения.
Результат: оборот вырос на 40%, отказы в e-commerce — всего 2%.
Как это строилось поэтапно:
● с 2008 года — развитие системы в целом
● одновременное внедрение WMS и сканеров ТСД (исключен ручной подбор)
● BI-аналитика для отслеживания качества поставщиков
● нормализация артикулов через скрипт сопоставления
● автоматизированная система рейтингов поставщиков
● конвейерная линия для мезонинного участка склада
● доработка ERP/WMS под Честный знак с API-синхронизацией ЭДО
В виде формулы это выглядит так:
Сквозная видимость = (ERP + WMS + TMS + ...) + I + R − E
где: I — лидерство между цепями R — правила простых данных E — допустимая погрешность задержек (в нашем случае 1-3 дней и отказы до 15%)
Фактически это управляемое приближение к реальной картине запасов.
И именно поэтому попытки добиться полной синхронности через жесткую централизацию, как правило, не устраняют проблему, а увеличивают сложность архитектуры и стоимость ее поддержки.