Вне зависимости от того, какой механизм ДУБ: классический или адаптированный, мы изменяем Целевой уровень буфера на треть. Является ли это жестким правилом? Нет.

Просто изменение на одну треть, с одной стороны, достаточно значительно, с другой — вполне безопасно. Кроме того, это правило обеспечивает работу системы в режиме маятника с затухающими колебаниями.

Но если вы можете обосновать иной шаг, например исходя из минимальной партии, вы вправе установить свои правила. Но помните об общем правиле: прежде чем что-либо менять в устоявшейся методологии, проверьте, соблюдаются ли исходные посылки, для которых она была разработана, понимаете ли вы принципы и механизмы, заложенные в решение. Если ответ «да», то — дерзайте, но помните, что с этого момента за последствия отвечаете только вы сами.

«Классический» механизм Динамического управления буфером прекрасно справляется со своими задачами, пока срок пополнения остается сравнительно небольшим (менее одного месяца). Логика и алгоритмы его остаются работоспособными и на более длинных сроках, только здесь мы сталкиваемся с большим «но». Это «но» — время реакции системы.

Спросите себя, сколько времени потребуется, чтобы настроенная система отреагировала на происходящие изменения? Давайте попробуем собрать вместе все, что мы уже знаем к этому моменту. Один срок пополнения понадобится, чтобы система оценила необходимость изменения Целевого уровня буфера, еще один срок пополнения нужен для того, чтобы пополнить запасы до измененного уровня (или дождаться, чтобы возникла необходимость пополнения при снижении буфера). Итого: минимальный срок для адаптации системы к изменившейся среде — два срока пополнения.

Выше мы с вами уже считали надежный срок пополнения при поставках из Юго-Восточной Азии и получили результат в 230 дней, почти восемь месяцев. Согласитесь, ждать три четверти года, чтобы принять решение, а потом еще столько же, чтобы исправить ситуацию, — перспектива нерадостная.

Означает ли, что в этом случае мы обречены на постоянное прогнозирование и связанные с ним ошибки? Означает ли это, что описанное решение — неприменимо? Что радость хорошего уровня наличия при отсутствии излишков для нас — недостижимая роскошь?

У меня для вас хорошие новости — решение можно применять, и оно дает свои результаты, в первую очередь — улучшение уровня наличия. Но все «классические» решения требуют серьезных доработок и адаптации.

Так уж сложилась моя консультантская судьба в области Теории ограничений, что я в ситуацию очень длинных сроков пополнения попал сразу, и поэтому пришлось с коллегами сразу думать над тем, как эту проблему решать. Результатом стала предлагаемая ниже адаптация механизма Динамического управления буфером для очень длинных сроков пополнения.

Попробую ответить в структуре классических трех вопросов ТОС: что менять? на что менять? как осуществить изменения?

Что нужно изменить?

Классический механизм ДУБ построен на исходной посылке, что поведение запаса «на руках» достаточно хорошо отражает изменение ситуации со спросом и сроками пополнения. Однако в случае длинных сроков пополнения эта исходная посылка оказывается неверна. При этом время реакции на «понижение» оказывается чрезмерно большим и раздувает запасы, а реакция на повышение может быть спровоцирована случайным «пробоем», и корректировка такого «случайного» действия будет длительной. То есть мы изначально задаем ситуацию завышения запасов. Кроме того, при длинных сроках поставки сам классический механизм Динамического управления становится недопустимо медленным, а поскольку большая часть буфера при таких сроках у нас будет находиться в состоянии «в пути», то классическое деление буфера на три зоны плюс правило «нахождения в красном» — и мы получаем избыточные запасы.

На что менять?

Нам необходим механизм, который, опираясь на существующие в нашей организации данные, позволил бы достаточно быстро отслеживать изменения, происходящие в спросе, и своевременно пересматривать Целевой уровень буфера запасов. Поведение остатков, которым мы пользовались в «классическом» механизме, нам не подходит. Что остается в нашем распоряжении?

Давайте вернемся к самому началу: определению Целевого уровня буфера. Целевой уровень буфера — это максимальное потребление за надежный период пополнения. И мы уже обсуждали вопрос наглядности в разделе «Первоначальный расчет уровня ЦУБ» — график, который предложил Сергей Зайцев. Этот график полностью соответствует требованиям, которые мы предъявляем к механизму: он строится на внутренних данных компании и достаточно надежно отражает изменения в спросе. Похоже, что этот зверь — и есть объект нашей охоты. Мы можем создать механизм Динамического управления буфером, опираясь на поведение графика продаж на надежный срок пополнения.

Как провести изменения?

Если мы имеем дело с длинными (особенно ОЧЕНЬ длинными) сроками пополнения, то мы должны внести в алгоритм изменения, которые бы ориентировались на график продаж на надежный срок пополнения.

Если этот график приближается или превышает ЦУБ, то это означает, что продажи за надежный срок пополнения больше установленного ЦУБ и высока вероятность, что даже при полном наполнении ЦУБ заказанного товара нам не хватит. Следовательно, Целевой уровень буфера должен быть увеличен.

Если график продаж на надежный срок пополнения опускается до уровня красного или ниже, то установленный Целевой уровень буфера минимум в три раза превышает реальный спрос за надежный срок пополнения. Следовательно, Целевой уровень буфера должен быть уменьшен.

Увеличение и уменьшение Целевого уровня буфера происходит точно так же, как и в классическом варианте ДУБ — на величину одной зоны буфера, на одну треть.

Давайте остановимся на потенциальных негативных последствиях предлагаемого механизма Динамического управления буфером. Здесь возможны две ситуации ошибки: мы увеличили ЦУБ исходя из требований системы, а продажи «развернулись» и начали снижаться, и вторая, зеркальная, мы снизили ЦУБ, а продажи начали расти.

Прежде чем ответить на эти замечания, я еще раз напомню: Динамическое управление буфером имеет смысл и работает только при надлежащем использовании основного решения: частого заказа и поддержания буфера «полным», то есть постоянного наличия заказов «в пути». Если это не выполняется, то обсуждение Динамического управления буфером не имеет смысла.

А теперь давайте рассмотрим предложенные ситуации. Начнем с последней: мы буфер снизили, а продажи начали расти.

Ситуация остается абсолютно безопасной и контролируемой. Если мы не пропускали заказов, то на момент снижения буфера общий объем товара «на руках» в пути и заказах равен ЦУБ или меньше на объем потребления, произошедшего с момента последнего заказа. То есть почти в три раза больше, чем новый рекомендуемый уровень буфера, который равен актуальным продажам. Кроме того, даже этот уровень буфера почти в два раза больше, чем актуальный спрос. Если спрос начнет разворачиваться, в цепочке поставок достаточно запасов, чтобы обеспечить продажи в течение времени, которое необходимо, чтобы система рекомендовала ЦУБ к увеличению (для этого продажи должны вырасти в два раза).

Не так однозначно хороша ситуация, когда ЦУБ был увеличен, а продажи начали снижаться, здесь время реакции системы может быть недостаточным. Поэтому в случае повышения ЦУБ в процедуру Динамического управления буфером должна быть добавлена проверка, не произошло ли снижение продаж. Если мы увеличивали ЦУБ, пользуясь адаптированным механизмом Динамического управления буфером, то при следующем заказе нужно проверить — не произошло ли изменение тенденции. И если спрос начал снижаться, то необходимо вернуть ЦУБ в исходное состояние.

Еще один вопрос, который стоит обсудить в этом разделе: может ли адаптированный механизм Динамического управления буфером заменить классически?. Раньше я отвечал (и это можно увидеть в моей книге) коротко — нет. Однако с 2019 года произошли изменения и появился новый опыт.

В текущей ситуации, мы практически перестали использовать “классический” алгоритм ДУБ. Опыт работы со “скоропортом” показал, что “классика” не справляется с задачами быстрого реагирования.

Тогда мы доработали “адаптированный” алгоритм, добавив к нему параметры, которые значительно снижают “шум”, но при этом сохраняют необходимую скорость реакции.

Так что по состоянию на 2022 год мы уже окончательно перешли с “классического” алгоритма ДУБ на разработанный нами “адаптированный”. А “классический” остался для непродовольственных и нескоропортящихся товаров, как некий “архаизм”.

Ну, последнее замечание в этом разделе: компьютер по-прежнему не обладает интуицией, поэтому все знания о глобальных изменениях, которые происходят в реальности, должны вноситься в систему человеком, а при длинных сроках пополнения это становится особенно важным.

Система приоритетов строится на механизме Управления буфером, который предоставляет информацию о текущем состоянии буфера запаса и выдает цветовой код.

В системе существует два статуса:

• статус буфера запаса «на руках»;
• статус буфера запаса для заказа на пополнение.

Принцип определения статусов в обоих случаях идентичен, он основан на проникновении в буфер.

Для статуса буфера запаса товаров «на руках»:

Статус буфера = (Целевой уровень буфера – Свободный остаток на руках)/Целевой уровень буфера * 100%

Для статуса заказа:

Статус буфера заказа = (Целевой уровень буфера – Свободный остаток на руках – Заказано ранее (в пути))/Целевой уровен буфера * 100%

Небольшое замечание по поводу использования показателя Свободный остаток на руках. Свободный остаток на руках — это фактический остаток на складе минус количество товара/продукции, находящихся в резерве под конкретного клиента. Использование этого показателя часто вызывает споры, связанные с тем, что товар же фактически есть, его просто заблокировали, но вдруг клиент откажется, и что: мы привезем излишек?

Товар, поставленный в резерв, это товар, обещанный клиенту, в течение какого времени товар должен находиться в резерве, определяется внутренними правилами компании. Его статус лучше всего описывается цитатой из фильма «Не бойся, я с тобой»: «Это не твой зуб, он даже не мой, он — ихний…» Формально этот товар уже не принадлежит компании, он ожидает, пока клиент выполнит все свои обязательства, чтобы быть торжественно ему доставленным и врученным. И если вы знаете, что в вашей компании менеджеры по продажам злоупотребляют резервированием товара, то спросите себя: почему так происходит? Обычно причиной такого поведения является хроническая нехватка товара вкупе с индивидуальной мотивацией специалиста по продажам. Две эти причины вместе взятые приводят к тому, что менеджеры по продажам защищают свои объемы продаж от «нападения» коллег путем избыточного резервирования товаров. Если это про вас, я вас поздравляю — вам предстоит большая и увлекательная работа по разъяснению и обучению. Если же клиент все-таки отказался от покупки, а вы уже заказали товар, то в большинстве случаев — это не трагедия, просто пропустите заказ этого SKU в следующей поставке.

Полученное значение сравнивается с границами зон буфера:

• если проникновение более 100%, то цветовой код — черный;
• если проникновение находится между 100% и уровнем красного, то цветовой код — красный;
• если проникновение меньше, чем уровень красного, но больше или равно уровню желтого, то цветовой код — желтый;
• если проникновение меньше, чем уровень желтого, но больше или равно нулю, то цветовой код — зеленый;
• если проникновение отрицательное (такое бывает), то цветовой код — голубой.

Приоритет заказов нарастает от зеленого к черному, голубой в принципе не подлежит заказу. Если два заказа или два SKU имеют одинаковый цветовой код приоритета, то больший приоритет имеет тот заказ/SKU, процент проникновения в буфер которого больше.

В идеальном мире, который, к сожалению, в реальности не существует, мы должны заказать все товары/продукцию, которые существуют до целевого уровня буфера. Но в жизни нам иногда не хватает денег, иногда не все помещается в одно транспортное средство, а для того, чтобы заказать второе, нам не хватает объема. Поэтому для повседневной работы мы устанавливаем простое правило работы для наших специалистов по закупкам: вся потребность к заказу одному поставщику сортируется в порядке убывания приоритета (проникновения в буфер), и заказ формируется построчно сверху вниз, пока не наберется транспортная партия и/или не будет исчерпан бюджет доступных денежных средств на оплату заказа поставщику.

Часто возникает вопрос: зачем нам два статуса в Помощнике заказов? Ведь, мол, все равно мы ориентируемся на статус потребности к заказу, а не статус запаса «на руках».

Во-первых, существует часто встречающаяся ошибка считать, что буфер запасов — это запас на какое-то время. Это неверно. Хотя действительно при расчете ЦУБ мы ориентируемся на некоторый временной горизонт, но спрос обычно имеет вероятностное, а не линейное поведение. Это означает, что статус буфера запасов может измениться скачкообразно, просто в силу аномально высокого локального спроса.

Во-вторых, это механизм дополнительного мониторинга правильного использования решения по управлению наличием. Если статус запаса на руках в красном и статус заказа в красном, то это чаще всего означает, что по какой-либо причине был пропущен заказ, который должен был быть сделан раньше, а может быть, мы встретились с «черным лебедем» — маловероятным событием аномально высокого спроса, и тогда, возможно, нам нужно переходить к следующему пункту.

В-третьих, если заказы все были сделаны вовремя, но статус запаса «на руках» в красном или, не дай бог, в черном, то, возможно, нам требуется предпринять дополнительные усилия по экспедированию доставки. Как правило, для большинства SKU неплохо иметь основного и хотя бы одного (а лучше — нескольких) резервного поставщика. Обычно основной поставщик — дешевый, но относительно долгий, поэтому резервные должны быть значительно быстрее, пусть и дороже. Если резервных поставщиков нет, то нужно постараться приложить усилия по ускорению доставки ранее сделанных заказов.

К этому моменту мы уже определились с тем, в отношении каких SKU мы намерены взять на себя обязательства по обеспечению постоянного наличия при отсутствии излишков.

Мы рассчитали для них Целевой уровень буфера, и с этого момента у нас есть в компании общепринятое, разделяемое всеми понимание, что такое «много» и что такое «мало». Пока запасы и товары в заказах в пределах Целевого уровня буфера — это не много, когда запасы находятся в красной зоне буфера и в заказах товаров нет — это мало.

Теперь мы готовы к тому, чтобы заказывать товар, используя механизм буфера и пополнения в соответствии с потреблением. Сама механика расчета очень проста:

Количество к заказу = Целевой уровень буфера – Свободный остаток на руках – Количество в исполняющихся заказах

Вот так может выглядеть рабочее место специалиста, который занимается заказами:

Для специалиста по закупкам достаточно ежедневно или по установленному графику формировать этот расчет и отправлять заказ в звено поставки выше по потоку: поставщику или на центральный/региональный склад, а для производства «для наличия» — формировать производственное задание на производство конкретной номенклатуры.

Более того, современные технологии позволяют поставщику самостоятельно сформировать задание на поставку, при условии что клиентское место хранения в цепи поставок обеспечивает его актуальной информацией о потреблении. На этом основан целый пласт решений, который носит обобщающее название «Управление запасами со стороны Поставщика» (Vendor Manegement Inventory — VMI).

Для того чтобы механизм пополнения в соответствии с потреблением заработал, необходимо реализовать два обязательных условия:

1. Предоставление информации о фактическом потреблении в месте хранения на ежедневной основе.
2. Реализован механизм учета заказов, находящихся в разном статусе исполнения.

Что касается первого вопроса, то при реализации решения в рамках одной организации он не вызывает никаких проблем, кроме сугубо технических, легко решаемых ИТ-службой организации. В тех случаях, когда мы имеем дело с управлением цепью поставок, выходящей за пределы организации, может потребоваться (и чаще всего — требуется) приложить дополнительные переговорные усилия, чтобы контрагент согласился предоставлять такую информацию, для этого ему нужно ясно показать выгоду от такого сотрудничества, которая с лихвой перекрывает дополнительную трудоемкость от ежедневного формирования и пересылки отчета о потреблении. Повторю еще раз, при наличии желания современные ИТ-технологии, онлайн-кассы и т.п. позволяют автоматизировать этот процесс с сохранением конфиденциальности и практически нулевой трудоемкостью.

Второй вопрос на моей личной практике часто неоправданно вызывает значительное сопротивление. Дело в том, что в большинстве учетных систем функционал заказа Поставщику существует, но часто не используется. Часто заказы все еще формируются вне автоматизированных систем — в таблицах EXCEL, электронной почты и т.п. А запуск системы пополнения на основе фактического спроса потребует, чтобы этот функционал присутствовал и работал.

Поэтому если вы не использовали этот функционал, то запускать его в работу следует параллельно с расчетом Целевых уровней буфера. Иначе заказы придется считать вручную, что создаст сотрудникам дополнительную трудоемкость, а это, в свою очередь, приведет к сопротивлению использованию системы.

Итак, на предыдущем шаге мы рассчитали и установили Целевой уровень буфера, но это еще не окончательное установление буфера.

Пока мы отработали только прогностическую функцию буфера, но у нас есть еще функции раннего оповещения и установления приоритетов поставки/производства. В Теории ограничений для этого используется цветовая кодировка статуса буфера/заказа. Для этого в буфере выделяются соответствующие зоны.

Классическое управление буфером работает с пятью цветами: черный, красный, желтый, зеленый и голубой, которые в случае с буфером запасов интерпретируются следующим образом:

Черный — означает, что товара уже нет в наличии и компания попала в ситуацию упущенных продаж по данному конкретному SKU.

Красный — существует риск не успеть пополнить запасы по данной номенклатуре.

Желтый — запасы находятся в «правильном» состоянии.

Зеленый — запас достаточен.

Голубой — запасы превышают целевой уровень буфера (излишки — овербуфер).

Традиционно Целевой уровень буфера делится на три равные части: нижняя треть красная, средняя — желтая, верхняя — зеленая. Черная граница обычно проходит на нуле, а голубое — все, что больше ЦУБ.

В большинстве случаев этого достаточно, но есть нюансы.

Первый из них связан с установлением черной границы. Я думаю, что многие сталкивались с ситуацией, когда остаток на складе ненулевой, а продаж нет, но как только остаток превышает некоторое значение — продажи сразу начинаются. Это происходит чаще всего потому, что покупатели покупают сразу некоторый объем и не меньше. Поэтому мы в практике используем и реализовали в программном продукте подход, который позволяет учесть эту особенность покупательского поведения, основываясь на исторических данных о продажах.

Для этого используется все тот же показатель целевой надежности, который я уже упоминал — какой процент спроса мы хотим гарантированно обслужить. Нам нужно проанализировать ежесуточное потребление товара, и величина, которая покрывает вероятность, равную персентилю надежности, и является рекомендуемой границей черного. На графике это видно нагляднее:

Что это будет означать? Это означает, что если остатки у нас ниже рекомендованной границы черного, то с вероятностью 95% мы не сможем обеспечить суточный спрос и получим упущенные продажи. В практике розничной торговли иногда добавляют еще одну — серую зону, которая равна величине выкладки на полках. В отличие от черной зоны, попадание в серую зону не означает высокую вероятность упущенных продаж.

Вторая ситуация связана с величиной зеленой зоны. Бывают ситуации, когда товар имеет очень большую минимальную партию поставки относительно срока пополнения и потребления за срок пополнения. Например, потребление за срок пополнения составляет 100 литров, а минимальная партия поставки 1000 литров. Что делать в такой ситуации?

Первый вариант — это увеличивать срок пополнения на время накопления минимальной партии, это позволит рассчитать буфер с учетом времени накопления минимальной партии, но… это имеет негативные последствия на этапе управления буфером в обычной деятельности. Если буфер будет разделен на традиционные равные три зоны, то цветовая индикация приоритетов поставки будет придавать излишнюю срочность поставке этой номенклатуры, хотя фактически ее в наличии еще достаточно большое количество.

Другой вариант — установить ЦУБ на уровне потребления, но тогда закупка минимальной партии а) никогда не наступит, пока товар не кончится; б) система постоянно будет сигнализировать о наличии значительных излишков, этот шум нужно будет постоянно отсеивать, о нем нужно будет помнить, а внимание менеджмента — это ключевое ограничение организации.

Мы выработали на практике вариант, который показал свою работоспособность. Если рассчитанный Целевой уровень буфера оказался меньше, чем полторы минимальных партии поставки SKU, то мы рекомендуем границы черной, красной и желтой зон установить в соответствии с рассчитанным ЦУБ, а величину зеленой зоны установить в размере минимальной партии поставки, то есть приплюсовать минимальную партию к уровню желтого. Это позволит установить правильные приоритеты и не рисковать ни отсутствием, ни избытком запасов, а также избежать излишнего «шума» в системе управления буферами.

И, наконец, третья ситуация — граница красного при очень длинных сроках пополнения. Когда сроки пополнения слишком большие, то большая часть товара при правильной работе будет находиться в пути, а «на руках» будет 20%, а иногда и меньше. В этом случае классическое зонирование будет также генерировать слишком много предупреждающих сигналов, которые будут отвлекать и напрягать менеджеров. В книге «Управление цепями поставок с невероятной скоростью»[1] Эли Шрагенхайм рекомендует в этом случае сдвинуть границу красного с 33% до 20% или даже 15% от буфера, но делать это не в самом начале, а когда убедились в процессе эксплуатации, что нахождение в этой зоне при правильном пополнении никогда не приводит к попаданию в ситуацию отсутствия товара «на руках».

Итак, мы подошли к точке, когда надежные сроки пополнения, целевые уровни буфера и границы его зон рассчитаны и установлены для всех SKU и мест хранения, участвующих во внедрении решения по обеспечению наличия в цепях поставок. Мы готовы переходить к заказу и пополнению в соответствии с реальным фактическим спросом во всех звеньях цепочки поставок.

---

[1] Eli Schragenheim, William H. Detmer, Wayne J. Patterson. Supply Chain Management At Warp Speed: integrating the system from end to end, 2009.

Хотелось бы напомнить одно важное правило, которым мы руководствуемся при расчете всех значений в решениях Теории ограничений: лучше быть приблизительно правым, чем абсолютно точно ошибаться. Это означает, что не следует стремиться к абсолютной точности рассчитываемых значений. Нужно учитывать, что все эти значения носят вероятностный характер и, следовательно, неизбежно имеют некоторую естественную и неустранимую погрешность. Лично я руководствуюсь правилом, что нужно опираться на достаточно пессимистические сценарии при оценке сроков пополнения и на обоснованно оптимистические при расчете спроса. Со мной можно и нужно не соглашаться, но я считаю необходимым обозначить основную свою исходную посылку: нехватка товара гораздо вреднее, нежели его незначительный избыток, особенно на старте проекта, когда все исходные данные ненадежны и недостоверны.

Итак, теперь, когда у нас есть рассчитанный надежный срок пополнения, мы можем приступать к расчету Целевого уровня буфера.

Если мы обратимся к типовым Деревьям Стратегии и Тактики, вынесенным в дополнение, то мы увидим там рекомендацию по расчету:

Целевой уровень запасов (Целевой уровень буфера) равен среднедневному потреблению за последний месяц, умноженному на надежный срок пополнения в днях, плюс три сигмы вариации потребления за срок пополнения и умноженному на коэффициент паранойи. В случае нормального распределения (а три сигмы говорят о гипотезе нормального распределения) отклонение в три сигмы составляет коэффициент 1,5. То есть мы получаем формулу:

ЦелевойУровеньБуфера = СреднедневноеПотребление * НадежныйСрокПополнения * 1,5

Если речь идет о ситуации, когда мы рассматриваем товар с относительно регулярным потреблением, большим количеством наблюдения, то гипотеза о нормальном распределении имеет все основания быть подтвержденной, и эта формула дает достаточно надежный расчет. Но…

Например, товар у нас был в наличии всего несколько дней месяца. Следует ли нам при расчете среднего потребления брать только дни наличия или считать среднее потребление за весь период? В последнем случае это приведет к явному занижению уровня спроса, но если взять в расчет среднее потребление только в дни наличия, то это может привести к еще очень большому завышению расчетной величины ЦУБ. В ситуации с короткими сроками пополнения — это не критично, но что делать, если ваши сроки пополнения превышают полгода? Тут требуется более универсальное решение.

В ситуации, когда:

• у нас явно присутствует сезонность в спросе;
• были длительные перерывы в наличии товара или вообще уровень наличия данного товара был крайне низкий;
• у нас длительные сроки пополнения (из моего личного опыта длительным можно считать срок пополнения более 30 дней — Д.Е.);

…расчет по этой формуле способен создать нам ненужные проблемы, которые потом придется исправлять с помощью Динамического управления буфером.

Кроме того, стоит учесть, что человеческий мозг визуальную информацию обрабатывает на порядки быстрее и качественнее, нежели цифровую или табличную.

Когда мы столкнулись в реальной практике внедрений с этой ситуацией, то мой коллега Сергей Зайцев предложил другой способ расчета, основанный на определении Целевого уровня буфера и наглядной визуализации, который и был нами реализован программными средствами и с тех пор стал основным в моей практике.

Итак:

Целевой уровень буфера — это максимальное потребление товара в данном месте хранения за надежный период пополнения.

Это можно представить в виде графика, который скользящим окном, равным надежному сроку пополнения, суммирует потребление на каждую дату, отражая, таким образом, поведение аккумулированного спроса за период потребления.

Этот способ также не защищает вас на все 100% от искажений. Например, в анализируемом периоде могла находиться ситуация с аномально большой продажей, и если вы положитесь на автоматический расчет величины ЦУБ — он будет завышен. Но есть и плюсы:

• наглядно видно влияние сезонности и трендов изменения спроса;
• если изначально задать уровень надежности, который вы хотите обеспечивать, в формате персентиля надежности (например, 0,95, что означает, что вы хотите гарантированно обслуживать 95% обычного спроса), то можно отбрасывать пики с помощью автоматизированной обработки.

Для примера приведу несколько графиков из реальных проектов.

Вот, например, достаточно хорошо продающаяся позиция:

А вот ее противоположность: редко продающаяся, с большими всплесками:

А вот пример аномального выброса продаж, когда требуется принятие управленческого решения:

Итак, давая определение понятию «буфер запасов», мы установили два параметра, влияющих на величину Целевого уровня буфера: надежный срок пополнения и спрос на конкретный SKU в конкретном звене цепочки поставок (месте хранения).

Надежный срок пополнения (reliable replenishment time (RRT)) — это время, в течение которого единица товара при необходимости может быть надежно пополнена (с вероятностью 90–95%)[1].

Наиболее часто встречающаяся ошибка — это отождествление срока поставки с надежным сроком пополнения. Это совершенно неверно. Обычно срок поставки — это время с момента размещения заказа у поставщика (звене цепи поставок выше по потоку) до момента поступления товара/продукции на склад. Надежное время пополнения — это время, которое пройдет с момента, когда товар прибыл на склад, до момента поступления следующей партии товара. Как правило, RRT значительно длиннее срока поставки. Занижение времени пополнения на старте проекта по внедрению решений по обеспечению наличия чревато высоким риском получить нехватку товара!!!

Что включает в себя надежный срок пополнения? Вот типовой состав (с конца процесса):

• время приходования товара на складе;
• время в пути;
• время исполнения заказа поставщиком;
• время согласования заказа;
• время ожидания между заказами.

Давайте рассмотрим эти пункты подробнее.

Время приходования товара на склад включает в себя:

• разгрузку транспортных средств;
• приемку товара на складе по качеству и количеству;
• отражение поступлений в учетной системе компании.

Продолжительность этого этапа определяется частотой обработки, мощностью зоны приемки склада, объемом принимаемых транспортных средств, процедурами и правилами компании. Этот отрезок часто недооценивается, хотя мне, например, известны компании, где процедура приемки может занимать неделю. Но даже если она достаточно коротка, ее продолжительностью нужно пренебрегать очень осторожно. Например, сама приемка занимает несколько часов, и, казалось бы, этой продолжительностью при расчете с точностью до дня можно и пренебречь, но… Если поставка приходит под конец рабочего дня, то даже при очень коротком времени приемки товар станет доступен отделу продаж лишь на следующий день, то есть срок пополнения удлиняется на день, что иногда может быть весьма чувствительным.

Кроме того, во многих компаниях, где не удается обеспечивать наличие, продажи часто идут «с колес», то есть минуя приемку, когда товар резервируется под клиента еще в машине. Это, конечно, ускоряет процесс обслуживания клиентов, но приводит к большому количеству пересортов, недовозов, потому что никто не может гарантировать, что зарезервированный товар не был поврежден при транспортировке, что поставщик не ошибся при погрузке в машину и т.п.

Время в пути — это чистое время транспортировки с момента выезда транспортного средства из ворот поставщика до момента прибытия на склад компании. Эта самая простая и очевидная составляющая надежного срока пополнения, по сути, определяется только расстоянием и транспортной доступностью между двумя звеньями цепи поставок и видом используемых транспортных средств. Часто поглощается параметром «время исполнения заказа поставщиком».

Время исполнения заказа поставщиком — это время с момента, когда поставщик подтвердил приемку заказа, до момента, когда заказ погружен и отправлен в следующее звено цепи поставок. При производстве «для наличия» это время равно производственному циклу (production lead time).

Время согласования заказа — время с момента, когда заказ отправлен поставщику, до момента, когда он подтвердил, что принял его к исполнению. Иногда это очень короткие отрезки времени, иногда — достаточно длительные, так как требуют, например, оплаты выставленного счета. В производстве это может быть время, которое пройдет с момента постановки заказа в план производства до момента, когда производство приступит к его исполнению.

Время ожидания между заказами — это самое «хитрое» время во всем надежном сроке пополнения. Его величина определяется как объективными, так и субъективными факторами. К объективным факторам следует отнести размер минимальной партии и минимальной транспортной партии. Минимальную партию заказа для SKU устанавливает, как правило, поставщик. Причины могут быть как экономические (внутренние нормы и правила, оптимизация переналадок на производстве, фасовка и упаковка), так и технологические. Например, при производстве творога, независимо от того, какой размер партии вы запустите в производство, при определенном типе оборудования вы 2 килограмма размажете по стенкам. Очевидно, что существует некая минимальная партия, где запуск заказа в производство — нецелесообразен. Кроме того, в химической и пищевой промышленности существует проблема точности дозировок: погрешность дозаторов примерно постоянна, но на больший объем запуска эта погрешность дает меньшую ошибку, а следовательно, более стабильное качество.

Транспортная партия также имеет экономическое обоснование. Согласитесь, нелогично тратить на транспортировку денег больше, нежели Проход, который может заработать компания от продажи доставленных товаров. Часто вместо размера транспортной партии задается сумма заказа в денежном выражении.

К субъективным же факторам относятся внутренние правила компании или правила (расписание) приемки заказов поставщика, продиктованные оптимизацией работы специалистов по формированию/приемке заказов.

Таким образом, время ожидания между заказами складывается из времени накопления минимальной партии поставки и/или минимальной транспортной партии и времени ожидания между заказами. Существуют два подхода: один рассматривает среднее время, второй опирается на максимальное.

Среднее время считается, исходя из следующих предпосылок: потребность может появиться как за один день до формирования заказа, так сразу после него. Соответственно, среднее время будет равно:

Лично я, в силу того что на старте проекта эти данные либо отсутствуют, либо крайне неточны, предпочитаю не усреднять время, а брать максимальное из двух: время накопления минимальной партии поставки и/или минимальной транспортной партии и установленное время между заказами.

Давайте разберем на примерах.

Пример 1.

Компания поставляет в розничные магазины. Время с момента получения заказа до момента появления товара на полке (согласование заказа, исполнение заказа, путь и приходование) — 3 дня. Минимальная партия поставки и транспортная партия от одной штуки, соответственно, времени ожидания накопления минимальной партии в компании нет, но… заказы компания принимает один раз в две недели. То есть время ожидания между заказами составляет 14 дней.

Считаем надежный срок пополнения. Если мы возьмем среднее время между заказами, то надежный срок пополнения, округленный до целых дней, составит (14+1)/2+3=11 дней, если же мы не будем усреднять время между заказами, то надежный срок пополнения составит 14+3=17 дней.

Обратите внимание, что большую часть надежного срока пополнения составляет время ожидания между заказами, установленное внутренними правилами поставщика. Если бы в этой компании было внедрено типовое Дерево Стратегии и Тактики для поставщика потребительских товаров, а в розничной сети соответствующее Дерево Стратегии и Тактики, то просто ежедневное предоставление информации о потреблении сократило бы срок пополнения до 1+3=4 дней!!! А это позволило бы сократить запас без ухудшения уровня наличия в торговых точках минимум в два раза, то есть как минимум в два раза поднять оборачиваемость запасов.

Пример 2.

Компания дистрибутирует продукцию из Китая и Юго-Восточной Азии. Продает компания два контейнера в месяц. Срок выполнения заказа поставщиком — 120 дней, срок согласования заказа — 14 дней, время в пути — 45 дней, время растаможивания и приходования на складе — 21 день. Частота заказа — один раз в месяц (раз в 30 дней).

Считаем надежный срок пополнения. Сложность здесь в расчете времени ожидания между заказами: мы можем заказывать каждые две недели, но заказываем раз в месяц. Я не буду в этом расчете считать среднее время ожидания между заказами и сразу возьму максимальное. Соответственно, сравнивая срок накопления минимальной транспортной партии и время между заказами — время между заказами больше, поэтому используем в расчете его. Получаем: 21+45+120+14+30 = 230 дней.
И возможностей для сокращения срока пополнения здесь у нас очень немного — мы можем сэкономить 14 дней и получить 216 дней, что на общем фоне выглядит почти так же много. Но… И здесь мы можем получить эффект от внедрения решений управления наличием. При таких длинных сроках поставки правильно рассчитанный буфер плюс частая поставка позволяет обеспечить относительно небольшой склад при постоянном наличии. Но вот эффект от сокращения запасов и рост оборачиваемости мы здесь вряд ли поймаем, нашим основным конкурентным преимуществом станет более высокий, по сравнению с конкурентами, уровень наличия, а следовательно, меньший объем упущенных продаж и дополнительная прибыль.

Я могу порекомендовать посмотреть на Ютубе ролик о результатах внедрения решения в Великобритании, где устранение стокаутов по 30% товарной матрицы привело к кратному росту прибыли[1].

---

[1] https://youtu.be/ceFhhPEtEKM

---

[1] THE TOCICO DICTIONARY. Second Edition, 2012 © TOCICO.