Каталог на 3 миллиона SKU и больше 100 поставщиков не оставляют шансов красивой картинке про «единые остатки в реальном времени». Видимость запасов в такой модели оказывается не витриной с зелеными статусами, а компромиссом между ERP, WMS, логистикой и чужими данными, которые успевают устареть еще до оформления заказа. Для российских IT-команд это не абстрактная проблема: именно на этом слое у e-commerce чаще всего ломаются обещания клиенту, SLA и экономика заказа.
Об этом на примере крупного дистрибьютора автозапчастей сообщает IT-World со ссылкой на Николая Чумакова, CEO компании е-комЭКСПЕРТ. Его тезис простой и неприятный для всех, кто любит рисовать «сквозную прозрачность» в архитектурных схемах: пользователь видит на сайте понятный статус вроде «в наличии» или «под заказ 2 дня», но за ним стоит длинная цепочка допущений. У клиента е-комЭКСПЕРТ каталог превышает 3 миллиона SKU, причем около 95% ассортимента физически лежит не у самого дистрибьютора, а на складах поставщиков. В момент заказа система должна за секунды понять, есть ли деталь на своем складе, у кого из более чем 100 поставщиков она доступна, по какой цене и можно ли привезти ее в обещанный срок.
На бумаге все выглядит прилично: ERP считает заказы и учет, WMS отвечает за склад, TMS управляет доставкой. На практике каждая система знает свою правду, но не общую. ERP может показывать, что товар есть, потому что он уже заказан или оприходован в учете. WMS в этот момент еще только принимает поставку и раскладывает ее по ячейкам. Поставщик мог прислать файл с остатками утром, а к обеду половина позиций уже ушла другому покупателю. Формально ошибок нет ни в одной системе, но видимость запасов для бизнеса и клиента все равно искажена. Это важный момент для разработчиков и продуктовых команд: проблема здесь не только в интеграциях и частоте обмена, а в том, что «истина» распределена между участниками цепочки и меняется быстрее, чем согласуются данные.
Отсюда вырастает вторая неприятная вещь: управление запасами в реальном бизнесе строится не на идеальной синхронизации, а на правилах и вероятностях. Дистрибьютор рассчитывает минимальные и максимальные уровни запасов, смотрит на потребность к моменту заказа, а затем распределяет закупку между поставщиками по цене, наличию и рейтингу надежности. У топ-10 поставщиков, по данным автора, подтверждаемость держится на уровне 90-100%, у остальных колеблется в районе 85-90%. Это уже не просто интеграционная задача, а смесь алгоритма и операционной дисциплины. Система сначала выбирает тех, у кого лучше цена и выше шанс отгрузки, а недостающий объем раскладывает на альтернативных партнеров, если рост себестоимости укладывается в допустимые рамки.
Но и здесь ломается не только код. Чумаков приводит показательный кейс: поставщик отправил заказ с несколькими ошибочными позициями, дистрибьютор сразу попросил принять возврат и заменить товар, а менеджер со стороны поставщика отложил вопрос «на потом». Технически ошибка уже случилась, но падение рейтинга поставщика произошло не из-за пересорта как такового, а из-за скорости реакции. В результате партнер потерял приоритет в подборе будущих заказов. Для бизнеса это важная деталь: в модели, где цены у многих близки, начинают играть не только API, EDI и проценты подтверждения, но и банальная управленческая гигиена. Есть и обратный риск: менеджеры дистрибьютора могут искусственно завышать рейтинг «своих» поставщиков. Тогда страдает уже сама площадка, потому что алгоритм выбора перестает быть нейтральным. Для CIO и владельцев продуктов отсюда прямой вывод: рейтинг поставщика должен быть прозрачным, аудируемым и привязанным к измеримым метрикам, а не к чьим-то личным симпатиям.
Со складом история не веселее. Автор пишет, что по мере роста объемов компании почти неизбежно упираются в ограничения ERP и переходят к полноценной WMS с адресным хранением, управлением размещением и пополнением. У клиента е-комЭКСПЕРТ после внедрения WMS производительность выросла примерно с 25 тысяч до 40 тысяч строк в сутки. Это уже не косметика, а прямое влияние на скорость доставки, выручку и количество ошибок. Но даже хорошая WMS не отменяет физику склада. Если в одной ячейке лежит несколько товаров, а подбор идет вручную без сканирования, кладовщик легко берет не ту деталь, особенно если позиции похожи внешне. Для системы нужный товар все еще «есть», хотя фактически его уже отгрузили другому клиенту. Так рождается классический разрыв между цифровым остатком и реальным.
Дальше цепочка последствий знакома любому, кто поддерживал крупный e-commerce: один клиент получает не ту позицию и открывает возврат, второй ждет заказ, по которому внезапно начинается внутренний розыск. По оценке автора, разбор такой ситуации в среднем занимает 4-6 часов, а в сложных случаях растягивается до двух дней. Если проблему быстро не локализуют, позицию просто вычеркивают из заказа, а клиент ищет товар заново. Для разработчиков здесь неприятная, но полезная мысль: даже идеальный фронт со статусом доставки не спасет, если контур складского исполнения не умеет быстро подтверждать физический остаток. Пользовательский опыт в этой зоне определяется не дизайном карточки товара, а скоростью, с которой бэкенд признает, что его данные уже не соответствуют реальности.
Отдельный слой риска связан не с отсутствием товара, а с его процессной недоступностью. Чумаков напоминает, что позиция может выпасть из отгрузки из-за низкого уровня комплектации, невалидного кода маркировки или ошибок при проверке в системе «Честный знак». То есть товар физически лежит на складе, но отгружать его нельзя: клиент все равно не сможет принять такую поставку. У ряда поставщиков, по словам автора, это съедает до 10% фактической доступности. Для бизнеса разница принципиальная: «остаток» и «доступный к продаже остаток» больше нельзя считать одним и тем же полем в базе. Для IT-команд это означает, что видимость запасов должна учитывать не только местоположение товара, но и его операционный статус, валидность маркировки, качество комплектации и вероятность успешного прохождения последующих этапов.
Главный вывод из этой истории довольно приземленный. Видимость запасов перестает быть задачей одного модуля или одной интеграции, как только ассортимент уходит в миллионы SKU, а цепочка поставок разносится по десяткам и сотням контрагентов. В такой архитектуре выигрывают не те, кто громче всех обещает «онлайн-остатки», а те, кто честно считает доверие к данным, умеет различать бухгалтерское наличие и реальную доступность и строит процессы так, чтобы человек не ломал алгоритм быстрее, чем алгоритм успевает ему помочь.