Представьте обычное утро продавца. В 9:10 покупатель заказывает последнюю единицу товара в интернет-магазине. В 9:12 такой же заказ приходит с Ozon, а на Wildberries товар всё ещё отображается в наличии. Менеджер начинает сверять кабинеты, склад ищет товар, которого уже нет, а один из заказов приходится отменять.
Проблема возникла не потому, что сотрудник работал медленно. Интернет-магазин, маркетплейсы и склад увидели один товар как три независимых остатка: карточки живут в разных кабинетах, заказы собираются в нескольких очередях, а фактическое количество приходится сводить вручную.
Чтобы этого избежать, товар, заказ и действия склада нужно связать в одну последовательность: при правильно настроенных правилах новый заказ сразу создаёт резерв, меняет доступный остаток и запускает сборку.
Разберём этот маршрут на примере SelSup. Платформа связывает товары, доступные остатки и заказы интернет-магазина и маркетплейсов со складскими ячейками, сборкой и проверкой маркировки. FBS (Fulfillment by Seller) – модель, при которой продавец хранит и собирает товары на своём складе, а готовые заказы передаёт маркетплейсу для доставки покупателю.
Проследим путь одного заказа: от резерва и адреса ячейки до проверки маркировки, печати этикетки и отгрузки. Заодно разберём, что система может автоматизировать, а что компании всё равно придётся настроить самостоятельно.
Что должно произойти после нового заказа
Под единым контуром будем понимать систему, в которой товар, доступный остаток, заказ и складское задание связаны между собой. Главная задача автоматизации – не собрать все кабинеты на одном экране, а правильно передать следующее действие.
Пока товар лежит на полке, он доступен для продажи. Как только заказ приходит с сайта или маркетплейса, настроенное правило резервирует нужное количество. Остальные подключённые каналы получают уже уменьшенный доступный остаток. Затем склад видит, что нужно собрать, где это лежит, какую маркировку проверить и к какому сроку подготовить отправление.
| Без единого контура | С единым контуром |
|---|---|
| Остатки исправляют в каждом кабинете | Изменение передаётся во все подключённые каналы |
| Заказы ищут на разных площадках | Они поступают в общую рабочую очередь |
| Сборщик ориентируется по названию товара | Он получает SKU, количество и адрес ячейки |
| Маркировку сверяют отдельно | Код проверяется во время сборки заказа |
| Ошибку замечают после отмены | Проблемный заказ выделяется до упаковки |
Этот незаметный для покупателя слой снимает часть ручной работы. Покупатель видит привычный сайт или маркетплейс, а сотрудники работают по одному процессу.
Пример SelSup: после заказа пять единиц резервируются, а доступный остаток меняется с 30 до 25. Для интегрированного интернет-магазина действует тот же принцип.
Четыре элемента, без которых схема развалится
Чтобы каналы действительно работали вместе, системе необходимо связать четыре объекта.
- Товар. Один и тот же физический товар может называться по-разному на сайте, Wildberries и Ozon. Внутри компании у него должен быть постоянный SKU – код, по которому система узнаёт товар во всех каналах.
- Фактический остаток. Это количество товара, которое действительно находится на конкретном складе.
- Резерв. Товар уже обещан покупателю, но ещё физически не покинул склад.
- Заказ. В нём должны сохраняться источник, состав, срок сборки, способ доставки и требования площадки.
Если хотя бы один элемент учитывается отдельно, появляется ручная сверка. Например, заказ уже создан, но резерв ещё не поставлен – последняя единица продолжает продаваться. Или карточки на двух площадках не сопоставлены с одним SKU – система считает их разными товарами.
Эти связи нужны не только для учёта. На их основе строится сам маршрут заказа: поступление, резервирование, сборка, проверка, упаковка и отгрузка.
Как один заказ проходит через единый контур
Рассмотрим товар, который одновременно продаётся в интернет-магазине, на Wildberries, Ozon и Яндекс Маркете. На складе находится 30 единиц.
- Покупатель оформляет на Ozon заказ на пять единиц.
- Заказ поступает в SelSup, а пять единиц резервируются. Фактически на складе пока остаётся 30 единиц, но продать можно уже 25.
- Новый доступный остаток передаётся в остальные подключённые каналы.
- Склад получает задание: какой товар взять, в каком количестве и в какой ячейке он находится.
- Сборщик сканирует товар. Если для этой категории нужна обязательная маркировка и в настройках включена её проверка, сотрудник также сканирует Data Matrix – двумерный код конкретного экземпляра.
- После проверки печатается этикетка нужной площадки, а заказ включается в поставку.
- Когда заказ собран, пять единиц переходят из резерва в отгруженные. Доступный остаток остаётся равен 25.
Если покупатель отменит заказ до отгрузки, резерв снимается и товар снова становится доступным. Если товар вернётся после доставки, его сначала нужно принять и проверить, а затем разрешить повторную продажу.
Для сотрудника результат – один понятный маршрут вместо четырёх кабинетов и ручного переноса статусов. Для бизнеса – меньше отмен и ошибок при сборке, а также понятный статус каждого заказа.
Этапы 1-3: заказ поступает, доступный остаток обновляется, а сборщик получает задание.
Этапы 4-6: товар сканируют, при необходимости передают код маркировки и формируют отгрузку.
Почему простой синхронизации остатков недостаточно
Интеграция часто начинается с передачи одного числа: «на складе десять штук». Но физический и доступный остаток – не одно и то же.
Упрощённая формула выглядит так:
Доступно к продаже = фактический остаток − резервы − брак − страховой запас.
Страховой запас нужен, если компания хочет оставить часть товара для розницы, гарантийной замены или оптовых клиентов. Он также снижает риск перепродажи, когда площадка получает обновление с задержкой.
Резерв, в свою очередь, должен создаваться сразу после получения заказа и сниматься только по определённому событию: отмене, истечению срока оплаты или возврату товара в продажу. Если остаток уменьшается лишь после сборки, один товар успеют заказать сразу в нескольких каналах.
Поэтому хорошая система показывает отдельно:
- фактическое количество на складе;
- доступный остаток;
- резерв;
- товар в сборке;
- готовые и отгруженные заказы;
- возвраты, брак и другие заблокированные единицы.
Так продавец видит не просто число, а понимает, что прямо сейчас происходит с товаром.
Как интернет-магазин становится частью общей системы
Собственный интернет-магазин не должен создавать ещё один независимый складской учёт. На сайте остаются витрина, поиск, корзина, оплата и личный кабинет покупателя. Товары, цены и доступные остатки поступают из выбранного источника, а оформленные заказы возвращаются в общую очередь.
Схема выглядит так:
Единый каталог → сайт и маркетплейсы → общая очередь заказов → резерв → сборка → доставка → обновление статуса.
При этом цена не обязана быть одинаковой во всех каналах. У маркетплейсов различаются комиссии, логистика и условия акций, а в собственном магазине продавец сам управляет оплатой и доставкой. Можно хранить базовую цену и отдельные правила расчёта для каждой площадки, сохраняя общий товар и общий складской остаток.
Если компания уже ведёт учёт в 1С или системе МойСклад, не обязательно полностью менять привычный процесс: SelSup поддерживает интеграции с этими системами. Собственную учётную программу можно связать с SelSup через API – интерфейс для обмена данными между системами. До запуска важно определить, где редактируются карточки, где хранится основной остаток и где завершается сборка.
Пример интернет-магазина: каталог, цены, остатки и заказы связаны с общей системой SelSup.
Что особенно важно для FBS-склада
Когда товар хранится у продавца, скорость зависит не только от обмена данными. Заказ ещё нужно правильно найти, проверить, упаковать и вовремя передать маркетплейсу.
Даже небольшой склад полезно разделить на зоны: приёмка, хранение, подбор, упаковка, готовые отправления и возвраты. Каждому месту хранения присваивается адрес, например A-03-02: зона A, третий стеллаж, вторая полка. Тогда задание сообщает сборщику не только название товара, но и точное место.
Сканирование помогает заметить ошибку на этапе, когда её ещё легко исправить. При расхождении система сообщает, что сотрудник взял другой размер, цвет или товар, и не даёт незаметно продолжить сборку. Для маркируемой продукции отдельно проверяется Data Matrix: обычный штрихкод определяет вид товара, а Data Matrix – конкретный экземпляр.
На старте один сотрудник может сам подобрать, проверить и упаковать заказ. При росте потока процесс разделяют между подборщиком, комплектовщиком и упаковщиком. Общая система сохраняет маршрут, даже когда над заказом последовательно работают несколько человек.
Рабочее место сборщика: SelSup находит заказ по скану, показывает ячейку и проверяет товар перед упаковкой.
Пять признаков, что автоматизация пока работает не полностью
- Один товар заведён несколько раз. Карточки разных площадок не сопоставлены с общим SKU.
- Резерв создаётся слишком поздно. Пока заказ ждёт сборки, товар продолжает продаваться.
- Остатки могут менять все сотрудники. Невозможно определить, какое значение было правильным.
- Маркировку проверяют отдельно от заказа. Возникает риск связать Data Matrix не с тем отправлением.
- Возврат сразу попадает в продажу. Повреждённый товар или экземпляр с проблемным кодом снова становится доступным покупателям.
Если компания узнаёт в этом списке свои процессы, добавление ещё одного кабинета проблему не решит. Нужен контур, который связывает действия с товаром и сохраняет их последовательность.
Когда единый контур нужен, а когда достаточно простого учёта
Единая система особенно полезна, если один товар одновременно продаётся хотя бы в двух каналах или склад работает по FBS. Она также приносит пользу, когда ассортимент включает варианты или маркированные товары, а заказы собирают несколько сотрудников. Чем чаще команда сверяет таблицы, переносит статусы и исправляет остатки вручную, тем заметнее результат автоматизации.
Цена автоматизации – первоначальная настройка. Нужно сопоставить карточки с общими SKU, выбрать источник остатка, задать правила резервирования и права сотрудников. Система выполнит эти правила, но правильный источник данных должна определить компания.
Если компания продаёт на одной площадке несколько заказов в день и весь товар находится перед глазами, сложный складской процесс может быть преждевременным. Сначала достаточно закрепить SKU, определить источник остатка и описать момент резервирования. Подключать ячейки, роли и многоступенчатую сборку стоит тогда, когда ручная работа уже приводит к отменам, пересорту или пропущенным срокам.
Практичный подход – автоматизировать сначала каталог, остатки и заказы, затем добавить складские задания, сканирование и маркировку. Так компания проверяет пользу на одном процессе и расширяет контур без резкой перестройки работы.
Как проверить систему до полноценного запуска
На демонстрации или пилотном запуске стоит провести один реальный заказ по всему маршруту:
- Получить его с выбранной площадки или сайта.
- Создать резерв и показать новый доступный остаток.
- Передать остаток в остальные каналы.
- Выдать складу задание с адресом ячейки.
- Проверить товар и Data Matrix сканированием.
- Напечатать этикетку и сформировать отгрузку.
- Отдельно обработать отмену и возврат.
После теста сравните три значения: остаток в системе, остаток на витринах и фактическое количество на полке. Если они совпадают после заказа, отмены и возврата, основу процесса можно масштабировать на остальные кабинеты и склады.
Единый контур незаметен – пока его нет
Покупателю неважно, сколько систем использует продавец. Он ожидает увидеть товар в наличии, оформить заказ и получить его в срок. Но за этим простым сценарием стоят каталог, резерв, складские ячейки, маркировка, этикетки и обмен статусами.
В SelSup эти операции связаны в одну цепочку: при получении заказа система резервирует товар, обновляет доступный остаток, выдаёт задание складу и проводит заказ до отгрузки без ручного переноса между кабинетами.
Если команда сверяет остатки в таблицах, ищет заказы в нескольких кабинетах или обнаруживает ошибки уже после упаковки, можно проверить этот маршрут на примере SelSup: провести один заказ, отмену и возврат по шагам из статьи. Такой тест покажет, какие ручные действия можно убрать именно из вашего процесса.
Комментарии