+7 913 755 28 06
Особенности B2B продаж, учитываемые в Stock-solver.
У оптовых продаж есть свои особенности, поэтому подход к анализу рядов оптовых продаж с последующими расчётами буферов и размеров пополнения отличается.
Высокая концентрация Клиента на SKU.
Допустим, SKU по числу реализаций попадает в группу "A", по валовой прибыли попадает в группу "A" и даже по числу Клиентов также попадает в группу "A". Таким образом, по данной SKU должен поддерживаться высокий УОС (уровень обеспечения спроса запасами). Но если проанализировать структуру Клиентов, потребляющих данную позицию, то может выясниться, что львиную долю всего объёма продаж потребляет один Клиент:
У оптовых продаж есть свои особенности, поэтому подход к анализу рядов оптовых продаж с последующими расчётами буферов и размеров пополнения отличается.
Высокая концентрация Клиента на 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 учитываются только резервы по определённому критерию (на основе вышеуказанного анализа).
Продажи "не с того склада".
В оптовых продажах часто (гораздо чаще, чем в рознице) встречаются ситуации, когда ввиду дефицита на ближайшем к Клиенту складе продажи осуществляются с другого склада, где есть этот товар. Если статистику продаж собирать по складу отгрузки, возникнет «порочный круг», когда не смотря на продолжающийся дефицит на складе, который ближе всего к Клиенту, будет продолжать пополняться именно склад отгрузки.
В оптовых продажах часто (гораздо чаще, чем в рознице) встречаются ситуации, когда ввиду дефицита на ближайшем к Клиенту складе продажи осуществляются с другого склада, где есть этот товар. Если статистику продаж собирать по складу отгрузки, возникнет «порочный круг», когда не смотря на продолжающийся дефицит на складе, который ближе всего к Клиенту, будет продолжать пополняться именно склад отгрузки.
Для правильного учёта статистики и дальнейшего пополнения можно привязать продажи к точке через её адрес в отгрузочном документе (в структуре "Заказа покупателя") либо через карточку Клиента. Первый вариант «железобетонный», но требует ведения учёта по нему не менее года до момента внедрения АСУЗ, «задним числом» такой объём работ не провернуть, второй вариант можно внедрить сразу, но он сильно зависит от «человеческого фактора» (от корректности заполнения).
Если допускается возможность продаж с другой точки в случае отсутствия товара на данной точке, то для корректного учёта в статистике нулевых продаж при нулевых остатках (возможных «вычерков», т.е. потенциального дефицита), необходимо в специальном регистре указать, с каких точек возможны продажи в случае нехватки остатка на данной точке. Обмен «всех со всеми» не всегда возможен - к примеру, точки продаж Компании расположены как в Европейской части РФ, так и на Дальнем Востоке, причём и привязка к одному РЦ не показательна (здесь главную роль играет транспортная логистика). Помимо транспортной логистики на "векторы" обмена между точками влияет и конкуренция по данному товару: к примеру, точки продаж, которые являются «по совместительству» и РЦ - это крупные города, и, в случае возникновения дефицита на них, они не могут его закрыть с других точек, т.к. транспортировка после продажи с другой точки требует времени, а этого времени просто нет в силу высокой конкуренции в этих городах по данному товару (Покупатель не будет ждать и обратится к конкурентам Компании).
Stock-solver использует привязки продаж именно к точкам (складам), расположенным ближе всего к Клиентам и, собирая статистику, опирается на "множества обмена между точками продаж" и "приоритеты обмена".
Если допускается возможность продаж с другой точки в случае отсутствия товара на данной точке, то для корректного учёта в статистике нулевых продаж при нулевых остатках (возможных «вычерков», т.е. потенциального дефицита), необходимо в специальном регистре указать, с каких точек возможны продажи в случае нехватки остатка на данной точке. Обмен «всех со всеми» не всегда возможен - к примеру, точки продаж Компании расположены как в Европейской части РФ, так и на Дальнем Востоке, причём и привязка к одному РЦ не показательна (здесь главную роль играет транспортная логистика). Помимо транспортной логистики на "векторы" обмена между точками влияет и конкуренция по данному товару: к примеру, точки продаж, которые являются «по совместительству» и РЦ - это крупные города, и, в случае возникновения дефицита на них, они не могут его закрыть с других точек, т.к. транспортировка после продажи с другой точки требует времени, а этого времени просто нет в силу высокой конкуренции в этих городах по данному товару (Покупатель не будет ждать и обратится к конкурентам Компании).
Stock-solver использует привязки продаж именно к точкам (складам), расположенным ближе всего к Клиентам и, собирая статистику, опирается на "множества обмена между точками продаж" и "приоритеты обмена".
