Особенности B2B продаж, учитываемые в Stock-solver

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

 

Высокая концентрация Клиента на SKU.
 

Допустим, SKU по числу реализаций попадает в группу "A",   по валовой прибыли попадает в
группу "A"  и даже по числу Клиентов также попадает в группу "A". Таким образом, по данной SKU будет поддерживаться высокий УОС (уровень обеспечения спроса запасами). Но если проанализировать структуру Клиентов, потребляющих данную позицию, то может выясниться, что львиную долю всего объёма продаж потребляет один Клиент:

График оптовых продаж.png
График оптовых продаж с выдел. высококонцентр. Клиента.png
Диаграмма концентрации Клиентов на SKU.png

В случае "отвала"  этого Клиента, вы останетесь со сверхзапасом (из-за высокого УОСа).

Совет "возить под заказ" работает только в случае короткого lead time.  А если поставщики данной SKU находятся, например, в Китае, и led time доходит до 230 дней? Практически никто из Клиентов столько ждать не будет,  и вы становитесь перед выбором: поддерживать большой буфер, рассчитывая на этого крупного Покупателя или не учитывать в статистике SKU продажи данному Покупателю.

Stock-solver выявляет "высококонцентрированного" Клиента в каждой SKU, отдельно анализирует продажи этого Клиента внутри продаж данной SKU и по целому набору критериев принимает решение о включении в статистику продаж / частичном включении (включении с понижающими коэффициентами) в статистику продаж / исключении из статистики продаж   данной SKU
с последующими расчётами буфера и размера пополнения.

Формула k сигм_edited.png

"Выстрелы".

 

 

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

В данном случае Stock-solver использует кластерный фильтр, где значения продаж группируются по степени "близости":

Кластерный фильтр, график исходного ряда.png
Кластерный фильтр, график с выделением кластеров.png
Кластерный фильтр, график кластера1.png

Далее идёт пересчёт и проверка суммы буферов в рублях на "вхождение в лимит" денежных средств при последовательном исключении сначала кластера 1, затем кластера 2 и т.д...

Кластерный фильтр, график без кластера1.png

Данный фильтр применяется после фильтра "высококонцентрированных" Клиентов.

Резервирование под Клиента.

 

При расчёте потребности (т.е. значения "к заказу") буфер сравнивается с текущим значением "остаток на складе (группе складов данного филиала/точки продаж) + в пути". А остаток на складе стандартным образом представлен в двух вариантах:
"в наличии" (
весь остаток)  и "доступно" (только свободный остаток), где "доступно" = "в наличии" -
-сумма всех резервов.

После формирования потребности (с последующим заказом Поставщику или заказом на перемещение) остаток, на который опирались расчёты, может сильно подскочить из-за снятия резерва ("Клиент отказался"), и вы получите излишек в цепи пополнения.

В оптовых продажах эти "перепады" на несколько порядков сильнее, чем в рознице, и могут критично сказаться на системе управления запасами. Поскольку эти резервы возникают и снимаются постоянно, можно получить сверхзапас.  Программно-ограничительные меры в учётной системе вроде запрета на продолжительность резерва "свыше стольких -то дней" практически не помогают (менеджеры ухитряются продлевать резерв, "переписывая" его на другого Клиента, на другого менеджера и т.п...). Учёт только оплаченных резервов тоже не спасёт - в оптовых продажах много Клиентов-дебиторов.

Stock-solver  анализирует историю всех резервов конкретной SKU каждого Клиента, т.е. как долго длился каждый резерв и чем он заканчивался: полной или частичной реализацией, либо снятием резерва. Соответственно в остатке по данной SKU учитываются только резервы по определённому критерию (на основе вышеуказанного анализа).