«Классический» механизм Динамического управления буфером прекрасно справляется со своими задачами, пока срок пополнения остается сравнительно небольшим (менее одного месяца). Логика и алгоритмы его остаются работоспособными и на более длинных сроках, только здесь мы сталкиваемся с большим «но». Это «но» — время реакции системы.
Спросите себя, сколько времени потребуется, чтобы настроенная система отреагировала на происходящие изменения? Давайте попробуем собрать вместе все, что мы уже знаем к этому моменту. Один срок пополнения понадобится, чтобы система оценила необходимость изменения Целевого уровня буфера, еще один срок пополнения нужен для того, чтобы пополнить запасы до измененного уровня (или дождаться, чтобы возникла необходимость пополнения при снижении буфера). Итого: минимальный срок для адаптации системы к изменившейся среде — два срока пополнения.
Выше мы с вами уже считали надежный срок пополнения при поставках из Юго-Восточной Азии и получили результат в 230 дней, почти восемь месяцев. Согласитесь, ждать три четверти года, чтобы принять решение, а потом еще столько же, чтобы исправить ситуацию, — перспектива нерадостная.
Означает ли, что в этом случае мы обречены на постоянное прогнозирование и связанные с ним ошибки? Означает ли это, что описанное решение — неприменимо? Что радость хорошего уровня наличия при отсутствии излишков для нас — недостижимая роскошь?
У меня для вас хорошие новости — решение можно применять, и оно дает свои результаты, в первую очередь — улучшение уровня наличия. Но все «классические» решения требуют серьезных доработок и адаптации.
Так уж сложилась моя консультантская судьба в области Теории ограничений, что я в ситуацию очень длинных сроков пополнения попал сразу, и поэтому пришлось с коллегами сразу думать над тем, как эту проблему решать. Результатом стала предлагаемая ниже адаптация механизма Динамического управления буфером для очень длинных сроков пополнения.
Попробую ответить в структуре классических трех вопросов ТОС: что менять? на что менять? как осуществить изменения?
Что нужно изменить?
Классический механизм ДУБ построен на исходной посылке, что поведение запаса «на руках» достаточно хорошо отражает изменение ситуации со спросом и сроками пополнения. Однако в случае длинных сроков пополнения эта исходная посылка оказывается неверна. При этом время реакции на «понижение» оказывается чрезмерно большим и раздувает запасы, а реакция на повышение может быть спровоцирована случайным «пробоем», и корректировка такого «случайного» действия будет длительной. То есть мы изначально задаем ситуацию завышения запасов. Кроме того, при длинных сроках поставки сам классический механизм Динамического управления становится недопустимо медленным, а поскольку большая часть буфера при таких сроках у нас будет находиться в состоянии «в пути», то классическое деление буфера на три зоны плюс правило «нахождения в красном» — и мы получаем избыточные запасы.
На что менять?
Нам необходим механизм, который, опираясь на существующие в нашей организации данные, позволил бы достаточно быстро отслеживать изменения, происходящие в спросе, и своевременно пересматривать Целевой уровень буфера запасов. Поведение остатков, которым мы пользовались в «классическом» механизме, нам не подходит. Что остается в нашем распоряжении?
Давайте вернемся к самому началу: определению Целевого уровня буфера. Целевой уровень буфера — это максимальное потребление за надежный период пополнения. И мы уже обсуждали вопрос наглядности в разделе «Первоначальный расчет уровня ЦУБ» — график, который предложил Сергей Зайцев. Этот график полностью соответствует требованиям, которые мы предъявляем к механизму: он строится на внутренних данных компании и достаточно надежно отражает изменения в спросе. Похоже, что этот зверь — и есть объект нашей охоты. Мы можем создать механизм Динамического управления буфером, опираясь на поведение графика продаж на надежный срок пополнения.
Как провести изменения?
Если мы имеем дело с длинными (особенно ОЧЕНЬ длинными) сроками пополнения, то мы должны внести в алгоритм изменения, которые бы ориентировались на график продаж на надежный срок пополнения.
Если этот график приближается или превышает ЦУБ, то это означает, что продажи за надежный срок пополнения больше установленного ЦУБ и высока вероятность, что даже при полном наполнении ЦУБ заказанного товара нам не хватит. Следовательно, Целевой уровень буфера должен быть увеличен.
Если график продаж на надежный срок пополнения опускается до уровня красного или ниже, то установленный Целевой уровень буфера минимум в три раза превышает реальный спрос за надежный срок пополнения. Следовательно, Целевой уровень буфера должен быть уменьшен.
Увеличение и уменьшение Целевого уровня буфера происходит точно так же, как и в классическом варианте ДУБ — на величину одной зоны буфера, на одну треть.
Давайте остановимся на потенциальных негативных последствиях предлагаемого механизма Динамического управления буфером. Здесь возможны две ситуации ошибки: мы увеличили ЦУБ исходя из требований системы, а продажи «развернулись» и начали снижаться, и вторая, зеркальная, мы снизили ЦУБ, а продажи начали расти.
Прежде чем ответить на эти замечания, я еще раз напомню: Динамическое управление буфером имеет смысл и работает только при надлежащем использовании основного решения: частого заказа и поддержания буфера «полным», то есть постоянного наличия заказов «в пути». Если это не выполняется, то обсуждение Динамического управления буфером не имеет смысла.
А теперь давайте рассмотрим предложенные ситуации. Начнем с последней: мы буфер снизили, а продажи начали расти.
Ситуация остается абсолютно безопасной и контролируемой. Если мы не пропускали заказов, то на момент снижения буфера общий объем товара «на руках» в пути и заказах равен ЦУБ или меньше на объем потребления, произошедшего с момента последнего заказа. То есть почти в три раза больше, чем новый рекомендуемый уровень буфера, который равен актуальным продажам. Кроме того, даже этот уровень буфера почти в два раза больше, чем актуальный спрос. Если спрос начнет разворачиваться, в цепочке поставок достаточно запасов, чтобы обеспечить продажи в течение времени, которое необходимо, чтобы система рекомендовала ЦУБ к увеличению (для этого продажи должны вырасти в два раза).
Не так однозначно хороша ситуация, когда ЦУБ был увеличен, а продажи начали снижаться, здесь время реакции системы может быть недостаточным. Поэтому в случае повышения ЦУБ в процедуру Динамического управления буфером должна быть добавлена проверка, не произошло ли снижение продаж. Если мы увеличивали ЦУБ, пользуясь адаптированным механизмом Динамического управления буфером, то при следующем заказе нужно проверить — не произошло ли изменение тенденции. И если спрос начал снижаться, то необходимо вернуть ЦУБ в исходное состояние.
Еще один вопрос, который стоит обсудить в этом разделе: может ли адаптированный механизм Динамического управления буфером заменить классически?. Раньше я отвечал (и это можно увидеть в моей книге) коротко — нет. Однако с 2019 года произошли изменения и появился новый опыт.
В текущей ситуации, мы практически перестали использовать “классический” алгоритм ДУБ. Опыт работы со “скоропортом” показал, что “классика” не справляется с задачами быстрого реагирования.
Тогда мы доработали “адаптированный” алгоритм, добавив к нему параметры, которые значительно снижают “шум”, но при этом сохраняют необходимую скорость реакции.
Так что по состоянию на 2022 год мы уже окончательно перешли с “классического” алгоритма ДУБ на разработанный нами “адаптированный”. А “классический” остался для непродовольственных и нескоропортящихся товаров, как некий “архаизм”.
Ну, последнее замечание в этом разделе: компьютер по-прежнему не обладает интуицией, поэтому все знания о глобальных изменениях, которые происходят в реальности, должны вноситься в систему человеком, а при длинных сроках пополнения это становится особенно важным.