+7 913 755 28 06
Уровень обеспечения спроса запасами.
Допустим, у нас имеется история посуточных продаж конкретной SKU за год:
А цикл поставки (т.е. интервал между проверками остатков + время с момента возникновения потребности по данной SKU
до момента оприходования её на складе) - 15 дней.
Смоделируем различные варианты (всего 253 значения) спроса за 15 дней:
до момента оприходования её на складе) - 15 дней.
Смоделируем различные варианты (всего 253 значения) спроса за 15 дней:
Упорядочим все получившиеся 253 исхода моделирования (варианты спроса за 15 дней) по возрастанию.
Эти значения будут строками в таблице "Спрос / Запас":
Эти значения будут строками в таблице "Спрос / Запас":
Эти же отсортированные исходы моделирования, но без повторяющихся значений, будут столбцами таблицы, т.е. вариантами запаса.
Таблицу "Спрос / Запас" заполним следующим образом: в каждой ячейке будет обеспечение спроса в данной строке запасом в данном столбце.
Для ячейки (1; 1) спрос 25 и запас 25. Значит мы можем обеспечить данный спрос в 25 ед., поскольку у нас запас как раз 25ед. Записываем "25".
Для ячейки (2; 1) спрос 33, а в запасе только 25, значит мы можем удовлетворить спрос только в 25ед.
Для ячейки (3; 1) спрос 41, а в запасе только 25, значит мы можем удовлетворить спрос только в 25ед.
Для ячейки (1; 2) спрос 25, а в запасе 33, значит мы можем удовлетворить спрос в 25ед (и даже останется 8ед.) и.т.д...
Т.е. в каждой ячейке будет минимум из спроса в данной строке и запаса в данном столбце:
Таблицу "Спрос / Запас" заполним следующим образом: в каждой ячейке будет обеспечение спроса в данной строке запасом в данном столбце.
Для ячейки (1; 1) спрос 25 и запас 25. Значит мы можем обеспечить данный спрос в 25 ед., поскольку у нас запас как раз 25ед. Записываем "25".
Для ячейки (2; 1) спрос 33, а в запасе только 25, значит мы можем удовлетворить спрос только в 25ед.
Для ячейки (3; 1) спрос 41, а в запасе только 25, значит мы можем удовлетворить спрос только в 25ед.
Для ячейки (1; 2) спрос 25, а в запасе 33, значит мы можем удовлетворить спрос в 25ед (и даже останется 8ед.) и.т.д...
Т.е. в каждой ячейке будет минимум из спроса в данной строке и запаса в данном столбце:
К примеру, запасом в 59ед. будут обеспечены все варианты спроса от 25ед. до 59ед. включительно, т.е. 25; 33; 41; 51; 51; 53; 53; 58; 58; 58; 58; 59. Далее, все варианты спроса больше 59ед. будут обеспечены только в размере 59ед (поскольку запас 59ед.).
Если теперь сложить в каждом столбце значения ячеек, то мы получим для каждого значения запаса суммарное обеспечение данным запасом для всех вариантов спроса. Поделив суммарное обеспечение для каждого запаса на сумму всех вариантов (исходов) спроса, получим относительное обеспечение спроса каждым из значений запаса, т.е. тот самый уровень обеспечения спроса (УОС), который выразим в процентах:
Если теперь сложить в каждом столбце значения ячеек, то мы получим для каждого значения запаса суммарное обеспечение данным запасом для всех вариантов спроса. Поделив суммарное обеспечение для каждого запаса на сумму всех вариантов (исходов) спроса, получим относительное обеспечение спроса каждым из значений запаса, т.е. тот самый уровень обеспечения спроса (УОС), который выразим в процентах:
В итоге заполненная таблица "Спрос / Запас" будет выглядеть так:
Уровень обеспечения по данной SKU показывает, какое количество из запрашиваемых единиц данной SKU мы можем обеспечить запасом.
Указанный способ расчёта УОС в виде заполнения таблицы очень нагляден, но не пригоден для "машинных" расчётов. В Stoc-solver алгоритм расчёта УОС реализован так: подсчитывается, сколько раз среди всех исходов спроса встречалось каждое значение,
т.е. находится частота появления каждого значения исхода. Значение 25 встречалось 1 раз, значение 33 - 1 раз, значение 41 - 1 раз, значение 51 - 2 раза, значение 53 - 2 раза, значение 58 - 4 раза и т.д...
Рассмотренный выше пример из таблицы с суммарным обеспечением запасом в 59ед. - это сумма всех вариантов значений меньше 59, т.е. 25+33+41+51+51+53+53+58+58+58+58 (или 25*1+33*1+41*1+51*2+58*4) плюс 59 х число всех исходов, равных или более 59.
Суммарное обеспечение запасом в 51ед. - это сумма всех вариантов значений меньше 51, т.е. 25*1+33*1+41*1 плюс 51*250 и т.д...
Указанный способ расчёта УОС в виде заполнения таблицы очень нагляден, но не пригоден для "машинных" расчётов. В Stoc-solver алгоритм расчёта УОС реализован так: подсчитывается, сколько раз среди всех исходов спроса встречалось каждое значение,
т.е. находится частота появления каждого значения исхода. Значение 25 встречалось 1 раз, значение 33 - 1 раз, значение 41 - 1 раз, значение 51 - 2 раза, значение 53 - 2 раза, значение 58 - 4 раза и т.д...
Рассмотренный выше пример из таблицы с суммарным обеспечением запасом в 59ед. - это сумма всех вариантов значений меньше 59, т.е. 25+33+41+51+51+53+53+58+58+58+58 (или 25*1+33*1+41*1+51*2+58*4) плюс 59 х число всех исходов, равных или более 59.
Суммарное обеспечение запасом в 51ед. - это сумма всех вариантов значений меньше 51, т.е. 25*1+33*1+41*1 плюс 51*250 и т.д...
Или в виде формулы:
где
- уникальное (без повторений) значение исхода, f - частота появления
Видно, что при данной статистике потребления 100%-ный уровень мы можем обеспечить только поддерживая запас,
равный максимальному из исходов спроса, т.е. 273ед.
При запасе 150ед. УОС будет 90%, при запасе 130ед. - 85,4% и т.д...
А зачем нужен УОС (и все расчёты, связанные с ним) ?
Конечно, для поддержания лояльности Клиентов и не упущения ни одной продажи хотелось бы поддерживать 100%-ный УОС. На это, кстати, упирает ТОС ("Теории ограничений системы"), предлагая рассчитывать первоначальное значение буфера (буфер или оптимальный запас в цепи - это расчётное целевое на данный момент значение запаса на складе + в пути) как «Максимальное ожидаемое потребление в течение среднего времени пополнения, учитывая изменчивость пополнения запаса».
Но беда в том, что выставив 100%-е УОСы по всем SKU, а затем переведя буферы (соответствующие 100%-му УОС) всех SKU в денежные выражения, вы можете обнаружить, что у вас просто не хватит денежных средств на поддержание таких запасов, даже с учётом отсрочек платежей Поставщикам.
Кроме того, 100%-й уровень обеспечения может быть разорительным в торговле скоропортом.
Поэтому для позиций с разными показателями спроса и стоимостными параметрами приходится настраивать разные УОСы.
В условиях ограниченных денежных средств при прочих равных показателях выгоднее всего вкладывать деньги в номенклатуру с минимальной волатильностью спроса (ранжирование SKU по колебанию спроса за цикл поставки проводится с помощью XYZ-анализа). Т.е. из двух SKU с одинаковой частотой спроса, одинаковым объёмом спроса, равными размерами выручки и валовой прибыли, но с разной волатильностью (колебаниями) спроса приоритет имеет SKU с меньшей волатильностью спроса, поскольку можно получить ту же отдачу при меньшем вложении. Но это "при прочих равных...".
На первом месте, конечно, должен стоять показатель частоты продаж, определяющий, насколько "ходовой" или "неходовой" является данная SKU. Таким показателем является число реализаций (или число дней реализации). Если дефицит "неходовой" позиции Клиенты ещё как-то поймут, то дефицит "ходовой" может привести к потере этих самых Клиентов.
На второе место можно поставить показатель валовой прибыли. Для продаж B2B нужен ещё один показатель - количество Клиентов по данной SKU, приоритет в данном случае будет иметь номенклатура с большим количеством Клиентов как более "стабильная", надёжная.
Stock-solver в непрерывном (ежедневном) режиме проводит ABC-анализ (с разделением на три подгруппы в группе "А" и в группе "В") по указанным трём показателям (для розничных продаж - по двум) и XYZ-анализ по волатильности спроса за цикл поставки.
В зависимости от принадлежности данной SKU к конкретной группе (например, " A3 B1 A2 Y "), ей присваивается определённый УОС.
К примеру, " A1 A1 A1 X " - 100%, " A1 A1 A1 Y " - 99,7%, ....., " C C C Z " - 70% (зависимость нелинейная). Получившиеся при данных УОСах значения буферов всех SKU переводятся в денежные единицы и складываются. Если полученная итоговая сумма (по всем SKU) превышает лимит денежных средств, которые могут быть вложены в запасы, УОСы понижаются с шагом 0,5% до тех пор, пока сумма не "зайдёт" в лимит.
равный максимальному из исходов спроса, т.е. 273ед.
При запасе 150ед. УОС будет 90%, при запасе 130ед. - 85,4% и т.д...
А зачем нужен УОС (и все расчёты, связанные с ним) ?
Конечно, для поддержания лояльности Клиентов и не упущения ни одной продажи хотелось бы поддерживать 100%-ный УОС. На это, кстати, упирает ТОС ("Теории ограничений системы"), предлагая рассчитывать первоначальное значение буфера (буфер или оптимальный запас в цепи - это расчётное целевое на данный момент значение запаса на складе + в пути) как «Максимальное ожидаемое потребление в течение среднего времени пополнения, учитывая изменчивость пополнения запаса».
Но беда в том, что выставив 100%-е УОСы по всем SKU, а затем переведя буферы (соответствующие 100%-му УОС) всех SKU в денежные выражения, вы можете обнаружить, что у вас просто не хватит денежных средств на поддержание таких запасов, даже с учётом отсрочек платежей Поставщикам.
Кроме того, 100%-й уровень обеспечения может быть разорительным в торговле скоропортом.
Поэтому для позиций с разными показателями спроса и стоимостными параметрами приходится настраивать разные УОСы.
В условиях ограниченных денежных средств при прочих равных показателях выгоднее всего вкладывать деньги в номенклатуру с минимальной волатильностью спроса (ранжирование SKU по колебанию спроса за цикл поставки проводится с помощью XYZ-анализа). Т.е. из двух SKU с одинаковой частотой спроса, одинаковым объёмом спроса, равными размерами выручки и валовой прибыли, но с разной волатильностью (колебаниями) спроса приоритет имеет SKU с меньшей волатильностью спроса, поскольку можно получить ту же отдачу при меньшем вложении. Но это "при прочих равных...".
На первом месте, конечно, должен стоять показатель частоты продаж, определяющий, насколько "ходовой" или "неходовой" является данная SKU. Таким показателем является число реализаций (или число дней реализации). Если дефицит "неходовой" позиции Клиенты ещё как-то поймут, то дефицит "ходовой" может привести к потере этих самых Клиентов.
На второе место можно поставить показатель валовой прибыли. Для продаж B2B нужен ещё один показатель - количество Клиентов по данной SKU, приоритет в данном случае будет иметь номенклатура с большим количеством Клиентов как более "стабильная", надёжная.
Stock-solver в непрерывном (ежедневном) режиме проводит ABC-анализ (с разделением на три подгруппы в группе "А" и в группе "В") по указанным трём показателям (для розничных продаж - по двум) и XYZ-анализ по волатильности спроса за цикл поставки.
В зависимости от принадлежности данной SKU к конкретной группе (например, " A3 B1 A2 Y "), ей присваивается определённый УОС.
К примеру, " A1 A1 A1 X " - 100%, " A1 A1 A1 Y " - 99,7%, ....., " C C C Z " - 70% (зависимость нелинейная). Получившиеся при данных УОСах значения буферов всех SKU переводятся в денежные единицы и складываются. Если полученная итоговая сумма (по всем SKU) превышает лимит денежных средств, которые могут быть вложены в запасы, УОСы понижаются с шагом 0,5% до тех пор, пока сумма не "зайдёт" в лимит.