Архив рубрики: Жизнеспособная система управления

Установление границ буфера

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

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

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

Черный — означает, что товара уже нет в наличии и компания попала в ситуацию упущенных продаж по данному конкретному 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. Сформулировать вопросы, на которые хочется получать ответ?
  2. Сформулировать как должна выглядеть информация, которая будет составлять ответ: состав и структура данных.
  3. Проверить существуют ли соответствующие данные в учете и, если нет, то:
  4. Организовать учет соответствующих данных.
  5. И только ПОСЛЕ выполнения п.п.1-4 начинать планировать какие-то улучшения.

Прежде, чем начинать что-то улучшать, нужно понять как обстоят дела в реальности!!! Потому что наше представление о реальности может не совпадать с действительным положением дел. Люди часто живут в своих фантазиях, а не реальном мире.

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

Не нужно стремиться к идеальному учету! Мы всегда будем действовать в условиях неполноты информации. И — да, лучше быть приблизительно правым, чем совершенно точно ошибаться. Но…

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

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

Учитывайте, господа!!!

Первоначальный расчет Целевого уровня буфера

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

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

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

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

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

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

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

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

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

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

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

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

Итак:

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

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

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

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

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

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

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

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

Расчет надежного срока пополнения (RRT)

Итак, давая определение понятию «буфер запасов», мы установили два параметра, влияющих на величину Целевого уровня буфера: надежный срок пополнения и спрос на конкретный 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.

Буфер запасов. Определение, функции и подходы к расчету

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

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

  • Прогнозирование — прогноз потребления, спроса, сроков завершения на коротком горизонте планирования (ЛИД-тайм, или надежный срок пополнения). Работает на этапе планирования.
  • Защита от обычной и предсказуемой неопределенности — запас времени, мощности, материалов и т.д., который должен обеспечить выполнение обязательств, но не учитывающий экстраординарные выбросы вероятности. Обычно мы говорим о вероятности в 90–95%. Работает на этапе планирования.
  • Инструмент раннего оповещения о том, что ситуация готова выйти за рамки обычной и предсказуемой определенности и необходимо предпринимать дополнительные управленческие усилия по корректировке ситуации. Работает на этапе исполнения.
  • Инструмент установления приоритетов для заказов, поставок. Работает на этапе исполнения.
  • Инструмент анализа наличия/отсутствия достаточной защиты от неопределенности. На этапе непрерывного улучшения.

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

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

Во-первых, очень часто при работе с прогнозами работают с «математическим ожиданием» и стандартным отклонением. Причем в качестве математического ожидания рассматривают среднее (арифметическое) значение, то самое, которое выдает стандартная функция Excel СРЗНАЧ. Но… среднее значение делит всю выборку с вероятностью 50/50 — в половине случаев будет больше, а в половине меньше.

Во-вторых, часто в какой-то момент теряют такую переменную, как «ошибка прогноза». Дело в том, что прогноз в реальности дает нам диапазон значений (например, ±3 сигмы), в который мы с заданной вероятностью попадем. Но это ВСЕГДА ДИАПАЗОН, и этот диапазон часто достаточно большой.

В-третьих, это само использование стандартного отклонения и нормального распределения. Дело в том, что методы, основанные на нормальном распределении и стандартном отклонении, исходят из исходной посылки о симметричном распределении отклонений относительно математического ожидания, что верно только при а) большом количестве наблюдений; б) наличии физического ограничения диапазона возможных значений. Во всех социально-экономических средах эти исходные посылки не соответствуют действительности. Об этом прекрасно написал Нассим Талеб в своем «Черном лебеде».

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

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

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

Отсюда мы получаем определение буфера запасов:

БУФЕР ЗАПАСОВ — это максимальный объем потребления конкретного SKU в конкретном месте хранения за надежный срок пополнения.

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

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

Книга «Управленческий учет на стероидах» теперь доступна на RIDERO

Теперь точно — всё!!!

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

Стоимость печатной версии в мягкой обложке от 1500 до 2000 рублей без стоимости доставки в зависимости от магазина. Стоимость электронной книги около 500 рублей.

Доступна по ссылке: https://ridero.ru/books/upravlencheskii_uchet_na_steroidakh/

У Ridero бывают сложности с сайтом, и иногда он тупит. Проверено первым покупателем электронной версии. Не пугайтесь и будьте настойчивыми. :)))))

N.B.: Информация для тех, кто заявился на книгу с автографом автора из ограниченного тиража в твердой обложке: всем, кто оставил заявку в Гугл-форме в пятницу (26 августа 2022) была отправлена ссылка на оплату на указанную в заявке электронную почту. Пока оплатили «не только лишь все».

Тираж заказан. Ожидаемый срок окончания печати 14 сентября 2022, плюс время на доставку автору и рассылку от меня адресатам.

Установление статуса режима управления номенклатуры

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

Следующий шаг, который нам предстоит сделать, это определить, в каком режиме мы будем управлять нашими товарами/продукцией/сырьем.

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

  • складская;
  • заказная;
  • новинка;
  • вывод.

Эти статусы определяют наши обязательства перед клиентами.

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

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

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

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

Еще один момент, на который, я считаю, важно обратить внимание, это тот факт, что все параметры, касающиеся пополнения, статусов номенклатуры, устанавливаются для каждого места хранения (склада — собственного или контрагента, неважно, будет ли это Поставщик или Покупатель). Если у вас сеть из 10 точек плюс один центральный склад и 10 тыс. SKU, то это означает, что у вас 11х10 000 = 110 000 точек управления, статусов номенклатуры, надежных сроков пополнения, целевых уровней буфера и т.д. Конечно, делать это вручную — задача слишком трудоемкая, но для этого существует специализированное программное обеспечение.

 При этом при установлении статусов для SKU в конкретном месте хранения существует определенная взаимозависимость, определяемая логикой управления цепью поставки.

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

Если на центральном складе номенклатура имеет статус «Заказная», то ниже по потоку она может иметь статусы «Заказная», «Новинка», «Вывод». Теоретически возможна ситуация, когда в месте хранения выше по потоку номенклатура имеет статус «Заказная», а ниже — «Складская», но это возможно только в том случае, если срок изготовления заказа МНОГО меньше, чем существующий срок надежного пополнения звена ниже по потоку, что в цепях поставок, управляемых в режиме «для наличия», большая редкость. Поэтому на старте следует принять за правило: если статус выше по потоку «Заказная», то ниже по потоку статус режима управления не может быть выше, чем «Заказная». И лишь потом, в процессе непрерывного улучшения, можно проверить допустимость инверсии статусов.

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

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

Но это отдельная большая тема, выходящая за рамки задачи, решаемой в данной книге[1].


[1] См., например: Эли Шрагенхайм. Управление смешанной средой «Производство на заказ (МТО)» и «Производство для наличия (МТА)» http://egorovde.ru/archives/1885

Определение границ «пилота» для внедрения

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

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

  • резко увеличивается уровень хаоса, чем больше сотрудников ОДНОВРЕМЕННО участвует в изменениях, тем больше неразберихи в процессе взаимодействия;
  • как следствие, резко возрастает уровень сопротивления, потому что результаты еще не получены, а отказаться от привычных моделей поведения нужно уже сейчас;
  • воздействие причинно-следственных связей размывается, и подтвердить или опровергнуть результаты обоснованно становится невозможно, а это открывает возможности к потенциальным манипуляциям.

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

В этом вопросе я предлагаю опереться на рекомендации, которые сформулировал Эли Шрагенхайм в своем блоге[1]:

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

Если мы говорим о внедрении решения по управлению наличием в цепях поставок, то здесь возможны варианты:

  1. Начать внедрение с центрального склада и не включать в пилот региональные склады и точки продаж.
  2. Зафиксировать некоторый регион для пилотного внедрения.
  3. Выбрать категорию продуктов и внедрять решения для этой категории.

У любого из этих вариантов есть свои плюсы и минусы.

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

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

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


[1] Эли Шрагенхайм. В поисках правильного пилота для подтверждения концепции. http://egorovde.ru/archives/1720

Последовательность действий при внедрении решений по управлению наличием

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

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

  1. Выбрать область и границы пилотного внедрения.
  2. Зафиксировать ключевые показатели функционирования системы управления запасами до момента начала внедрения.
  3. Установить статусы, связанные с режимом управления для конкретных SKU в конкретных местах хранения.
  4. Рассчитать первоначальные Целевые уровни буферов запаса.
  5. Приступить к заказам на основе рассчитанных Целевых уровней буфера.
  6. Настроить механизмы Динамического управления буфером.
  7. Подвести итоги пилота и перейти к масштабированию на всю компанию.
  8. Запустить процесс непрерывного улучшения (POOGI).

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

Исходные предпосылки для внедрения решений по обеспечению наличия

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

Вообще, мне хотелось бы «пристроиться» к мнению еще одного эксперта в области ТОС — Рави Гилани, который говорит, что вся Теория ограничений — это про исходные посылки[2] (чаще всего в русском переводе исходные посылки и предпосылки используются как синонимы, хотя в оригинальных текстах — это два разных слова — Д.Е.), в ходе разработки и внедрения решений мы или выясняем исходные посылки, или ставим их под сомнение, или выдвигаем новые. И процесс этот бесконечен, именно он обеспечивает реализацию последнего из пяти фокусирующих шагов: вернитесь к шагу первому, но не дайте инерции мышления поймать себя в ловушку.

Основные вопросы, которые следует себе задавать:

  • Почему мы решили, что это верно?
  • Что свидетельствует о том, что это верно?
  • Есть ли иные способы объяснить необходимость этих действий?

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

«Вчерашнее решение сегодня становится историческим курьезом („Ну не странно ли! Как вы считаете, зачем они вообще это сделали?“)» Э.М. Голдратт[3].

Решения по обеспечению наличия (в оригинальной литературе они называются MTA (Make To Availability) и Replenishment, но можно встретить и DTA (Distribution To Availability) и PTA (Purchase To Availability), но все это технически одно и то же решение) основаны на следующих исходных посылках[4]:

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

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

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

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

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


[1] См.: Эли Шрагенхайм. Обычные ошибки практиков в известных решениях ТОС. http://egorovde.ru/archives/1715

[2] См.: https://youtu.be/7YEOhmcr5FQ

[3] Уильям Детмер. Теория ограничений Голдратта: Системный подход к непрерывному совершенствованию. М.: Альпина Паблишерз, 2010. С. 42.

[4] Эли Шрагенхайм. Границы применимости решения Производство для наличия (МТА). http://egorovde.ru/archives/1392