Как организовать FBS-склад: процессы, сборка, хранение и ошибки

Коротко: из чего состоит нормальный FBS-процесс

В упрощённом виде FBS выглядит так: маркетплейс прислал заказ, сотрудник нашёл товар, упаковал его и передал в доставку. Такая схема действительно работает, пока заказов немного. При росте объёма проблема быстро смещается с упаковочного стола на весь складской процесс.

Рабочая цепочка выглядит иначе:

• заказ поступил в систему;
• товар зарезервирован;
• сотрудник получил адрес хранения;
• товар найден и подтверждён сканированием;
• при необходимости отсканирован КИЗ;
• заказ упакован и промаркирован;
• перемещён в контролируемую зону отгрузки;
• передан маркетплейсу;
• результат приёмки подтверждён.

Отмена или возврат запускают отдельную обратную цепочку. Именно наличие этих связей отличает управляемый FBS-склад от склада, который держится на памяти сотрудников.

1. FBS начинается с физического остатка, а не со сборки

Первая ошибка при запуске FBS - начинать с принтера, упаковочного стола и стикеров. В действительности FBS начинается с ответа на вопрос: сколько товара физически находится на складе прямо сейчас.

Одного значения «остаток = 10» недостаточно. Минимально нужно разделять:

• физический остаток - сколько единиц реально лежит на складе;
• резерв - сколько уже обещано поступившим заказам;
• доступно - сколько ещё можно безопасно продать.

Например: физически 10, в резерве 3, доступно 7. Если система продолжит публиковать 10, склад рано или поздно продаст товар, которого уже нет.

Поэтому источник правды должен находиться внутри складского контура, а публикация на маркетплейсы строиться уже от него. Подробнее этот принцип разобран в разделе остатков и распределения.

2. У каждого товара должен быть адрес хранения

На маленьком складе опытный сотрудник действительно способен помнить, где лежит большинство SKU. Но такая модель не масштабируется. Новый человек, отпуск кладовщика, второй склад или резкий рост ассортимента сразу превращают память сотрудников в узкое место.

Адрес должен принадлежать месту, а не человеку. Например:

A-03-02-04

• A - зона;
• 03 - стеллаж;
• 02 - секция;
• 04 - полка или ячейка.

Сотрудник должен получить не задачу «найди тушь такого-то бренда», а конкретное указание: «возьми SKU 14582 из A-03-02-04».

Это и есть смысл адресного хранения: склад перестаёт зависеть от знания отдельных людей.

3. Раскладывать товар нужно под скорость отбора, а не под красоту

Логичная на первый взгляд раскладка по брендам и категориям не всегда даёт лучший результат. Для FBS важнее сократить маршрут сборщика и число потенциальных ошибок.

Практический подход - учитывать частоту продаж:

• зона A - самые ходовые позиции ближе к сборке;
• зона B - товары со средней частотой заказов;
• зона C - редкий ассортимент дальше от рабочей зоны.

При этом похожие товары, которые легко перепутать, иногда полезно физически разнести. Для склада важна не только длина маршрута, но и вероятность ошибки.

4. Конкретный товар нужно связать с конкретным заказом как можно раньше

Опасная схема - заранее распечатать десятки этикеток, затем собрать десятки товаров и только после этого пытаться сопоставить одно с другим. На похожих SKU такая модель почти неизбежно создаёт пересорт.

Безопаснее строить сборку заказа вокруг подтверждения физического товара:

1. система показывает следующий заказ и адрес хранения;
2. сотрудник подходит к нужной ячейке;
3. сканирует штрихкод товара;
4. система проверяет соответствие варианту заказа;
5. только после успешной проверки разрешает продолжить.

Сканер здесь нужен прежде всего не ради скорости. Его главная задача - не позволить человеку быстро собрать неправильный товар.

5. Маркированный товар должен получить свой КИЗ внутри сборки

Для товара с обязательной маркировкой недостаточно знать SKU. Нужно сохранить связь между заказом и конкретной физической единицей товара.

Рабочая последовательность:

заказ → товар → сканирование DataMatrix → проверка → привязка КИЗ → упаковка.

Если сначала собрать большую партию заказов, а потом отдельно разбирать коды маркировки, вероятность ошибки резко возрастает. Поэтому DataMatrix и КИЗ лучше встраивать непосредственно в операцию сборки.

6. Рабочее место упаковщика должно убирать действия, а не добавлять их

На рабочем месте не должно быть необходимости постоянно переключаться между кабинетами маркетплейсов, Excel, программой печати и несколькими окнами браузера.

Обычно достаточно:

• компьютера, терминала или смартфона;
• сканера;
• принтера этикеток;
• упаковочных материалов;
• места проверки товара;
• зоны готовых заказов.

Каждое лишнее действие нужно умножать на количество заказов. Даже 15 дополнительных секунд на одном заказе превращаются более чем в четыре часа лишней работы на 1 000 заказов.

7. Печать - часть складского процесса

На небольшом объёме принтер воспринимается как обычная периферия. На потоке он становится частью конвейера.

Типичные проблемы:

• выбран не тот принтер;
• стикер напечатан дважды;
• этикетка ушла на офисный A4-принтер;
• перепутаны документы разных маркетплейсов;
• закончились расходники;
• стикер плохо читается;
• браузер каждый раз требует ручного подтверждения печати.

Правильный сценарий - сотрудник завершает операцию, а система понимает, какой документ нужен и куда его отправить. Именно поэтому печать этикеток лучше связывать с действием внутри заказа, а не оставлять отдельной ручной процедурой.

8. Wildberries, Ozon и Яндекс Маркет должны сходиться в один физический процесс

Правила площадок различаются: статусы, дедлайны, поставки, этикетки, упаковка, документы, отмены и возвраты меняются независимо друг от друга. Но физический склад у продавца остаётся одним.

Поэтому устойчивее строить процессы не вокруг интерфейса конкретного маркетплейса, а вокруг собственных сущностей:

• товар;
• физический остаток;
• резерв;
• заказ;
• сборка;
• грузоместо;
• отгрузка;
• возврат.

Интеграционный слой уже переводит эти операции в требования Wildberries, Ozon или Яндекс Маркета. Такой подход особенно важен, когда один и тот же физический запас продаётся сразу на нескольких площадках.

9. Один физический остаток нельзя мысленно умножать на количество маркетплейсов

Допустим, на складе осталось две единицы товара. В кабинетах одновременно опубликовано:

• Wildberries - 2;
• Ozon - 2;
• Яндекс Маркет - 2.

Физически товаров всё равно два. Если заказы придут почти одновременно, один из них уже невозможно выполнить.

Поэтому схема должна быть такой:

физический остаток → резерв → доступно → опубликовано.

Иногда к этому добавляют страховой запас. Например: физически 5, страховой остаток 1, доступно к публикации 4. Чем точнее учёт и быстрее синхронизация, тем меньше требуется такой буфер.

10. Собранный заказ ещё не отгружен

Между упаковочным столом и машиной должна существовать контролируемая зона готовых заказов. Там заказы можно разделять по площадке, времени передачи, маршруту или проблемному статусу.

Статусы «собран» и «передан маркетплейсу» нельзя считать одним и тем же событием. Иначе возникает классическая ситуация: заказ точно собирали, но физически он остался рядом со столом и не уехал.

Работа склада также не должна заканчиваться после выезда машины. Если передано 500 заказов, а площадка подтвердила 498, два расхождения лучше искать сразу, пока последовательность действий ещё можно восстановить.

11. Отмена и возврат - полноценные обратные процессы

Если заказ отменился после отбора или упаковки, простого изменения статуса недостаточно. Система должна понять, где находится товар, снят ли резерв, нужно ли вернуть его в ячейку, что делать с КИЗ и не попал ли заказ уже в грузоместо.

Возврат тоже нельзя автоматически превращать в свободный остаток. Сначала нужно подтвердить:

• что товар физически вернулся;
• что это правильный SKU;
• что сохранены упаковка и комплектация;
• что товар пригоден к повторной продаже;
• что маркировка корректна.

Только после проверки принимается решение: вернуть товар в доступный остаток, переместить в брак или отправить на отдельное хранение. В KENVARA этот контур вынесен в отдельный процесс возвратов и отмен.

12. При росте заказов оптимизировать нужно маршрут, а не скорость ходьбы

Схема «получил заказ → сходил за товаром → вернулся → взял следующий заказ» перестаёт быть эффективной на большом складе. Сотрудники начинают тратить значительную часть смены на перемещения.

Следующий уровень - групповой или волновой отбор. Несколько заказов объединяются в маршрут, чтобы сотрудник один раз прошёл нужные зоны склада и собрал сразу несколько позиций.

Но чем эффективнее массовый отбор, тем важнее последующий контроль распределения товаров по конкретным заказам. Ускорение не должно происходить за счёт точности.

13. При масштабировании разделяйте операции

На старте один сотрудник может полностью провести заказ от получения до отгрузки. При росте объёма процесс обычно естественным образом делится:

• отбор - найти и взять товар;
• проверка - подтвердить соответствие заказу;
• упаковка - подготовить и промаркировать;
• отгрузка - сформировать грузоместа и передать площадке.

Это не обязательно четыре разных человека. Главное - чтобы система понимала текущий этап каждого заказа и могла показать, где возникла задержка.

14. Какие показатели действительно полезно контролировать

Без измерений невозможно понять, стал ли склад работать лучше после изменений. Минимальный набор метрик:

• заказов собрано в час;
• среднее время сборки;
• время от получения заказа до готовности;
• ошибки отбора и пересорт;
• отмены из-за отсутствия товара;
• доля заказов, подготовленных вовремя;
• расхождения физического и системного остатка;
• время между сборкой и передачей маркетплейсу;
• производительность отдельных участков склада.

Иногда перенос нескольких ходовых SKU на два стеллажа ближе к упаковке даёт больше эффекта, чем сложная программная оптимизация. Сначала нужно измерить узкое место, а уже затем автоматизировать его.

15. Чек-лист запуска FBS-склада

Перед ростом объёма полезно проверить склад по короткому списку:

• физический остаток отделён от резерва и доступного количества;
• у каждого активного SKU есть понятное место хранения;
• перемещения товара фиксируются;
• сборщик видит адрес хранения до начала поиска;
• штрихкод подтверждает правильный товар;
• КИЗ связывается с заказом во время сборки;
• принтер и формат этикетки определяются системой;
• готовые заказы имеют отдельную зону и статус;
• есть контроль фактической передачи маркетплейсу;
• отмены возвращают товар через контролируемый процесс;
• возвраты проходят проверку до восстановления остатка;
• остатки нескольких площадок считаются от одного физического запаса.

Если несколько пунктов существуют только «по договорённости между сотрудниками», именно там обычно появляется следующая ошибка при росте.

16. Когда Excel перестаёт быть достаточным

Excel отлично подходит для старта, справочников и отдельных расчётов. Проблема появляется, когда одновременно нужно управлять событиями: несколькими сотрудниками, складами, тысячами SKU, адресами хранения, параллельными заказами, резервами, КИЗ, возвратами и несколькими отгрузками в день.

Таблица хорошо хранит данные. FBS требует ещё отвечать на вопросы: кто взял товар, из какой ячейки, под какой заказ, какой КИЗ отсканирован, кто упаковал, куда положили готовый заказ и когда его передали площадке.

В этот момент бизнесу нужна не ещё одна таблица, а система управления операциями.

17. Как этот подход реализован в KENVARA

В KENVARA FBS рассматривается не как отдельный список заказов с кнопкой «Собрать», а как единый контур между маркетплейсом, физическим товаром и складом.

В одной системе связываются:

• каталог товаров;
• физические остатки и резервы;
• склады и адресное хранение;
• заказы Wildberries и Ozon;
• сканирование товара;
• DataMatrix и КИЗ;
• печать этикеток;
• поставки и отгрузки;
• распределение остатков;
• история действий;
• отмены и возвраты.

Принцип простой: маркетплейсов может быть несколько, но физический товар у бизнеса один. Поэтому система должна понимать не только статус в кабинете площадки, но и реальное состояние товара и заказа внутри склада.

Главное правило хорошего FBS-склада

Хороший FBS-склад - это не склад, где сотрудники научились очень быстро бегать. Это склад, где им почти не приходится искать, вспоминать и самостоятельно решать, что делать дальше.

• у товара есть адрес;
• у заказа есть резерв;
• каждая критичная операция подтверждается;
• у маркированной единицы есть конкретный КИЗ;
• у собранного заказа есть место ожидания отгрузки;
• у переданной поставки есть подтверждение приёмки;
• у возврата есть отдельный контролируемый маршрут.

Когда эти процессы связаны между собой, рост количества заказов перестаёт означать пропорциональный рост хаоса. Именно тогда FBS превращается из ручной сборки в управляемый склад.