Начнем мы, естественно, с классического механизма Динамического управления буфером. Все описанные здесь алгоритмы, подходы и рекомендации основаны на изложенных в уже упомянутой книге «Управление цепью поставок с невероятной скоростью»[1].
Необходимость в разработке формализованного механизма ДУБ определяется тем, что в отличие от человека, для компьютерных систем понятия «слишком долго и много в зеленом» и «слишком долго и много в красном» не имеют смысла. Хотя если мы вооружим нашего сотрудника графическим способом предоставления информации, то человек вполне в состоянии принимать решения просто глядя на график остатков и зон буфера. И если бы у нас было гарантированно небольшое число SKU и мест хранения в управлении, то люди справлялись бы с этой задачей, но реальность такова, что в управлении в цепи поставок находятся десятки, а иногда — и сотни тысяч SKU в десятках мест хранения в цепи поставок. И ручная обработка такого объема данных физически невозможна в разумные сроки. Поэтому был разработан и предложен данный механизм ДУБ.
Исходная посылка механизма:
Если у нас реализован и работает механизм частого (в идеале — ежедневного) пополнения на основании фактического потребления, то поведение остатков товаров/продукции «на руках» достаточно хорошо отражает изменения в тенденциях спроса и/или сроков пополнения.
То есть у нас есть и постоянно обновляются все необходимые для принятия решений данные, несмотря на то что и надежный срок пополнения, и уж тем более спрос на товар — это вероятностные переменные, обладающие достаточно высокой изменчивостью и неопределенностью.
Из двух ситуаций: «буфер слишком маленький» и «буфер слишком большой», первая, как правило, рассматривается как более опасная, могущая нанести ущерб репутации и бизнесу компании. С нее мы и начнем.
Как определить, что буфер слишком маленький и компания рискует остаться без товара? Компания регулярно довозит товар, заказывает его до Целевого уровня буфера, в пути всегда есть товар, но статус буфера «на руках» постоянно проваливается в нижнюю треть буфера — в красное. Это достаточно надежное свидетельство того, что или растет спрос на данную позицию, или у нас увеличился надежный срок пополнения и рассчитанный Целевой уровень буфера не обеспечивает спрос.
Математически (алгоритмически) это определяется так: суммируем разницу между уровнем границы красного и остатком «на руках» в течение срока пополнения назад от сегодняшней даты (собственно, рассчитываем площадь выделенной на рисунке ниже фигуры). Затем сравниваем полученное значение со значением красной границы буфера. Если значение превысило установленную красную границу, то уровень буфера должен быть увеличен на треть.
Разберем на простом примере. У нас есть товар Х, срок пополнения которого 15 дней. Пусть ЦУБ у нас равен 21 единице, граница красного соответственно — 7. Фактические остатки на руках (подневно) от сегодняшнего дня назад: 3, 4, 10, 14, 5, 10, 12, 10, 5, 12, 14, 10, 12, 14. Считаем «площадь» нахождения в красном: (7–3)+(7–4)+(7–5)+(7–5) = 4+3+2+2 = 11. Это точно больше, нежели граница красного. Соответственно, целевой уровень буфера должен быть увеличен на треть до уровня 28 единиц.
Очевидно, что при таком резком увеличении ЦУБ остатки «на руках» проваливаются еще глубже в красное, а в системе появляется заказ на дополнительное дополнение с обновленным до нового уровня ЦУБ приоритетом.
ВАЖНО!!! До момента поступления увеличенного заказа на склад система динамического управления буфером должна игнорировать нахождение запасов «в красном», то есть мы исключаем из рассмотрения один срок пополнения.
Еще кое-какие моменты, которые важно учитывать при работе ДУБ. Возможна ситуация, когда запасы находятся в красном или даже в черном, но по ним не происходит движения. Это возможно, если остаток на руках меньше, чем разовая покупка, а мы не пополняем товар, например, по причине аварии или иного сбоя у производителя товара. Такие ситуации можно было наблюдать с противовирусными препаратами, когда мощности поставщиков не хватило на пополнение резко увеличившегося спроса («стойкая дефектура» в терминологии фармотрасли). В этой ситуации рекомендации Динамического управления буфером должны быть проигнорированы или вообще механизм ДУБ должен быть отключен до момента устранения возникновения причин ситуации.
Теперь давайте рассмотрим обратную ситуацию: необходимость уменьшения ЦУБ.
Если продажи за срок пополнения значительно меньше, чем Целевой уровень буфера, то с очень высокой долей вероятности остатки «на руках» будут находиться высоко в зеленой зоне буфера. При этом сам факт нахождения остатков в зеленой зоне — это не криминал, это нормальное состояние, но если они находятся в зеленой зоне в течение срока пополнения, то это свидетельствует о некоторой избыточности защиты от неопределенности.
При этом нужно помнить, что небольшой избыток менее опасен, чем даже небольшая нехватка товара. Поэтому классический подход рекомендует здесь подход, хоть и схожий с предыдущим, но обладающий гораздо меньшей чувствительностью.
Математически определяем так: суммируем разницу между остатками «на руках» и границей между желтой и зеленой зонами буфера за один срок пополнения назад от сегодняшней даты. Если полученная «площадь» зеленого равна Целевому уровню буфера, то Целевой уровень буфера нужно снизить на треть.
Очевидно, что после снижения ЦУБ запасы «на руках», скорее всего, окажутся в состоянии «овербуфера» — в голубом. Это нормально, теперь мы должны дождаться, пока запасы с учетом уже заказанных и «доезжающих» снизятся ниже ЦУБ и возникнет необходимость снова проверять адекватность установленного ЦУБ.
На практике этот механизм хорошо работает для товаров, имеющих достаточно регулярное потребление без резких пиков и больших перерывов в продажах. Для них механизм Динамического управления буфером может быть включен в автоматическом режиме и не требовать подтверждения человеком, во всех остальных случаях нам потребуется экспертное участие человека.
Я соглашусь с утверждением, которое делает Эли Шрагенхайм в своей книге: «Ни один компьютер не обладает интуицией для определения „подозрительных“ ситуаций… Динамическое управление буфером как ни одна из практик управления ограничениями требует тщательной оценки и контроля»[2]
Описанный здесь «классический» механизм ДУБ прекрасно работает с розничной торговлей и регулярно потребляемыми товарами при относительно коротких сроках пополнения (относительно короткими сроками пополнения я считаю срок пополнения менее месяца). Но для товаров, не имеющих достаточно регулярного спроса, или сред, где спрос в принципе редкий, но при этом сроки пополнения короткие, для классического механизма ДУБ могут понадобиться механизмы «загрубления», чтобы избавиться от информационного «шума».
Пример из реальной практики: срок пополнения 21 день, но позиция Складская, если имеет не менее 6 продаж В ГОД, то есть продается в среднем раз в два месяца. Очевидно, что классический механизм уменьшения Целевого уровня буфера будет создавать в системе избыточный шум, но и использование «адаптированного», о котором речь пойдет далее, при таких сроках пополнения — неоправданно. В этом случае целесообразно использовать некие коэффициенты чувствительности.
Это верно и для настроек на увеличение буфера. Например, есть позиция, которая продается достаточно редко и немного, но по какой-то причине компания считает, что она должна быть в наличии, при этом за один раз может быть продан весь буфер. То есть остаток на руках попадет в черное на целый срок пополнения. Типовой алгоритм потребует увеличения ЦУБ, однако это нецелесообразно. Конечно, здесь можно вообще отключить механизм для этой позиции, но есть риск пропустить ситуацию с улучшением спроса. Поэтому здесь мы тоже можем применить коэффициент чувствительности.
Но это уже техники «для продвинутых». Я не рекомендую прибегать к ним самостоятельно, тут уж лучше обратиться к специалисту, а не заниматься самолечением.
[1] Eli Schragenheim, William H. Detmer, Wayne J. Patterson. Supply Chain Management At Warp Speed: integrating the system from end to end, 2009. P. 153–157.
[2] Eli Schragenheim, William H. Detmer, Wayne J. Patterson. Supply Chain Management At Warp Speed: integrating the system from end to end, 2009. P. 157.