С тех самых пор, как ритейлеры начали вести учет данных про остатки, они, подобно поиску Священного Грааля, выискивали идеальную систему для пополнения запасов. И тут они столкнулись с двумя важными проблемами.
1) Все прогнозы зависят от сохраненной истории продаж. Этими данными манипулируют или интерпретируют их как основу для прогноза будущего спроса. Нужен разумный алгоритм.
2) Любая информация о грядущих событиях должна фиксироваться в системе. Другими словами, менеджеры по закупкам должны еще в какой-то степени вмешиваться в процесс, внося данные о своих запланированных промо-акциях.
Ритейлеры пытаются найти ответы на эти вопросы еще начиная с 1970-х годов. До этого момента изучение автоматического пополнения запасов магазина не было популярным, поскольку ещё не распространилось использование штрих-кодов, сканирования товаров и использование компьютеров для обработки огромных массивов данных. Серьезная система ASR (автопополнения запасов магазина) до 80-х годов широко не использовалась, и многие крупные ритейлеры обратились к такой практике лишь в последние двадцать лет. Некоторые все еще продолжают делать заказы «вручную» или допускают довольно частое вмешательство самого магазина в процесс заказа. На самом деле, зачастую оказывается чрезвычайно сложно управлять динамическим пополнением запасов в его старой интерпретации.
На мой взгляд, системы на основе метода Min Max гораздо надежнее и устойчивее, но желание создать еще более совершенную систему – не остановить.
У ритейлеов, которые собираются использовать динамическую систему, есть два варианта: разработать ее самостоятельно или купить готовое программное обеспечение. И у них есть выбор между двумя решениями: просто «умножить на среднее значение» или сделать более сложные «расчеты на основе прогноза». Использование внутренних систем, как правило, в приоритете, так как разрабатывать системы прогнозирования ужасно сложно.
Давайте начнем с обзора проблем, которые возникают при создании динамической системы пополнения запасов. В самых ранних попытках первой проблемой было отсутствие истории продаж. Поначалу большинство ритейлеров сохраняли лишь малую часть всех данных о своих продажах из-за ограниченных возможностей их хранения, а алгоритмы могли рассчитываться только на основе истории за 2-8 недель. Из-за этого алгоритмы были очень условными. Они не могли, к примеру, учитывать факторы роста сезонности или сравнение данных одного года с другим. Алгоритмы были просто ужасны из-за «короткой памяти».
Вторая проблема, с которой столкнулись ритейлеры – это низкое качество сканирования данных и учета остатков. Даже сейчас у многих ритейлеров не лучшее качество данных из-за неверного сканирования, пересорта или других проблем. (Более подробно я расскажу об этом в отдельной статье из этой серии – «Точное ведение учета остатков»). Такая проблема все еще актуальна для некоторых ритейлеров, особенно в сфере торговли свежими продуктами. Когда учет остатков ведется некорректно, система пополнения делает ложные прогнозируемые расчеты. Например, товар в магазине закончился, а в системе все еще светится остаток. Или наоборот: товар есть в наличие, хотя, согласно данным об учете остатков, его запас равен нулю.
Еще больше проблем возникает, когда в расчетах для пополнения запасов нужно учесть грядущие рекламные акции. У большинства ритейлеров была предусмотрена специальная классификация промо-акций в IT-системе, и, соответственно, можно было отмечать акционные недели. Но все это работало в переменным успехом. У некоторых товаров вообще не было истории продаж, потому что это были новые позиции. За основу для расчетов во многих системах брались данные по «схожим продуктам». Опять же, все это работало с переменным успехом и не без ошибок со стороны человека.
Ранние разработки динамических систем ASR были подвержены всем этим трудностям. Путь к знаниям оказался очень тернистым.
1) Отсутствие информации про сезонность или праздники означало, что простые алгоритмы не смогут достаточно быстро наращивать или снижать запасы в течение сезона.
2) Некоторые ранние разработки систем работали по принципу еженедельного прогноза на основе календарной недели (с воскресенья по субботу). Но такие расчеты недостаточно хорошо учитывали особенности быстро оборачиваемых товаров, где нужна была более точная оценка ежедневных продаж. Ритейлеры с промо-активностями в середине недели не могли в программе отметить полностью всю неделю как акционную или простую.
3) Нужно было внимательно следить за включением отметки о проведении акции. Менеджеры по закупкам могли опоздать с запуском промо-акции или с ответной реакцией на действия конкурентов. Активация отметки в программе о проведении акции редко происходила вовремя. В итоге: что посеешь – то пожнешь.
4) Не все промо-акции одинаковы. Простого «включения» и «выключения» отметки о рекламном периоде было недостаточно. Некоторые ритейлеры пытались классифицировать рекламные мероприятия по степени важности на «высокие», «средние» или «низкие». Но и это не исключает ошибок в выборе класса из-за неверного толкования менеджера или слишком оптимистичных общих ожиданий.
5) Работа ритейлеров над заказами усложнилась с появлением промо-акций с мульти-закупкой и другими экзотическими
и перекрестными схемам. Система уже не могла их обработать должным образом. Когда проходило несколько разных акций одновременно, ее алгоритмы не справлялись.
6) Товары в акционной упаковке или с увеличенным количеством единиц (в подарок) часто заводились в систему под новыми кодами. Нередко различные вариации одного и того же продукта никак не были связаны в программе. Из-за постоянной смены упаковки у многих ритейлеров возникали проблемы с учетом аналогичных позиций.
7) Магазины некоторых форматов, которые торговали крупными партиями или оптом, обнаружили, что после разовых акций все их последующие расчеты сбиваются.
Учитывая все эти трудности, в основном, все ранние разработки систем динамического пополнения создавали одни лишь проблемы. Результаты их расчетов многие ритейлеры использовали только в качестве рекомендованных запасов для ориентира менеджеров магазинов. Другие поняли, что в работе динамической системы не обойтись без постоянного человеческого вмешательства. Тем не менее, по-прежнему нужны были отдельные распределения для рекламных мероприятий и праздничных сезонов. Системы AR эпохи 80-х и 90-х годов казались слишком сложными. Многие ритейлеры просто отказались от их использования и явно опасались наступать на одни и те же грабли дважды.
Как показывает мой опыт, все эти ранние динамические системы менее эффективны, чем система на основе метода Мин Макс, дополненная распределениями. У них есть общий недостаток. Они, как правило, рассчитываются на основе истории продаж за ограниченный или фиксированный срок, например, 4 или 13 недель. Чем короче период продаж, тем хуже результаты расчетов. Эффект ничем не отличается от использования фиксированных периодов времени для постоянного просмотра настроек Мин и Макс. В некоторых случаях ритейлеры принимали тщательно обдуманные решения изменить важность различных периодов продаж, используемых в алгоритме. Например, можно придать свежим результатам продаж более высокое значение (или больший удельный вес фактора), чем истории более ранних продаж. Проблема, как всегда, кроется в том, какой должна быть формула для реализации такого подхода в разрезе каждого отдельного раздела магазина и разных времен года.
Безусловно, самая большая проблема – правильно объяснить ситуацию, когда вымывается запас товаров, и каковы при этом потери от недопродаж. Или когда по товару проходит промо-акция, какова эффективность самой акции, если при этом наблюдается нехватка товара в запасе, происходят перемены в погоде или другие одновременные явления? Необходимо правильно определить факторы, которые повлияли на результаты продаж: к примеру, отсутствие на складе или действительно эффективная промо-акция. В противном случае, при неправильной интерпретации результатов, прогнозы будут искусственно снижены или, наоборот, раздуты. Со временем таких эффектов накапливается все больше. Любому ритейлеру, который все еще использует фиксированную динамическую систему, я рекомендую все же вернуться к более простой системе (например, с методом Min Max и распределениями) или потратиться на разработку более сложного программного обеспечения, которое работает на основе прогнозов.
Помощник закупок полностью поддерживает подход автора. В нём можно использовать как ручной метод Min-Max, так и динамический метод определения объема закупки.