Планирование запасов для магазинов с высоким SKU

Каталог из 1200 SKU не способствует принятию 1200 решений о покупке в неделю. Производит около тридцати. Самая сложная часть планирования большого каталога — это не все просмотреть, а построить фильтр, который превращает все в тридцать позиций, о которых человек должен подумать.

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

Что изменится за несколько сотен SKU

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

Вся проблема в этой арифметике. Время просмотра зависит от размера каталога, а неделя - нет, поэтому где-то при небольшом количестве SKU полный проход перестает соответствовать и незаметно становится частичным проходом, который никто не помечает как один. Обзор все еще происходит в календаре. Он просто перестает освещать каталог.

Второе, что меняется, — это форма ошибки. В небольшом каталоге вы знаете товары, поэтому ошибка обычно — это то, что вы заметили и ошиблись. В большом случае ошибка — это то, на что никто не обращал внимания. Артикул может оставаться на нулевом уровне в течение одиннадцати дней, и ни один человек не сформирует о нем мнение, потому что ни один этап процесса никогда не приводил к этому. Молчание перестает быть доказательством того, что все в порядке.

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

Сначала сегментируйте, а затем проверяйте по исключениям

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

Сегментация — это долговечный фильтр. Он меняется медленно, обычно раз в квартал, и разделяет каталог в зависимости от того, какой доход приносит продукт и насколько предсказуемым является его спрос. Расчет обеих оценок описан в Анализ запасов ABC-XYZ, а порядок обработки полученных уровней, включая частоту просмотра каждого уровня, принадлежит определение приоритета продуктов для повторного заказа. И то, и другое здесь является предпосылками, а не темой этого поста.

Правила исключений — это еженедельный фильтр, и большинство магазинов никогда не записывают их. Правило исключения — это условие, при котором SKU ставится перед человеком. Все остальное остается в стороне. Рабочий стартовый набор:

Проанализируйте это на примере магазина: 1200 SKU, девять поставщиков, одно местоположение. Из 1200 180 относятся к еженедельному уровню. Правила отмечают, что 23 из них находятся ниже точки повторного заказа, 5 — с заказом на покупку после обещанной даты и 7 — чей прогноз превысил пороговое значение. Четыре артикула подчиняются сразу двум правилам, поэтому очередь на неделю составляет 31 товар, а не 1200.

Еженедельный график покупок

Если фильтры существуют, процедура становится достаточно короткой, чтобы их можно было защитить. Тридцать одно решение примерно по две минуты каждое — это примерно час, а час — это вещь, которая выдерживает напряженную неделю.

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

Группируйте по поставщикам, прежде чем принимать решение о каком-либо количестве. Шесть SKU от одного поставщика — это один заказ и одна стоимость доставки; одни и те же шесть, распределенные между тремя поставщиками, — это совершенно другое решение. Группировка в первую очередь также выявляет опасные ситуации, которые стоит отодвинуть вперед: SKU, который находится за две недели до момента повторного заказа, стоит добавить к заказу, который все равно отправляется.

Решайте количество только того, что находится в очереди. Все, что находится за его пределами, уже проверено правилами.

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

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

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

Что необходимо автоматизировать

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

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

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

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

Статус заказа на покупку. Кто-то должен заметить, что срок заказа истек, пока еще есть время его выполнить. Это запланированное сравнение, а не суждение.

Автоматизация этих четырех означает, что нечто иное, чем файл, должен хранить записи о ваших поставщиках, сроках выполнения заказов и параметрах повторного заказа и работать по часам. StockCue выполняет эту работу, и ограничения плана здесь имеют большее значение, чем в большинстве постов: уровень Free охватывает 50 SKU, что по определению не является магазином с большим количеством SKU, поэтому каталог такого размера означает рост до 2000 SKU или масштабирование до неограниченного количества. Прогнозирование с сезонной корректировкой работает на каждом плане, включая бесплатный, тогда как заказы на покупку, получение и подсчет запасов начинаются на уровне Starter, поэтому магазин, которому нужен рабочий процесс покупки, а также цифры, с самого начала рассматривает платный уровень.

Что должно оставаться ручным

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

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

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

Само одобрение. Рекомендация, основанная на неверном сроке выполнения заказа, скорее ошибочна, чем явно ошибочна, и никакая автоматизация не помечает собственные неверные исходные данные. Кто-то должен посмотреть на число и решить, что оно правдоподобно, прежде чем оно станет приказом.

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

Выходим из таблицы

«Управление 1000 SKU без электронных таблиц» — распространенный способ сформулировать эту проблему, но он слегка неправильно ее диагностирует. Количество строк - это не то, что ломается. Электронная таблица без проблем вмещает 1200 строк, сортирует их быстрее, чем любое приложение, и с радостью рассчитает точку повторного заказа для каждой из них.

Чего электронная таблица не может делать, так это действовать, пока она закрыта. Каждый перерасчет в нем — это человек, вспоминающий о необходимости сделать перерасчет. Ничто в файле не выполняется во вторник, если его во вторник никто не открывает, ничто в нем не поднимает руку, и цифры в нем остаются такими же свежими, как и в прошлый раз, когда у кого-то был свободный день. При 40 SKU этот разрыв составляет несколько минут работы. При 1200 это разница между фильтром, который работает, и фильтром, который существует в принципе.

Чистая версия перемещения обычно не является удалением. Большинство магазинов, которые превращают перерасчет в инструмент, сохраняют в файле то, в чем он всегда был лучше: особенности поставщиков, правила упаковки коробок, заметку о продавце, который закрывается на три недели в августе. Такое разделение ничего не стоит и сохраняет контекст, для которого нет поля ни в одном программном обеспечении.

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

Часто задаваемые вопросы

Как вы управляете запасами более 1000 наименований товаров?

Фильтруя, а не просматривая. Сегментируйте каталог так, чтобы небольшой уровень получал частое внимание, а остальные выполнялись в более длительных циклах, а затем примените правила исключений (ниже точки повторного заказа, заказ на покупку после обещанной даты, прогноз существенно сдвинулся), чтобы к вам попадали только те продукты, по которым необходимо принять решение. Постоянная работа над большим каталогом направлена ​​на поддержание этого фильтра, а не на просмотр каждого продукта.

Как часто магазин с высоким SKU должен проверять точки повторного заказа?

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

Что следует автоматизировать в первую очередь в большом каталоге?

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

Можете ли вы представить 1000 SKU в электронной таблице?

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