В предыдущей части я сфокусировался на важности центрального склада для сокращения сроков поставки и, как следствие, в значительном снижении запасов вкупе со значительным улучшением наличия. Само по себе это существенное изменение для улучшения показателей деятельности. Хорошая новость в том, что можно сделать всё ещё лучше.
Для этого требуется, чтобы мы отказались от некоторых общепринятых практик и заменили их новыми. Следующая практика, от которой нужно отказаться, это сложившаяся практика дозаказа. Текущие превалирующие практики: пополнять, когда запасы достигли предписанного уровня (известного как МинМакс), либо пополнять после предопределённого периода (известного как точка дозаказа). В обеих этих методологиях мы потребляем (продаём) запас, но откладываем точку пополнения на какой-то день в будущем. Это приводит к искусственно увеличенному горизонту планирования. Мы называем время между потреблением и точкой дозаказа OLT (Order Lead Time, время исполнения заказа). Изменив эту процедуру на новую — заказывать сразу же при потреблении (или даже в конце каждого дня), мы можем устранить OLT.
Взгляните на свои данные: если ваше время доставки (время, которое проходит с момента размещения заказа до прибытия заказа на склад), например, 4 недели, и ваш средний уровень запасов 4 месяца, то ваше OLT составляет 3 месяца. Это значит, что выбранная вами процедура увеличивает ваш горизонт планирования, и в результате точность прогноза ухудшается, как и точность размера запасов. Очень часто OLT составляет, как минимум, 50% от общего горизонта прогнозирования.
Таким образом, с помощью небольшого изменения мы можем уменьшить горизонт прогнозирования как минимум на 50% — это возможность снизить запасы вдвое, в дополнение к достижениям, уже полученным при введении центрального склада. И это ещё не конец.
Как было сказано в предыдущей части, целевой уровень запасов нужно определять с помощью формулы — Максимальное прогнозируемое потребление в течение среднего периода пополнения, с поправкой на надёжность пополнения. Как только у нас появляются запасы на центральном складе, мы можем использовать эту формулу чтобы установить целевой уровень запасов на каждом региональном складе, учитывая при этом только время транспортировки. Определяя уровень запасов таким образом мы можем двигаться дальше по цепи поставки вплоть до последнего звена.
Как только целевые уровни запасов установлены и пополнение делается ежедневно, мы можем добавлять следующий элемент — частоту поставки. Общепринятая практика — ждать, пока заказ не достигнет достаточно большого кол-ва SKU, т.к. мы получим минимальную цену на транспортировку в расчёте на единицу. Результат — заказ каждого SKU в большем количестве, чем требуется. Большие запасы увеличивают горизонт планирования, что приводит к снижению точности размера запасов. Это также означает более высокие транспортные затраты — да, экономия получается надуманной, т.к. совокупные затраты растут, когда мы перемещаем больше запасов, чем требуется, для большинства SKU. В итоге мы платим дважды — высокие и неточные запасы в сочетании с более высокими совокупными затратами. Переход к более частым заказам с меньшим количеством для каждого SKU (но всё ещё достаточно высоким в целом) приведет к снижению транспортных затрат в сочетании с более высоким уровнем наличия, т.к. при частых заказах запас некоторых позиций будет регулярно достигать точки потребления. Таким образом, повышается возможность системы обрабатывать редкий пиковый спрос.
Помимо все этих преимуществ, мы должны помнить, что Мёрфи ещё существует, и что необходимость продолжать улучшения никогда не заканчивается. Мы можем далее улучшать результаты, используя концепцию управления буфером.
Разделите буфер запаса на три зоны по ⅓ буфера. Верхняя треть (от размера целевого уровня до ⅔ от его размера) зелёная, следующая треть жёлтая и нижняя — красная. В каждой точке хранения скорость потребления может быть быстрее либо медленнее в сравнении со скоростью, спрогнозированной при расчете целевого уровня. Если фактическая скорость быстрее ожидаемой, то запасы быстро перейдут из зелёной зоны в жёлтую и красную. Каждая поставляющая точка получает ежедневные заказы от своих точек потребления. Каждый заказанный SKU прибывает с цветовым кодом, показывающим текущее состояние запаса в точке потребления. Цвета дают поставляющей точке следующее: чёткая индикация срочности пополнения: Зелёный — не срочно, Красный — очень срочно. Они также используются в механизме установки приоритета — если существует конфликт приоритета, то вначале будет отправлен заказ в точку с запасом в красной зоне. Это ВАЖНО, поскольку в большинстве систем управления запасами отсутствует механизм установления приоритетов для обоих видов звеньев цепи и, как правило, реакция опаздывает. В данном случае реакция в большинстве случаев оказывается своевременной и эффективной.
Управление буфером также предоставляет возможности для постоянного совершенствования. Большинство систем управления запасами практически никогда не изменяют установленный целевой уровень SKU. Однако задержка SKU слишком долго в Зелёном или в Красном — это чёткий сигнал, что уровень запасов неверен. Он слишком высок (если запас долго находится в Зелёном) либо слишком низок (долго находится в Красном). Отслеживание таких случаев позволяет динамически подстраиваться если целевые уровни запаса основаны на фактическом потреблении, постоянно проверяя, что остаток каждой позиции не слишком высок или недостаточен. Если дополнительно мы будем проводить анализ случаев, когда остаток находился в красной зоне, мы сможем постоянно продолжать улучшать результаты деятельности системы.
Подводя итог: для значительного сокращения запасов, операционных издержек при управлении запасами и значительного улучшения наличия:
• Создайте центральный склад
• Установите целевые уровни запасов для каждой позиции в соответствии с формулой — Максимальное прогнозируемое потребление в течение среднего периода пополнения, с поправкой на надёжность пополнения.
• Делайте заказы ежедневно
• Пополняйте часто
• Используйте управление буфером
То, чего вы достигните, выходит за рамки того, что вы можете себе представить.
Путешествие на этом не заканчивается. С соответствующими показателями оценки результатов возможны дальнейшие улучшения, но это тема отдельной статьи.
Мы описали, как реализованы механизмы
Буфер и Динамическое управление буфером в StockM А здесь можно прочесть статью от собственника
компании Садовые машины о том, как внедряли решения теории ограничений, с какими проблемами столкнулись и как менялись результаты за время и после внедрения