В предыдущей публикации мы рассмотрели обоснование применения метода Упрощенный Барабан-Буфер-Канат.
Теперь давайте попробуем перенести эту идею из производства на цепочку поставок.
При применении в производстве метода “Упрощенный Барабан-Буфер-Канат” важно, чтобы 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%, и мы уже приняли четыре заказа. Когда мы можем пообещать выполнение пятого? Если у нас не будет контроля загрузки мощности, то мы, скорее всего, назовем стандартный срок исполнения заказа, то с высокой долей вероятности вы опоздаете. А если бы у нас был график текущей загрузки мощности, то мы увидели бы, когда у нас освобождается критический ресус и, уже исходя из этого, называли бы клиенту возможный срок исполнения заказа.
Эли Шрагенхайм рекомендует приплюсовать ко времени освобождения половину буфера, считая, что это достаточно обеспечивает защиту. Дерзко. Смело. Молодежно.
Я бы так действовать побоялся и приплюсовал бы полный буфер. И, если при этом бы заказы завершались бы в зеленой зоне, то тогда бы уже начал сокращать эти сроки. Но тут выбор за вами. У рекомендации Эли есть свое обоснование, но я бы применял ее только для себя, внутри компании, ничего не говоря об этом клиентам. И только проверив работоспособность гипотезы, начал бы транслировать это на рынок.