Добрый день, я занимаюсь разработкой сервиса по прогнозированию спроса на базе Microsoft Azure, Spark Apache в IT компании. В цикле статей я расскажу про реальные бизнес кейсы из российских реалий, с которыми сталкивается IT компания. В основном статьи будут про бизнес: есть клиент, есть его задачи, нужно найти способ как их решать и доказать менеджменту адекватность расчётов, далее уже внедрение.
Данная статья носит информативный характер: я не буду подробно описывать алгоритмы расчета и наши модели, однако, я расскажу логику, на которой базируется вся математическая часть.
Первый бизнес-кейс
Компания хочет понять сколько у неё потерь (очень круто, когда компания сразу знает, что хочет), и как можно их уменьшить.
Цель поставлена. Теперь немного о компании: Федеральная сеть 400 розничных магазинов. Пилотную версию проекта договорились проводить с одной категорией товара – 20 sku, средний срок годности продукта 15 дней.
Структура работы выглядит следующим образом:
- Анализ деятельности компании. На данном этапе анализируются бизнес процессы компании: системы пополнения, график поставок, остатки.
- На втором этапе нужно понять, что считать «потерей», откуда она возникает, как оценить величину потерь и тд. Куча открытых вопросов.
- Предложить решение, позволяющее сократить потери.
Кажется, все просто. Нужно понимать, что оптимизацию можно реализовать в бизнес процессах (изменение графика поставок, учёт пробок…) и IT решение, базирующиеся на внедрении новых технологий, дающих business value. В последнем случае в компании не нужно делать серьезные изменения, такие как переобучение персонала, изменение структуры работы, обновление инфраструктуры. В данной статье буду говорить только об IT решении.
Немного об экономии в больших компаниях
Например, просрочка единицы каждого sku в день не кажется существенной при анализе небольшой группы – 20 sku. Однако, давайте посчитаем месячные чистые потери:
31(дней)*400(магазинов)*20(количество sku)*1=240 000 единиц.
Пусть средняя цена закупки будет 30р, то есть 7.2 млн рублей в месяц чистых потерь. Казалось бы, всего 1 единица товара в день, единичка миллионы бережет.
На первом этапе анализа компании будем под потерями учитывать недопродажи компании и просроченными товары. Осталось понять, как их считать. В данном проекте нам очень повезло, так как у клиента была статистика просроченного товара, иначе пришлось бы искусственно их моделировать.
Попробуем разобраться с недопродажами
Под недопродажей будем считать ситуацию, когда наблюдается OOS (out of stock), то есть приходится моделировать ситуацию в духе «что было бы, если бы у компании было достаточно остатков, чтобы удовлетворить спрос покупателей». В данных клиента есть остатки в разрезе Shop-Sku-Day, что радует. Стоит заметить, что остатки считаются на конец рабочего дня.
Учитывая вышеописанную логику, необходимо найти дни с учетом товара в пути, в которые остатки были нулевыми, и заменить продажу в этот день на среднюю за последнюю неделю. Отметим, что если в такой день по факту не было продаж, то недопродажей считаем среднюю продажу за последние 7 дней, иначе недопродажа = недельная средняя – факт продажа.
По сути, данные о продажах говорят нам о той части спроса, которую удалось удовлетворить, однако это не есть исходный спрос покупателей.
Очистка от OOS и некоторые другие процедуры, очищающие данные, например, от такой ситуации: если на полке нет кока-колы, то часть покупателей купит пепси; позволяют получить реальный спрос со стороны покупателя.
Супер! Мы получили динамику недопродаж в разрезе Shop-Sku-Day и реальный спрос со стороны покупателя. Дело осталось за малым: перевести все в деньги – недопродажи умножить на маржу, а просрочку на закупочную цену. Скажу, что в данной компании суммарные потери были 6.6 млн рублей в месяц —примерно 8% от оборота данной группы sku. Все расчеты проводились на реальных данных клиента, результаты полностью соответствуют действительности. В России, к сожалению, анализу потерь мало кто уделяет этому пристальное внимание, поэтому потери составляют такой большой процент от оборота во многих компаниях.
Первые этапы выполнены. Можно рапортовать менеджменту, что у вас потери в 6.6 млн! На что получим весьма логичный ответ – И что? Предлагайте решение и обосновывайте его экономику!
Окей, нужно придумать, как снизить косты. Одно из наших IT решений подобных задач – облачный сервис по прогнозированию продаж на базе Microsoft Azure. Данное решение не требует серьезных затрат на его внедрение и интеграцию в бизнес. Кроме того, в сервисе используются облачные технологии, что позволяет не загружать мощности клиента.
Компания прогнозировала продажи на основе скользящей средней + страховой запас, а в сервисе заложены более серьезные методы прогнозирования (о них попозже). Замечу, что в компании была средняя точность прогнозирования порядка 50%, а наш сервис на трехлетних данных клиента показывает точность 70%.
Дневную точность считаем по следующей формуле:
$$display$$точность=1-frac{|y- widehat{y} |}{max(1,y, widehat{y})}, где y - факт, widehat{y} - прогноз$$display$$
Если нужно агрегировать, то считаем как средневзвешенную.
Самая важная часть проекта – показать реальный профит от нашего продукта. Отмечу, что, естественно, точность прогноза дает выгоды, однако, в каждой компании разные. Это связано с их бизнес процессами, например, график поставок не позволяет сделать заказ сегодня, кратность заказа — количество йогуртов должно быть кратно 24, или минимальный заказ должен быть 100 штук. Поэтому необходимо смоделировать всю систему изнутри: берем график поставок клиента, условия заказа, плечи доставок и нужную загруженность транспорта. И уже в этой среде моделируем потери при разной точности, чтобы показать реальный business value.
Мы должны смоделировать остатки клиента, поставки товара, продажи, просроченную продукцию, закладывая разную точность прогноза.
Итак, мы построили модель, в которой заложили следующие предпосылки:
- Модель включает в себя вероятностную часть: покупатели с большой вероятностью покупают более свежий товар, чем «долго лежащий».
- В моделировании использовалась восстановленная функция спроса: фактические продажи были очищены от OOS и эффекта товаров-субститутов.
- Остатки и поставки моделировались с учетом графиков, сроков поставок, условий заказа.
- Издержки от недопродажи были посчитаны как разность между (спросом и модельными продажами)*маржу.
- Издержки от брака были посчитаны, как сумма всех просроченных товаров в денежном выражении, использовались закупочные цены.
Зависимость потерь от точности прогнозирования:
Теперь явно видно, что при точности порядка 70% экономия составит примерно 1.2 млн рублей в месяц, что неплохо, учитывая, что пилотная версия строилась на группе из 20 sku.
Возникает интересный момент: у клиента 12 дневный страховой запас, однако, имея хороший прогноз, его можно уменьшить и получить дополнительные выгоды. При моделировании все исходные данные системы не меняются, кроме страхового запаса, что позволяет, не уменьшая уровень сервиса для покупателя, снизить косты. Дополнительно отмечу, что все смоделированные заказы согласуются с графиком поставок клиента, а также соблюдаться условия заказов, то есть смоделированная система полностью соответствует бизнес процессам компании.
График – лучший инструмент для доказательства:
Теперь при точности 70% экономия составит 4.6 миллиона рублей в месяц! Данный результат, очевидно, очень крутой. Удивительно, как внедрение сервиса по прогнозированию, может дать экономию средств клиента в размере 4.6 млн рублей в месяц только на 20 sku!
Выводы
Таким образом, с помощью IT решения нам удалось сэкономить клиенту 4.6 млн рублей в месяц на пилотной версии. Сейчас мы взяли в разработку оставшиеся группы товара для анализа и выявление профита, который даст наш облачный сервис по прогнозированию.
Надеюсь, что статья была полезна. В следующей статье будет подробно рассказано про работу нашего сервиса.
Буду рад ответить на ваши вопросы. Спасибо за внимание!
Автор: PavelGonchar
