Надежный срок пополнения — это еще один критически важный параметр, необходимый для обеспечения наличия.

Как рассчитать надежный срок пополнения?

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

Он в себя включает помимо собственно срока исполнения заказа/ которые короткий, еще несколько отрезков времени.

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

В очень многих компаниях из-за того, что присутствует хронический дефицит товара, процесса приемки по количеству и качеству не происходит. Товар клиенту отгружается «с колес». Потом обнаруживается, что отгрузили не то, брак, возникают возвраты, потерянная репутация, куча взаимодействия и переписки.

Просто по тому, что этот этап приемки по количеству и качеству пропустили.

Дальше это собственно срок выполнения заказа.

Он определяется только тем, что дает вам ваш поставщик. Допустим, какой-нибудь отечественный завод работает так: дайте нам в этом месяце заказ, мы его поставим на следующий месяц в план производства. Соответственно, в производство ваш заказ может попасть на любую дату в течение следующего месяца, и отгружен будет в любую дату месяца, который будет после того периода, на который мы делаем план производства. То есть мы уже получаем срок исполнения заказа 60 дней.

Но и это еще не всё! Вам же надо прожить с чем-то пока у вас проходит время между заказами.

У нас есть еще время накопления заказа или время ожидания между заказами, которое определяется либо частотой заказов, установленной поставщиком или вами, либо размером минимальной партии заказа: чем больше минимальная партия, тем дольше она накапливается.

Если вы размещаете заказ раз в месяц, как в моем примере с заводом, то у вас получается 60 дней плюс 30 дней — 90 дней. То есть надежный срок пополнения, в течение которого вам надо обеспечивать наличие, составляет 90 дней (это без учета времени приходования на склад).

Для расчета сроков пополнения сырья и материалов расчет выполняется аналогично.

Особую сложность составляет производство готовой продукции.

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

Это время определяется следующими факторами:

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

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

Так считается надежный срок пополнения (Reliable Replenishment Time — RRT). При этом занизить срок пополнения опаснее, чем завысить.

Подробно как считается и применяется надежный срок пополнения мы разбираем на обучении методике: Ближайшее обучение по управлению запасами: https://vmss.pro/training/

В предыдущей публикации мы рассмотрели обоснование применения метода Упрощенный Барабан-Буфер-Канат.

Теперь давайте попробуем перенести эту идею из производства на цепочку поставок.

При применении в производстве метода «Упрощенный Барабан-Буфер-Канат» важно, чтобы touch-time (чистое время исполнения заказа, в русском варианте соответствующего термина нет, так что я использую термин «чистое технологическое време) был не более 20% от общего времени исполнения заказа, которое мы обещаем клиентам. И если в производстве с этим более или менее понятно, что в цепочках поставок это понятие еще более неопределенное. Что же будет touch-time при выполнении заказов при поставке «под заказ». На мой взгляд, это время комплектации, время погрузки, время в пути, время прохождения всяких таможенных прочих операций… В него не попадает время ожидания, пролеживания и т.п.

У нас возможны две ситуации: когда отношение touch-time к времени исполнения заказов менее 20%, и когда это отношение более 20%. Так вот, если отношение менее 20%, то не надо ничего сложного придумывать, можно использовать УББК. А если отношение более 20%, то УББК не применим. Здесь скорее подойдут подходы разработанные для управления проектами — метод Критической цепи (CCPM). Причем, в оригинале говорится от доле touch-time в 5-10%%, но по моему личному оценочному суждению 20% — это еще приемлемая доля для применения УББК, если больше нужно адаптировать метод Критической цепи. А если touch-time менее 20%, то, даже если заказ уже в красной зоне буфера, мы можем его успеть выполнить за время, отведенное под красную зону, т.к. она все еще в полтора раза больше «несжимаемого» touch-time.

К счастью, ситуации, подходящие для применения УББК, — это часто встречающиеся ситуации.

Просто для примера. Я живу в Санкт-Петербурге и мы достаточно часто пользуемся Озоном, Яндекс.Маркетом и другими маркетплейсами. При заказе срок доставки в пункт выдачи заказа 28-72 часа, при этом собрать и довезти заказ в пределах города можно в пределах двух часов. Но мне обещают от суток и больше. Почему так, я понимаю: нужно найти мощности, найти доставщика, оптимизировать загрузку и маршруты. Но мне как клиенту это неважно, Меня обещанный срок доставки устраивает, а следовательно метод УББК для такой ситуации вполне себе подходящий.

Предоположим, что срок исполнения — 48 часов. Тогда мы устанавливаем буфер заказа в 48 часов, делим ее на три равные части по 16 часов: зеленую, желтую, красную. Приоритет заказов будет определяться тем, в какой зоне сейчас находится заказ. И даже если заказ попал уже в красную зону — его вполне можно успеть выполнить как срочный. Мы можем заниматься оптимизацией загрузки, искать, объединять, комплектовать — главное уложиться в объявленный срок. И сквозная система приоритетов здесь всем в помощь.

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

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

Но здесь включается принцип «лучше быть приблизительно правым, чем совершенно точно заблуждаться». Представим, что у нас touch-time заказа 20%, и мы уже приняли четыре заказа. Когда мы можем пообещать выполнение пятого? Если у нас не будет контроля загрузки мощности, то мы, скорее всего, назовем стандартный срок исполнения заказа, то с высокой долей вероятности вы опоздаете. А если бы у нас был график текущей загрузки мощности, то мы увидели бы, когда у нас освобождается критический ресус и, уже исходя из этого, называли бы клиенту возможный срок исполнения заказа.

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

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

Прежде, чем продолжить говорить про использование подхода «Упрощенный Барабан-Буфер-Канат» в управлении поставками, стоит сделать небольшое отступление.

Изначальный вариант решения для производства, который появился во всех книжках, называется «Барабан-Буфер-Канат» (Drum-Buffer-Rope). В этом решении было два буфера: один буфер, который измерялся во времени, защищал работу ограничения, а второй буфер защищал наши обязательства перед клиентом.

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

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

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

Итак, во второй половине 90-х правило двух буферов было поставлено под сомнение. И Эли Шрагенхайм обосновал подход, который сейчас называется «Упрощенный Барабан-Буфер-Канат». Идея этого подхода состояла в том, что клиентам все равно, где находится наше внутреннее ограничение. Никого из наших клиентов не интересует, где находится наше внутреннее ограничение.

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

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

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

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

Получается, что, если у нас в системе два буфера в одном потоке, то какой из них главный?

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

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

Это была революционная история!

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

Вопрос: а зачем она берет столько времени на исполнение заказа?

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

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

Но чтобы это работало, нужна еще одна дополнительная штука: мы должны знать сколько мы уже на напринимали заказов. То есть в дополнение к буферу заказа нам нужно добавить еще обязательный механизм: контроль загрузки нашей мощности. Для производства критически важно, потому что если мы напринимали заказов и, грубо говоря, мы обещаем клиенту 10 дней, и у нас технологическое время один день, и одновременно у нас уже принято 10 заказов, то, когда мы пообещаем клиенту время исполнения закза, а на самом деле мы точно будем опаздывать. Потому что пока очредедь дойдет до этого заказа, мы уже опоздаем. Поэтому применение метода «упрощенный Барабан-Буфер-Канат» на производстве требует одновременного использования контроля загрузки мощности.

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

Сегодня мы будем говорить о прикладных вещах, связанных с управлением цепочками поставок. Тема этого поста: управление цепочками поставок в режиме «под заказ», откуда брать решения?

Если мы вспомним все, что мы говорили предыдущих публикациях, то, во-первых, под заказ мы поставляем в двух случаях:

1. Когда наш клиент готов ждать. У нас есть много времени на то, чтобы выполнить заказ нашего клиента, и клиент это время, которое нам нужно для выполнения его заказа, готов ждать. В этом случае нам не нужны никакие запасы, и мы, естественно, поставляем только под заказ.
2. Вторая ситуация более грустная для нас, как поставщика. Это ситуация, когда клиент может быть и не хотел бы ждать, но у нас нет мощности для того, чтобы произвести что-то, или поставить что-то, или закупить что-т,о создать что-то, что надо нашему клиенту за то время, которое он готов терпеть. И поэтому из всего рынка у нас остаются только те клиенты, которые готовы ждать. В такие ситуации мы попадаем с самыми бедными клиентами, потому что они готовы ради скидки в цене ждать, или самые богатые клиенты, которые хотят какие-то уникальные комплектации. Естественно, в эту ситуацию бы попадаем всегда, когда на рынке по каким-либо причинам происходит сбой в логистических цепочках, сбой в управлении запасами, и на рынке образуется дефицит. Когда у нас на рынке образуется дефицит, то в этом случае, естественно, клиент будет ждать. Потому что это рынок продавца, и мы начинаем поставлять под заказ, даже если других условиях это было бы не так.

В рамках Теории ограничений для управления поставок «под заказ» решений нет!

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

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

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

У нас есть два крупных отдельных готовых логистических решения из раздела того, что называется «движители Теории ограничений», то есть логистические решения Теории ограничений. В их составе есть два готовых решения: это производство «под заказ» (MTO — make to order) в режиме «упрощенный Барабан-Буфер-Канат», и метод Критической цепи (CCPM), который вообще-то используется в проектном управлении. Два этих способа управления обеспечивают нам управление системами для того, чтобы укладываться в срок.

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

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

Продолжение следует ….

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

Один из них называется в оригинале долларо-дни прохода (TDD), у него есть еще аббревиатура деньго-дни прохода (TVD). Суть его предельно проста: если у нас нет товара, то мы теряем прибыль, то есть это показатель упущенной прибыли. Для цепочек, которые работают в режиме «на склад», он считается очень просто: время отсутствия товара умноженное на скорость продаж (среднюю за какой-то период) и на уровень Прохода, который мы зарабатываем с одной штуки. Если у нас товара не было пять дней, мы потеряли проход за пять дней. Потерянный проход — это не просто какая-то потерянная наценка. Нет ребята!!! Это напрямую потерянная ваша прибыль, потому что вы же уже все получили, уже расходы вычли, о прибыли отчитались, и каждый дополнительный рубль прохода, вообще-то, — это увеличение вашей прибыли. Поэтому можно по-русски его называть показатель упущенной прибыли.

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

Второй показатель должен ответить на вопрос: а как дорого нам обходится безубыточное функционирование цепочки продаж? Показатель называется долларо-дни запасов (IDD) или деньго-дни запасов (IVD). Он введен для того, чтобы можно было сравнивать между собой заморозку дешевых и дорогих товаров. Дешевый товар стоимостью 10 рублей, который у нас будет лежать 10 дней, и дорогой товар, который стоит 100 рублей, но лежит один день, с точки зрения, заморозки денег — это одинаково. Но зато каждый дополнительный день для 100 рублевого товара, это тоже самое, что 10 рублевый еще на 10 дней. Этот показатель показывает именно то, как у нас «застревают» деньги в системе.

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

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

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

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

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

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