Мы уже не один раз говорили о том, что обеспечение высокого уровня наличия требует значительной защитной мощности. С практической точки зрения это означает, что мы не должны допускать возникновения активного внутреннего ограничения мощности.
В своем вебинаре 2018 года, посвященном использованию динамического моделирования, доктор Алан Барнард показывал, как сокращение защитной мощности приводит к возникновению хаоса в детерминированной (то есть управляемой жесткими функциональными зависимостями, а не вероятностными связями) системе.
В уже упоминавшейся книге «Управление цепями поставок с невероятной скоростью» Эли Шрагенхайм предлагает очень полезный механизм контроля за мощностью — метод Планируемой загрузки (Planned Load). Суть его состоит в том, что мы учитываем технологическое время, необходимое для производства всех заказов (в нашем случае — на пополнение склада) и сравниваем его со стандартным сроком производства (пополнения). Пока суммарное технологическое время по открытым заказам много меньше, чем срок пополнения, у нас все в порядке, но… Как только у нас появляется ресурс, планируемая загрузка по которому начинает достигать 80% от срока пополнения — это сигнал, что у нас потенциальные проблемы с мощностью и нужно предпринимать дополнительные усилия по поиску возможностей дополнительного увеличения мощности за счет вывода дополнительных смен, сверхурочных, поиска контрагентов и т.п. Я рекомендую ознакомиться с материалом на эту тему[1].
Какие мощности нам важны в первую очередь с точки зрения управления запасами в цепочках поставок:
Достаточность оборотного капитала. Необходимо постоянно мониторить достаточность оборотных средств для поддержания необходимого уровня запасов в цепи поставок. Нехватка или ограничение оборотного капитала способны похоронить любые перспективы. Это параметр следует постоянно держать под контролем. Если вы попадаете в ситуацию с нехваткой оборотного капитала, то первое, что вы должны делать — это предпринимать максимум усилий по выходу из этой ситуации. Это очень опасная и нежелательная ситуация.
Производственная мощность. Это способность выпустить требуемый ассортимент в разумные сроки.
Складская мощность. Если на ваших складах невозможно разместить хотя бы половину ваших буферов, то, скорее всего, проблемы с наличием вам гарантированы.
Транспортная мощность. Ее дефицит часто не сразу заметен, но между тем он также способен подорвать уровень наличия в цепочках поставки.
Это неполный перечень потенциальных ограничений мощности, с которыми может столкнуться компания, использующая в своей повседневной практике решения Теории ограничений по обеспечению наличия.
Любая система управления качеством, какую ни возьми, строится на первом базовом стандарте — стандарте о записях. Любой процесс непрерывного улучшения начинается с учета отклонений от стандарта.
При этом нужно всегда помнить про правило: не оптимизировать в пределах шума. Хорошо известный эксперимент с воронкой доктора Деминга это прекрасно демонстрирует. Следовательно, с одной стороны, нам нужно организовать учет событий, которые являются отклонением от стандартного поведения, с другой стороны, нужно исключить избыточный управленческий шум в системе.
В рамках решений Теории ограничений у нас есть прекрасный механизм управления буфером, который обеспечивает нас постоянной информацией о статусе запасов на руках. Нормой, с точки зрения управления буфером, является нахождение запасов в желтой зоне буфера, соответственно, как только запасы попали в красную зону буфера, у нас должна быть возможность зафиксировать причину попадания в красную зону. Таких причин может быть множество: поломка транспорта, поломки на производстве поставщика, дефицит сырья, пропущенный заказ, несвоевременно выполненные процедуры Динамического управления буфером, внезапный нетипичный всплеск спроса и т.д.
Обычно на старте набор причин плохо структурирован, но по мере накопления они начинают складываться в некий справочник.
Соответственно, если у нас фиксируются причины, то мы можем их группировать и анализировать, поочередно устраняя от самых частых ко все более и более редким причинам. На одном их проектов для этих целей была задействована CRM-система, где был создан особый тип события — «Косяк», куда фиксировались все проблемы, которые возникали в ходе выполнения заказов клиентов (даже если они не приводили к срыву заказа). Раз в неделю «Косяки» разбирались на самом высшем уровне и разрабатывались корректирующие мероприятия по их устранению.
Спустя 2–3-й срок пополнения после начала работы системы по новым правилам целесообразно начинать учет причин проникновения в красное и процедуры процесса непрерывного улучшения.
Марку Твену приписывают фразу: «Нет ничего проще, чем бросить курить — я сам это делал тридцать раз». Эта гениальная фраза описывает практически любую ситуацию по созданию долговременных и сохраняющихся улучшений.
Получение быстрого результата, безусловно, вдохновляет, но результат мало получить, его нужно удержать. И именно повторяющееся воспроизведение результата с требуемым качеством и является характеристикой системы управления компанией. Какой бы совершенный инструмент вы ни внедрили, если после его внедрения вы перестанете контролировать его адекватность окружающей вас реальности, он неизбежно превратится в исторический артефакт.
Доктор Голдратт говорил, что вчерашнее решение сегодня становится историческим курьезом. Все решения ТОС построены таким образом, чтобы давать быстрый и значительный результат. Внедрение решения управления наличием в цепях поставок способно дать заметный эффект на горизонте три-пять сроков пополнения. Однако история внедрений знает случаи, когда хорошие решения спустя какое-то время после внедрения забрасывались. Причины были разные, но основная — внедрили и забыли.
Между тем стандартная структура любого решения Теории ограничений предполагает следующие разделы:
Установка (mindset) — понимание существующей реальности, конфликтов, управляющих этой реальностью, а также направления их разрешения.
Получение быстрого результата — срываем «низко висящие плоды». Это самый любимый внедренцами этап, когда практически сразу после начала внедрения мы начинаем наблюдать улучшение ситуации.
Процесс непрерывного улучшения (в Теории ограничений обычно используется аббревиатура POOGI — process of on-going improvement).
Капитализация конкурентного предложения — разработка и распространение «предложения ценности» для значимых сегментов рынка.
Собственно, POOGI — это полный аналог кайдзен в бережливом производстве. Процесс непрерывного улучшения — это поиск возможностей для улучшения существующей ситуации, необязательно — крупных возможностей, часто это небольшие, осуществляемые шаг за шагом улучшения, позволяющие совершенствовать качество работы нашей системы.
Во всех решениях Теории ограничений, которые посвящены управлению наличием в цепях поставок, раздел Процесса непрерывного улучшения включает в себя четыре действия (инъекции)[1]:
Причины проникновения в «красное» фиксируются и регулярно (еженедельно) анализируются.
Проводится мониторинг мощностей с целью своевременного обнаружения возникновения ресурсов с ограниченной мощностью (CCR) и соответствующего управления мощностями.
Ассортимент предлагаемых товаров регулярно проверяется и регулируется с целью удовлетворения потребностей локальных рынков и обеспечения прибыльности.
Разрабатываются предложения ценности, основанные на логистических преимуществах.
Ну и последний вопрос посвященный Динамическому управлению буфером.
Как часто следует проводить оценку адекватности установленного уровня буфера?
Если мы говорим про работу с автоматизированной системой управления запасами, например NET Stock, то в ней предусмотрен механизм анализа необходимости изменения ЦУБ, и если такие буферы выявляются, то для пользователя создается задача, информирующая его о необходимости проверить и подтвердить или отменить рекомендации автоматизированной системы. В этом случае ДУБ работает в фоновом режиме и задачи по изменению возникают автоматически. Со временем, настроив уровни чувствительности, «шум» практически исчезает, и сам вопрос снимается: Динамическое управление буфером отрабатывает по потребности.
Но если у вас нет системы, которая бы могла выполнять эту работу автоматически, то можно дать следующие рекомендации:
При коротких сроках пополнения процедуры Динамического управления буфером следует запускать хотя бы раз в два срока пополнения, а при длительных сроках пополнения Динамическое управление буфером должно быть отработано перед каждым формированием заказа поставщикам.
Промоакции отличаются от обычных сезонных пиков спроса только тем, что этот пик — самоинициированный. Это значит, что его размах, сроки начала и продолжительность определяются нашей компанией. И если уровень всплеска относительно «обычных» продаж — величина все-таки вероятностная, тем не менее опытным путем она может быть установлена. Еще одна особенность промоакций — это провал продаж продукции, участвовавшей в акции после ее завершения в силу того, что в процессе акции потребители, подталкиваемые сниженными ценами, приобретают избыточное количество, которое должно быть потреблено.
Мы не будем разбирать вред от акций, просто порекомендую к прочтению материал по ссылке[1].
Здесь мы коротко остановимся только на вопросах, касающихся Динамического управления буфером.
Первая и основная проблема управления запасами при проведении промоакций — это несогласованность между отделом маркетинга или рекламы и подразделениями, управляющими цепью поставок. Творческие рекламисты и маркетологи часто просто забывают проинформировать заблаговременно закупщиков и производство об ожидающейся акции.
Если этот информационный разрыв в компании закрыт, то дальше техника предельно проста:
Определяем дату начала промоакции.
Даем прогноз изменения спроса, вызванный промоакцией (например, смотрим на графики потребления при проведении предыдущих акций).
Устанавливаем временный ЦУБ для всех мест хранения, участвующих в акции.
Пополняем все эти места хранения до полного буфера. ВАЖНО: весь запас должен находиться в местах продаж к моменту начала акции.
Начинаем акцию и следим за рекомендациями Динамического управления буфером.
Возвращаем ЦУБ в исходное состояние.
Подводим итоги проведения промоакции.
Хотелось бы чуть-чуть подробнее остановиться на пункте 5 и словосочетании «следим за рекомендациями Динамического управления буфером». Я раз за разом повторяю, что все наши прогнозы носят вероятностный характер, и мы можем ошибиться в оценке спроса. Как правило, в промоакции спрос достигает своего пика в первые же дни, а затем идет на спад. Учитывая это, установлено общее правило, которое можно описать так:
Мы устанавливаем ЦУБ на начало акции и пополняем запасы до ЦУБ. Примерно через половину времени акции мы снижаем уровень ЦУБ до середины между «старым» (предакционным) уровнем ЦУБ и ЦУБ, а на момент окончания акции мы возвращаем ЦУБ в исходное положение. Но… если ДУБ во время проведения акции рекомендует нам увеличивать буфер, то мы НЕ СНИЖАЕМ ЦУБ.
Сезонность — это тоже обычные и ожидаемые пики спроса, только более длительные по времени.
Однако в случае с сезонностью есть ряд вопросов, которые следует тщательно проработать.
Очевидно, что мы так же, как и при коротких пиках, должны, опираясь на опыт, статистику и прогнозы, изменить Целевые уровни буферов. Но часто этого оказывается недостаточным. Если бы проблема сводилась бы только к увеличению объема производства — задача была бы очень простой, но… Часто все не так просто. Рекомендую прочитать материал по ссылке[1].
Очень редко когда производитель в состоянии производить весь свой ассортимент за сколько-нибудь разумное время пополнения, а в момент, когда компания сталкивается с сезоном высокого спроса, то мощности часто просто недоступны. А мы ведь с вами помним: чтобы использовать решение пополнения по фактическому спросу, компания должна обладать значительным объемом защитной мощности.
Что это означает на практике? На практике чаще всего это означает: одним изменением ЦУБ нам не отделаться. Нам потребуется большая работа по анализу доступной и защитной мощности. И если выяснится, что мощности нам недостаточно, то нам придется принимать одно из следующих решений:
Сужать ассортимент. Уменьшать количество SKU, по которым мы гарантируем наличие, до того уровня, который позволяют наши мощности.
Создавать избыточный запас, который бы позволил пережить пиковое потребление. Это означает заблаговременное увеличение ЦУБ и «наработку» запасов. Поясню на простом примере из практики: клиент доставляет клей автотранспортом. Если в обычное время срок пополнения составляет менее 4 недель, то зимой товар просто замерзает и портится, поэтому если не прибегать к дорогостоящим способам транспортировки, срок пополнения увеличивается до шести месяцев, что означает необходимость сознательно увеличивать уровень запасов до полугодового уровня потребления и уход в «голубую» зону уровня буфера.
При длинных сроках пополнения, наоборот, влияние сезонности часто преувеличивается. Вроде бы с точки зрения продаж мы действительно наблюдаем сезонный рост и снижение потребления, но, взглянув на график продаж за срок пополнения при надежном сроке пополнения в девять месяцев, мы увидим, что колебания спроса минимальны, так как сглаживаются длительным сроком пополнения, и обычный механизм Динамического управления буфером с такой «сезонностью» вполне справляется.
Таким образом, в ситуации сезонности мы каждый раз должны проделывать одну и ту же последовательность действий:
Рассчитать ЦУБ с учетом сезонного колебания спроса.
Проверить достаточность мощности для пополнения ЦУБ в условиях пика спроса.
Принять решение по ширине ассортимента в пиковый и межпиковый сезон.
Окончательно рассчитать целевые уровни запасов и принять решение о способах их наполнения.
Применить изменения в системе управления запасами.
Какой бы алгоритм Динамического управления буфером мы ни использовали: классический или адаптированный, одна исходная посылка остается неизменной — Динамическое управление буфером работает на основе фактических данных недавнего прошлого, а компьютер не обладает интуицией и не отслеживает информацию об изменениях за пределами учетной системы.
Динамическое управление буфером прекрасно справляется с ситуациями, когда колебания спроса и/или срока пополнения остаются в пределах плюс-минус 25% от установленного, может быть, справится с изменением в 30%, но если колебания будут больше по амплитуде, то ДУБ — бессилен, он в принципе не может успеть отреагировать на такие колебания, да и не должен. Напоминаю, что буфер — это механизм защиты от обычной ожидаемой неопределенности.
Если же мы имеем дело с ситуацией, когда колебания превышают 25% в течение срока пополнения, автоматизированной системе понадобится помощь интуиции человека, его знания о внешней среде.
Собственно, мы можем выделить три таких ситуации:
Короткие резкие пики спроса.
Сезонные колебания спроса.
Промоакции.
Давайте проанализируем, что мы можем сделать с управлением запасами в цепочках поставок в этих ситуациях. Кроме того, я рекомендую к прочтению материал блога Эли Шрагенхайма[1].
Работа с короткими пиками спроса
Собственно, короткие пики спроса делятся на те, о которых мы знаем, и неожиданные. Мы ничего не можем поделать с неожиданными, абсолютно случайными пиками спроса, так как не существует математики, которая бы была в состоянии с достаточной надежностью предсказывать появление «черных лебедей» — крайне маловероятных, но очень сильных по своему воздействию событий. Если мы столкнулись в своей практике с такой ситуацией, все, что мы можем сделать, — это приложить максимум усилий, чтобы как можно быстрее вернуть нашу систему в стабильное и работающее состояние.
Но есть пиковый спрос, о котором мы прекрасно осведомлены, но тем не менее наша система пополнения запасов не в состоянии обеспечить пополнение запасов во время пика. Слово «короткий» является здесь ключевым. Короткий означает: короче, чем надежное время пополнения.
Можно привести довольно много таких примеров:
Новогоднее подарочное безумие.
Сопоставимое с ним по масштабам празднование 8 Марта, про пик потребления цветов можно и не упоминать. В отрасли, связанной с продажей цветов, говорят, что в период с 5 по 8 Марта они и зарабатывают свою годовую прибыль, весь остальной год уходит на покрытие операционных расходов.
Пасхальная компания (куличи и яйца).
День знаний, или 1 сентября.
Наверное, стоит вспомнить и про День святого Валентина.
Я думаю, что такого рода примеров каждый может привести достаточное количество. Что общего у всех этих пиков? Все они длятся меньше недели, иногда один-два дня, и вся продукция, не проданная в эти дни, уже вряд ли будет продана в другие даже по сниженным ценам, при этом отсутствие товара однозначно обозначает упущенные продажи и недовольных клиентов. При этом, как правило, ни одна производственная компания не в состоянии произвести продукцию за срок пикового спроса, а ни одна цепь поставок не в состоянии ее дистрибутировать с требуемой скоростью. Поэтому при работе с короткими известными пиками спроса единственный источник информации — это прогноз.
Так, например, компания, в которой я когда-то работал, занималась производством кондитерских изделий. В обычном режиме мы производили и продавали около 170 тонн своей продукции в месяц, но на Новый год и 8 Марта наши продажи составляли ВДВОЕ больше. Это достаточно хорошая статистика для грубой количественной оценки, хотя каждый пик в разрезе конкретной продукции мог быть выше или ниже.
Первый вопрос, на который мы должны себе ответить: какой риск мы готовы на себя принять? Дело в том, что если мы создадим недостаточные запасы — мы получим упущенные продажи/возможности, если запасы окажутся избыточными — мы понесем потери в объеме абсолютно-переменных затрат на поставку этой продукции. Поэтому мы должны выбрать для себя, на какой вариант мы ориентируемся.
Получив ответ на этот вопрос, мы можем понять, в какой пропорции нам нужно изменить Целевой уровень буфера. Общее правило можно сформулировать так: за один срок пополнения до начала цикла мы поднимаем ЦУБ в той пропорции, в какой мы ожидаем пик продаж относительно обычного потребления, а за один срок пополнения до его окончания — снижаем до первоначального уровня.
Реальное практическое воплощение этого правила будет зависеть от используемых вами средств автоматизации. Часто необходимость «отступить» от даты события на срок пополнения путает пользователей. Было бы хорошо, если бы изменение ЦУБ можно было устанавливать на даты возникновения пиков спроса, а автоматизированная система в момент формирования заказа поставщику «заглядывала» бы вперед и анализировала, какой ЦУБ будет действовать на ожидаемую дату поступления заказа. Такой способ изменения Целевого уровня буфера, как правило, более нагляден для сотрудников, а необходимость смещать изменения ЦУБ при длинных сроках пополнения на графиках выглядит часто очень странно и создает сложности при объяснении своих действий вышестоящим руководителям.
Важно, чтобы на момент начала ожидаемого пика спроса ВЕСЬ буфер был размещен в соответствующих местах хранения.
Еще один важный момент, который следует проверять: это ответ на вопрос, в течение какого времени имеющаяся в нашем распоряжении доступная мощность позволит наработать необходимый запас. Часто имеющаяся в нашем распоряжении мощность требует достаточно длительного времени накопления запасов, тогда и уровень буфера нам нужно будет поднимать ступенчато, с учетом возможностей нашего производства, хранения и/или цепи поставок.
Вне зависимости от того, какой механизм ДУБ: классический или адаптированный, мы изменяем Целевой уровень буфера на треть. Является ли это жестким правилом? Нет.
Просто изменение на одну треть, с одной стороны, достаточно значительно, с другой — вполне безопасно. Кроме того, это правило обеспечивает работу системы в режиме маятника с затухающими колебаниями.
Но если вы можете обосновать иной шаг, например исходя из минимальной партии, вы вправе установить свои правила. Но помните об общем правиле: прежде чем что-либо менять в устоявшейся методологии, проверьте, соблюдаются ли исходные посылки, для которых она была разработана, понимаете ли вы принципы и механизмы, заложенные в решение. Если ответ «да», то — дерзайте, но помните, что с этого момента за последствия отвечаете только вы сами.
«Классический» механизм Динамического управления буфером прекрасно справляется со своими задачами, пока срок пополнения остается сравнительно небольшим (менее одного месяца). Логика и алгоритмы его остаются работоспособными и на более длинных сроках, только здесь мы сталкиваемся с большим «но». Это «но» — время реакции системы.
Спросите себя, сколько времени потребуется, чтобы настроенная система отреагировала на происходящие изменения? Давайте попробуем собрать вместе все, что мы уже знаем к этому моменту. Один срок пополнения понадобится, чтобы система оценила необходимость изменения Целевого уровня буфера, еще один срок пополнения нужен для того, чтобы пополнить запасы до измененного уровня (или дождаться, чтобы возникла необходимость пополнения при снижении буфера). Итого: минимальный срок для адаптации системы к изменившейся среде — два срока пополнения.
Выше мы с вами уже считали надежный срок пополнения при поставках из Юго-Восточной Азии и получили результат в 230 дней, почти восемь месяцев. Согласитесь, ждать три четверти года, чтобы принять решение, а потом еще столько же, чтобы исправить ситуацию, — перспектива нерадостная.
Означает ли, что в этом случае мы обречены на постоянное прогнозирование и связанные с ним ошибки? Означает ли это, что описанное решение — неприменимо? Что радость хорошего уровня наличия при отсутствии излишков для нас — недостижимая роскошь?
У меня для вас хорошие новости — решение можно применять, и оно дает свои результаты, в первую очередь — улучшение уровня наличия. Но все «классические» решения требуют серьезных доработок и адаптации.
Так уж сложилась моя консультантская судьба в области Теории ограничений, что я в ситуацию очень длинных сроков пополнения попал сразу, и поэтому пришлось с коллегами сразу думать над тем, как эту проблему решать. Результатом стала предлагаемая ниже адаптация механизма Динамического управления буфером для очень длинных сроков пополнения.
Попробую ответить в структуре классических трех вопросов ТОС: что менять? на что менять? как осуществить изменения?
Что нужно изменить?
Классический механизм ДУБ построен на исходной посылке, что поведение запаса «на руках» достаточно хорошо отражает изменение ситуации со спросом и сроками пополнения. Однако в случае длинных сроков пополнения эта исходная посылка оказывается неверна. При этом время реакции на «понижение» оказывается чрезмерно большим и раздувает запасы, а реакция на повышение может быть спровоцирована случайным «пробоем», и корректировка такого «случайного» действия будет длительной. То есть мы изначально задаем ситуацию завышения запасов. Кроме того, при длинных сроках поставки сам классический механизм Динамического управления становится недопустимо медленным, а поскольку большая часть буфера при таких сроках у нас будет находиться в состоянии «в пути», то классическое деление буфера на три зоны плюс правило «нахождения в красном» — и мы получаем избыточные запасы.
На что менять?
Нам необходим механизм, который, опираясь на существующие в нашей организации данные, позволил бы достаточно быстро отслеживать изменения, происходящие в спросе, и своевременно пересматривать Целевой уровень буфера запасов. Поведение остатков, которым мы пользовались в «классическом» механизме, нам не подходит. Что остается в нашем распоряжении?
Давайте вернемся к самому началу: определению Целевого уровня буфера. Целевой уровень буфера — это максимальное потребление за надежный период пополнения. И мы уже обсуждали вопрос наглядности в разделе «Первоначальный расчет уровня ЦУБ» — график, который предложил Сергей Зайцев. Этот график полностью соответствует требованиям, которые мы предъявляем к механизму: он строится на внутренних данных компании и достаточно надежно отражает изменения в спросе. Похоже, что этот зверь — и есть объект нашей охоты. Мы можем создать механизм Динамического управления буфером, опираясь на поведение графика продаж на надежный срок пополнения.
Как провести изменения?
Если мы имеем дело с длинными (особенно ОЧЕНЬ длинными) сроками пополнения, то мы должны внести в алгоритм изменения, которые бы ориентировались на график продаж на надежный срок пополнения.
Если этот график приближается или превышает ЦУБ, то это означает, что продажи за надежный срок пополнения больше установленного ЦУБ и высока вероятность, что даже при полном наполнении ЦУБ заказанного товара нам не хватит. Следовательно, Целевой уровень буфера должен быть увеличен.
Если график продаж на надежный срок пополнения опускается до уровня красного или ниже, то установленный Целевой уровень буфера минимум в три раза превышает реальный спрос за надежный срок пополнения. Следовательно, Целевой уровень буфера должен быть уменьшен.
Увеличение и уменьшение Целевого уровня буфера происходит точно так же, как и в классическом варианте ДУБ — на величину одной зоны буфера, на одну треть.
Давайте остановимся на потенциальных негативных последствиях предлагаемого механизма Динамического управления буфером. Здесь возможны две ситуации ошибки: мы увеличили ЦУБ исходя из требований системы, а продажи «развернулись» и начали снижаться, и вторая, зеркальная, мы снизили ЦУБ, а продажи начали расти.
Прежде чем ответить на эти замечания, я еще раз напомню: Динамическое управление буфером имеет смысл и работает только при надлежащем использовании основного решения: частого заказа и поддержания буфера «полным», то есть постоянного наличия заказов «в пути». Если это не выполняется, то обсуждение Динамического управления буфером не имеет смысла.
А теперь давайте рассмотрим предложенные ситуации. Начнем с последней: мы буфер снизили, а продажи начали расти.
Ситуация остается абсолютно безопасной и контролируемой. Если мы не пропускали заказов, то на момент снижения буфера общий объем товара «на руках» в пути и заказах равен ЦУБ или меньше на объем потребления, произошедшего с момента последнего заказа. То есть почти в три раза больше, чем новый рекомендуемый уровень буфера, который равен актуальным продажам. Кроме того, даже этот уровень буфера почти в два раза больше, чем актуальный спрос. Если спрос начнет разворачиваться, в цепочке поставок достаточно запасов, чтобы обеспечить продажи в течение времени, которое необходимо, чтобы система рекомендовала ЦУБ к увеличению (для этого продажи должны вырасти в два раза).
Не так однозначно хороша ситуация, когда ЦУБ был увеличен, а продажи начали снижаться, здесь время реакции системы может быть недостаточным. Поэтому в случае повышения ЦУБ в процедуру Динамического управления буфером должна быть добавлена проверка, не произошло ли снижение продаж. Если мы увеличивали ЦУБ, пользуясь адаптированным механизмом Динамического управления буфером, то при следующем заказе нужно проверить — не произошло ли изменение тенденции. И если спрос начал снижаться, то необходимо вернуть ЦУБ в исходное состояние.
Еще один вопрос, который стоит обсудить в этом разделе: может ли адаптированный механизм Динамического управления буфером заменить классически?. Раньше я отвечал (и это можно увидеть в моей книге) коротко — нет. Однако с 2019 года произошли изменения и появился новый опыт.
В текущей ситуации, мы практически перестали использовать “классический” алгоритм ДУБ. Опыт работы со “скоропортом” показал, что “классика” не справляется с задачами быстрого реагирования.
Тогда мы доработали “адаптированный” алгоритм, добавив к нему параметры, которые значительно снижают “шум”, но при этом сохраняют необходимую скорость реакции.
Так что по состоянию на 2022 год мы уже окончательно перешли с “классического” алгоритма ДУБ на разработанный нами “адаптированный”. А “классический” остался для непродовольственных и нескоропортящихся товаров, как некий “архаизм”.
Ну, последнее замечание в этом разделе: компьютер по-прежнему не обладает интуицией, поэтому все знания о глобальных изменениях, которые происходят в реальности, должны вноситься в систему человеком, а при длинных сроках пополнения это становится особенно важным.
Начнем мы, естественно, с классического механизма Динамического управления буфером. Все описанные здесь алгоритмы, подходы и рекомендации основаны на изложенных в уже упомянутой книге «Управление цепью поставок с невероятной скоростью»[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.
