+7 913 755 28 06
Особенности B2B продаж, учитываемые в Stock-solver.
У оптовых продаж есть свои особенности, поэтому подход к анализу рядов оптовых продаж с последующими расчётами буферов и размеров пополнения отличается.
Высокая концентрация Клиента на SKU.
Допустим, SKU по числу реализаций попадает в группу "A", по валовой прибыли попадает в группу "A" и даже по числу Клиентов также попадает в группу "A". Таким образом, по данной SKU должен поддерживаться высокий УОС (уровень обеспечения спроса запасами). Но если проанализировать структуру Клиентов, потребляющих данную позицию, то может выясниться, что львиную долю всего объёма продаж потребляет один Клиент:
В случае "отвала" этого Клиента, вы останетесь со сверхзапасом (из-за высокого УОСа).
Обычно следуют советы "возить под заказ" или брать "планы продаж" с таких Клиентов. Совет "возить под заказ" работает только в случае короткого lead time. А если поставщики данной SKU находятся, например, в Китае, и led time доходит до 230 дней? Практически никто из Клиентов столько ждать не будет. "Планов продаж" от Клиентов вы также не дождётесь... Если и дождётесь по некоторым, то не факт, что когда дело дойдёт до реализации привезённого объёма под план этого Клиента, этот Клиент купит весь указанный объём именно у вашей Компании,
- это оптовые продажи, и он начнёт одновременно "давить" вас и ваших конкурентов (в случае наличия у них необходимого объёма товара) по ценам, и вы можете не осилить этот демпинг.
В итоге вы становитесь перед выбором: поддерживать большой буфер, рассчитывая на этого крупного Покупателя или не учитывать в статистике SKU продажи данному Покупателю.
Stock-solver выявляет "высококонцентрированного" Клиента в каждой SKU, отдельно анализирует продажи этого Клиента внутри продаж данной SKU и по целому набору критериев принимает решение о включении в статистику продаж / частичном включении (с понижающими коэффициентами) в статистику продаж / исключении из статистики продаж данной SKU с последующими расчётами буфера и размера пополнения.
Обычно следуют советы "возить под заказ" или брать "планы продаж" с таких Клиентов. Совет "возить под заказ" работает только в случае короткого lead time. А если поставщики данной SKU находятся, например, в Китае, и led time доходит до 230 дней? Практически никто из Клиентов столько ждать не будет. "Планов продаж" от Клиентов вы также не дождётесь... Если и дождётесь по некоторым, то не факт, что когда дело дойдёт до реализации привезённого объёма под план этого Клиента, этот Клиент купит весь указанный объём именно у вашей Компании,
- это оптовые продажи, и он начнёт одновременно "давить" вас и ваших конкурентов (в случае наличия у них необходимого объёма товара) по ценам, и вы можете не осилить этот демпинг.
В итоге вы становитесь перед выбором: поддерживать большой буфер, рассчитывая на этого крупного Покупателя или не учитывать в статистике SKU продажи данному Покупателю.
Stock-solver выявляет "высококонцентрированного" Клиента в каждой SKU, отдельно анализирует продажи этого Клиента внутри продаж данной SKU и по целому набору критериев принимает решение о включении в статистику продаж / частичном включении (с понижающими коэффициентами) в статистику продаж / исключении из статистики продаж данной SKU с последующими расчётами буфера и размера пополнения.
"Выстрелы".
Как в ряду розничных продаж, так и в ряду оптовых встречаются аномально большие значения или "выстрелы". Но эти "выстрелы" отличаются как по форме (если не считать продажи по акции в рознице, а они легко учитываются и исключаются, то в опте размах вариации значений продаж значительно больше), так и по "содержанию" - в опте выделяющиеся по величине продажи могут быть совсем не "аномалией", а вполне нормальными продажами каких-нибудь крупных Клиентов (одного или нескольких). Поэтому просто взять и срезать их каким-нибудь квантильным фильтром будет некорректно.
В данном случае Stock-solver использует кластерный фильтр :
Как в ряду розничных продаж, так и в ряду оптовых встречаются аномально большие значения или "выстрелы". Но эти "выстрелы" отличаются как по форме (если не считать продажи по акции в рознице, а они легко учитываются и исключаются, то в опте размах вариации значений продаж значительно больше), так и по "содержанию" - в опте выделяющиеся по величине продажи могут быть совсем не "аномалией", а вполне нормальными продажами каких-нибудь крупных Клиентов (одного или нескольких). Поэтому просто взять и срезать их каким-нибудь квантильным фильтром будет некорректно.
В данном случае Stock-solver использует кластерный фильтр :
Далее идёт пересчёт и проверка суммы буферов в рублях на "вхождение в лимит" денежных средств при последовательном исключении сначала кластера 1, затем кластера 2 и т.д...
Данный фильтр применяется после фильтра "высококонцентрированных" Клиентов.
Резервирование под Клиента.
При расчёте потребности (т.е. значения "к заказу") буфер сравнивается с текущим значением "остаток на складе (группе складов данного филиала/точки продаж) + в пути". А остаток на складе стандартным образом представлен в двух вариантах: "в наличии" (весь остаток) и "доступно" (только свободный остаток), где "доступно" = "в наличии" - сумма всех резервов.
После формирования потребности (с последующим заказом Поставщику или заказом на перемещение) остаток, на который опирались расчёты, может сильно подскочить из-за снятия резерва ("Клиент отказался"), и вы получите излишек в цепи пополнения.
В оптовых продажах эти "перепады" на несколько порядков сильнее, чем в рознице, и могут критично сказаться на системе управления запасами. Поскольку эти резервы возникают и снимаются постоянно, можно получить сверхзапас. Программно-ограничительные меры в учётной системе вроде запрета на продолжительность резерва "свыше стольких -то дней" практически не помогают (менеджеры ухитряются продлевать резерв, "переписывая" его на другого Клиента, на другого менеджера и т.п...). Учёт только оплаченных резервов тоже не спасёт - в оптовых продажах много Клиентов-дебиторов.
Stock-solver анализирует историю всех резервов каждого Клиента, т.е. как долго длился каждый резерв и чем он заканчивался: полной или частичной реализацией, либо снятием резерва. Соответственно в остатке по данной SKU учитываются только резервы по определённому критерию (на основе вышеуказанного анализа).
При расчёте потребности (т.е. значения "к заказу") буфер сравнивается с текущим значением "остаток на складе (группе складов данного филиала/точки продаж) + в пути". А остаток на складе стандартным образом представлен в двух вариантах: "в наличии" (весь остаток) и "доступно" (только свободный остаток), где "доступно" = "в наличии" - сумма всех резервов.
После формирования потребности (с последующим заказом Поставщику или заказом на перемещение) остаток, на который опирались расчёты, может сильно подскочить из-за снятия резерва ("Клиент отказался"), и вы получите излишек в цепи пополнения.
В оптовых продажах эти "перепады" на несколько порядков сильнее, чем в рознице, и могут критично сказаться на системе управления запасами. Поскольку эти резервы возникают и снимаются постоянно, можно получить сверхзапас. Программно-ограничительные меры в учётной системе вроде запрета на продолжительность резерва "свыше стольких -то дней" практически не помогают (менеджеры ухитряются продлевать резерв, "переписывая" его на другого Клиента, на другого менеджера и т.п...). Учёт только оплаченных резервов тоже не спасёт - в оптовых продажах много Клиентов-дебиторов.
Stock-solver анализирует историю всех резервов каждого Клиента, т.е. как долго длился каждый резерв и чем он заканчивался: полной или частичной реализацией, либо снятием резерва. Соответственно в остатке по данной SKU учитываются только резервы по определённому критерию (на основе вышеуказанного анализа).