Срыв отгрузок на складе: как одна настройка WMS вернула нормальный ритм работы.

История из практики, которая хорошо иллюстрирует простую мысль: причина сбоя почти никогда не там, где он проявляется. На складе начался срыв отгрузок. Машины стоят в очереди на погрузку, задержка — уже три дня. Клиенты недовольны, транспортники считают простой, руководство требует объяснений.

Классическая реакция в такой ситуации — «давить на людей». Но я пошел по цепочке вопросов вниз, к корню проблемы. Разбор по цепочке: Почему машины стоят? Потому что грузчики не отгружают. Почему грузчики не отгружают? Потому что нет укомплектованных заказов. Почему нет укомплектованных заказов? Потому что кладовщики не успевают собрать машины. Почему кладовщики не успевают? Потому что отборщики не могут отобрать продукцию с полок стеллажей: ячейки отбора пустеют, товара в них нет. И здесь самое интересное: почему в ячейках отбора нет товара, хотя на складе он в наличии? Потому что не происходит пополнение зон отбора из зон хранения.

Разбор показал: WMS ставила задачу на пополнение только в тот момент, когда отборщик уже стоит у ячейки и ему нужно отобрать товар. Пополнение было реактивным, а «пока не поздно» по факту уже поздно. Отборщик приходит — ячейка пуста. Задача на пополнение создаётся и встаёт в очередь. Пока водитель погрузчика доедет до зоны хранения, возьмёт паллету и доставит её, отборщик потерял время, а заказ срок. В пиковые часы очередь на пополнение не разгребалась, и отставание нарастало лавинообразно: три дня, и вот уже машины ждут своей очереди на погрузку.

Отбор без товара — это всегда простой самого дорогого ресурса: и человека, и техники. А «виноватых» в этот момент ищем не там, где болит.

Решение: сформулировано ТЗ для специалиста по WMS: система должна сама инициировать задачу на пополнение, как только остаток в ячейке отбора опустится ниже установленного порога по количеству или по объёму. Не тогда, когда отборщик пришёл за товаром, а заранее. По сути, это классический механизм минимального остатка, только применённый к ячейкам отбора. Порог задаётся по каждому SKU с учётом скорости отбора и времени на пополнение: к моменту, когда товар реально нужен, паллета уже стоит в ячейке.