Все записи автора Дмитрий Егоров

Динамическое управление буфером запасов при длинных сроках пополнения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как работает «классический» алгоритм динамического управления буфером запасов

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

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

Исходная посылка механизма:

Если у нас реализован и работает механизм частого (в идеале — ежедневного) пополнения на основании фактического потребления, то поведение остатков товаров/продукции «на руках» достаточно хорошо отражает изменения в тенденциях спроса и/или сроков пополнения.

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

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

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

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

Разберем на простом примере. У нас есть товар Х, срок пополнения которого 15 дней. Пусть ЦУБ у нас равен 21 единице, граница красного соответственно — 7. Фактические остатки на руках (подневно) от сегодняшнего дня назад: 3, 4, 10, 14, 5, 10, 12, 10, 5, 12, 14, 10, 12, 14. Считаем «площадь» нахождения в красном: (7–3)+(7–4)+(7–5)+(7–5) = 4+3+2+2 = 11. Это точно больше, нежели граница красного. Соответственно, целевой уровень буфера должен быть увеличен на треть до уровня 28 единиц.

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

ВАЖНО!!! До момента поступления увеличенного заказа на склад система динамического управления буфером должна игнорировать нахождение запасов «в красном», то есть мы исключаем из рассмотрения один срок пополнения.

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

Теперь давайте рассмотрим обратную ситуацию: необходимость уменьшения ЦУБ.

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

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

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

Очевидно, что после снижения ЦУБ запасы «на руках», скорее всего, окажутся в состоянии «овербуфера» — в голубом. Это нормально, теперь мы должны дождаться, пока запасы с учетом уже заказанных и «доезжающих» снизятся ниже ЦУБ и возникнет необходимость снова проверять адекватность установленного ЦУБ.

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

Я соглашусь с утверждением, которое делает Эли Шрагенхайм в своей книге: «Ни один компьютер не обладает интуицией для определения „подозрительных“ ситуаций… Динамическое управление буфером как ни одна из практик управления ограничениями требует тщательной оценки и контроля»[2]

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

Пример из реальной практики: срок пополнения 21 день, но позиция Складская, если имеет не менее 6 продаж В ГОД, то есть продается в среднем раз в два месяца. Очевидно, что классический механизм уменьшения Целевого уровня буфера будет создавать в системе избыточный шум, но и использование «адаптированного», о котором речь пойдет далее, при таких сроках пополнения — неоправданно. В этом случае целесообразно использовать некие коэффициенты чувствительности.

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

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


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

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

Зачем нужно Динамическое управление буфером запасов?

Наверное, единственное, что можно точно утверждать про бизнес-реальность, в которой мы все живем, так это то, что со временем в ней может измениться практически все. Со временем меняется спрос, сроки пополнения и даже уровень неопределенности (он же наш старый знакомец — Мерфи). Поэтому и установленный однажды ЦУБ нужно время от времени проверять на адекватность существующей реальности.

Для этого в решения по управлению наличием встроен механизм, который называется Динамическое управление буфером (Dinamic Buffer Management (DBM)), получивший в русском языке устоявшуюся аббревиатуру ДУБ.

Динамическое управление буфером — это механизм проверки на соответствие существующим условиям рассчитанного Целевого уровня буфера.

Главная задача механизма Динамического управления буфером — это информировать нас о признаках существования одной из двух ситуаций:

  • уровень установленной защиты от неопределенности (буфер) слишком велик относительно существующих бизнес-условий;
  • уровень установленной защиты слишком мал относительно существующих бизнес-условий.

И при этом он не должен порождать излишнего «шума», то есть сигналов, не требующих обработки.

В типовых деревьях Стратегии и Тактики механизм ДУБ описан в очень общих фразах:

«Если запасы „на руках“ слишком долго находятся в красной зоне (по умолчанию — один срок пополнения), то целевой уровень увеличивается на величину одной зоны (1/3) текущего размера буфера. Если запасы слишком долго находятся в зеленом, то целевой уровень уменьшается на величину одной зоны».

При этом делается оговорка, что «слишком долго» — определяется желаемым уровнем сервиса, по умолчанию — это один срок пополнения.

Пожалуй, единственный из известных мне источников, где дается какой-либо алгоритм для настройки Динамического управления буфером — это книга, написанная в соавторстве Эли Шрагенхаймом, Уильямом Детмером и Уэйном Паттерсоном «Управление цепями поставок на невероятной скорости»[1], где авторы излагают подходы к увеличению и снижению Целевого уровня буфера, основываясь на методах, которые мы назовем «Классическими», потому что они составляют классику Теории ограничений и родились в процессе обсуждения методов между двумя Эли: Голдраттом и Шрагенхаймом, но, к сожалению, эта книга не переведена на русский язык. Тем, кому доступно чтение на английском — настоятельно рекомендую к изучению.

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

Однако в практике есть одно, но большое «но»: эти параметры сами по себе вероятностные, т.е. колеблются в некоторых пределах, которые можно обозначить как «уровень шума». А в Теории ограничений, так же как и TQM, есть рациональное правило: не нужно заниматься оптимизацией в пределах «шума». Такие действия способны причинить системе больше вреда, чем пользы. Это наглядно демонстрирует известный эксперимент с воронкой Эдварда Деминга[2].

Итак, давайте попробуем от общих рекомендаций перейти к конкретным алгоритмам. Условно мы их обозначим как «Классический» и «Адаптированный».

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

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

Дальше мы разберем их подробнее.


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

[2] https://www.deming.pro/deming-funnelexperiment.html

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

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

Первый — это первоначальное заполнение буфера.

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

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

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

  1. Отсортируйте номенклатуру с точки зрения скорости генерации Прохода в единицу времени (Проход в дни наличия, Проход на кв. метр склада в день в дни наличия, Проход на метр полки в день в дни наличия).
  2. Отсортируйте номенклатуру с точки зрения показателя ROIDD (см. соответствующий раздел).
  3. Закажите до Целевого уровня буфера всю номенклатуру, имеющую отрицательный показатель IDD (ну, вдруг вам повезло, и такая у вас есть).
  4. Определите бюджет закупок (сумму увеличения запасов, которая будет доступна ПОСЛЕ оплаты Операционных расходов).
  5. Всю остальную номенклатуру закажите до уровня границы желтого, пока отпущенный бюджет на закупку товара не закончится.
  6. Последовательно доводите наполнение буфера (товары «на руках» плюс товары «в пути» плюс товары «в заказе») до Целевого уровня буфера.
  7. Переходите в регулярный режим работы.

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

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

И еще один «особый» случай — это работа с новинками. Если с товарами, по которым мы взяли на себя обязательство по поддержанию постоянного наличия (они — Складские), у нас есть статистика продаж, на которую мы можем опираться при установлении Целевого уровня буфера, то с товарами-новинками такая информация у нас отсутствует. Соответственно, единственное, на что мы можем опираться — это прогноз. Мы можем прогнозировать исходя из данных о продажах товаров-аналогов (точнее было бы сказать: товаров, которые МЫ ДУМАЕМ, что потребитель будет воспринимать как аналоги). Это хороший метод, например, в работе с запасными частями часто происходит замена каталожного номера детали, в результате чего появляется новое SKU, но которое будет просто прямой заменой предыдущему.

Существует классическая матрица определения инновационности товаров: новые-старые для нас, новые-старые для рынка.

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

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

Вне зависимости от того, каким образом для товара-новинки был установлен Целевой уровень буфера, в дальнейшем они управляются в том же режиме, что Складские позиции, но… контроль Целевого уровня буфера (Динамическое Управление буфером) выполняется как минимум в два раза чаще, чем для Складских, а клиентам НЕ ГАРАНТИРУЕТСЯ постоянное наличие этих SKU. По истечении установленного в компании времени, которое определяется спецификой рынков, товар-новинка должен быть переведен или в Складскую позицию, или в Заказную, или поставлен на Вывод.


[1] См., например: Эли Шрагенхайм, Рави Гилани «Устраняем активное ограничение денег» http://egorovde.ru/archives/1765, или Дмитрий Егоров «Пять фокусирующих шагов для ограничения Деньги» http://egorovde.ru/archives/1521, или выступление Рави Гилани на конференции в Санкт-Петербурге в 2017 году https://youtu.be/7YEOhmcr5FQ

Учет величины минимальной партии поставки и минимальной транспортной партии при заказах

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

В главе, посвященной расчету Целевого уровня буфера, я уже говорил о том, что нецелесообразно устанавливать ЦУБ на уровне менее чем полторы минимальной партии, установленной для конкретного SKU, и постарался дать этому объяснение.

Таким образом, работа при расчете заказа строится так:

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

При длинных сроках пополнения иногда оказывается целесообразным формировать заказ поставщику, не дожидаясь, пока потребность превысит минимальную партию поставки или минимальную транспортную партию, можно установить некоторый понижающий коэффициент, при превышении которого заказ формируется и округляется вверх до минимальной партии поставки или минимальной транспортной партии. В практике наших проектов при контейнерных поставках этот коэффициент вполне работоспособен на уровне 80–85% от минимальной партии.

Желательно, чтобы контроль за выполнением этих условий выполняла автоматизированная система, так как количество SKU может быть значительным, а транспортная партия может меняться от поставщика к поставщику. Разработанный и реализованный нами программно-методический комплекс NET Stock[1] поддерживает все методические нюансы, о которых я здесь рассказывал.


[1] http://netstock.pro

«TOC и ИИ: Используем знания TOC чтобы полностью извлечь ценность от искусственного интеллекта для управления организациями» Перевод материалов блога Эли Шрагенхайма

Эли Шрагенхайм опубликовал статью, которую они написали вместе с сыном Амиром Шрагенхаймом, посвященную возможностям сочетания Искусственного интеллекта и Теории ограничений.

Местами они повторяют то, что писали раньше, местами дают новые вводные. Есть даже место, где мне сильно хотелось поспорить. Но… Не здесь. Здесь место для оригинального текста авторов.

Как обычно, ссылка на оригинал и картинка из поста автора.

Ваш Дмитрий Егоров

P.S.: «Очепятки» возможны, так как вычитывать времени не было. И это… очень «многа букафф»…


Эли и Амир Шрагенхайм

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

Современные системы ИИ способны делать предсказания, основываясь на больших объемах данных и моделируемых результатах, а также предпринимать какие-либо действия (как это делают роботы) или поддерживать человека в процессе принятия решений. Важным примером может выступать способность понимать язык, его реальные смыслы и генерировать разнообразные сервисы. «Опыт» создается с помощью предоставляемого набора данных, который должен быть очень большим. Этот способ обучения пытается сымитировать обучение человека на собственном опыте, но с тем преимуществом, что появляется возможность обучения на ОГРОМНОМ объеме опыта с, надеюсь, меньшими предубеждениями.

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

У ИИ есть несколько критически важных ошибок. Одна из них – это невозможность объяснить, как пришли к конкретному решению Его зависимость как от больших наборов данных, так и от обучения, делает невозможность объяснить решение потенциальной угрозой совершения ошибок, которые бы не сделали большинство людей. Даже огромные наборы данных содержат искажения, поскольку они были собраны в определенное время, в определенном месте и при определенных условиях, вследствие чего они могут неправильно интерпретировать конкретную ситуацию.

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

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

Она концентрируется на поиске вариантов прорывов, пытаясь найти, где находятся существующие пределы[i] в достижении цели. Поэтому мы бы хотели изучить может ли быть использована мощь ИИ для преодоления этих лимитов.

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

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

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

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

Оценка неопределенности и ее влияния.

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

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

Самая насущная потребность в управлении цепочкой поставок (и других критически важных решений в бизнесе) – это получить прогноз спроса на завтра, на следующей неделе, в следующем месяце, а также в долгосрочной перспективе. Оценка потенциального спроса на следующий год(ы) критически важна для инвестирования в мощность или в НИОКР (R&D). Не существует НИ ОДНОГО СПОСОБА получить сейчас надежную и точную цифру завтрашнего спроса, и чем дальше в будущее мы отодвигаемся, тем хуже становится ситуация (так работает неопределенность).

Пример: Предположим, что самый лучший алгоритм прогнозирования дает вам прогноз, что спрос на следующей неделе для SKU13 составляет 1237 единиц, но фактический оказался 1411.

Был ли первоначальный прогноз ошибочным?

Теперь предположим, что первый алгоритм включат в себя оценку среднего отклонения – «ошибку прогноза». Оценка была плюс-минус 254. Это сразу представляет первый прогноз в лучшем свете, потому что прогноз включает в себя вероятность получения фактического результата 1411. Если второй алгоритм не содержит «ошибки прогноза», как мы можем на него полагаться?

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

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

Существуют метапараметры алгоритма ИИ, которые определяют возможное решение. Изменяя эти метапараметры можно легко получить результат, который будет более консервативным или более оптимистическим (наприме: вместо использования порога в 0,76, мы можем использовать 0,7 в одном случае или в 0,82 в другом). Таким образом, доступ к обоим прогнозам дает ЛПР более полную информацию для рассмотрения наиболее подходящего действия, не привыкая к использованию стандартного отклонения или другим параметрам разброса.

Получение более ценной информации о состоянии рынка

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

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

Значительные изменения – это проблема при использовании существующей практики использования ИИ. Однако, уже существуют алгоритмы ИИ, которые определяют отклонения от определенной реальности. Такие алгоритмы все шире используются в предсказании необходимости обслуживания производственных мощностей. Такие сигналы ИИ указывают ЛПР, что реальность изменилась, сообщая им, что требуется ручное вмешательство.

Прогнозирование влияния больших изменений, решение о которых принимается внутри компании, таких как изменение цен, запуск маркетинговой акции и т.п. – это реальная потребность менеджмента. Хотя изменение цены на товар кажется простой задачей, сложно оценить все последствия  на спрос других товаров и реакцию конкурентов. Плюс такие изменения происходят не очень часто, и внутренних данных, собранных за прошлые периоды, может быть недостаточно, чтобы создать эффективную модель ИИ, которая бы дала достаточно точный прогноз. Это создает возможностьи для сторонней организации, которая работает с Big Data. Такая организация может собирать данные множества заинтересованных организаций и использовать агрегированные данные для создания лучше модели ИИ, которая может быть использована для того, чтобы делиться данными с организациями результатами прогноза последствий от подобных действий. Это позволит выиграть всем участвующим сторонам и легко может покрыть связанные с этим операционные издержки. Такие организации должны гарантировать отсутствие утечки данных конкретных предприятий, и делиться только общими открытиями.

Предупреждение об изменениях в поставках

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

Конечно, снабжение – это абсолютно необходимый элемент обеспечения бизнеса. Проблема в том, что когда у поставщика происходят изменения, которые негативно влияют на поставки, для некоторых клиентов потребуется значительное время, чтобы осознать эти изменения и вызываемый ими ущерб. Менеджмент не должен фокусироваться на обычных рутинных взаимоотношениях. Однако, если изменения в поведении обнаруживаются достаточно рано, возможно с использованием программного обеспечения, то это обеспечивает базовую потребность [организации??? – Д.Е.] Это особенно ценно, когда причина изменений неизвестна. Например, когда поставщик сталкивается с финансовыми проблемами или сменой руководства.

Достижение эффективного сотрудничества между ИИ, аналитикой и человеческой интуицией

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

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

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

Пример.

Предположим, что ИИ прогнозирует спрос для продукта P1, который сильно отклоняется от обычных ожиданий (или обычного прогноза или просто текущего спроса), в этом случае модулю ИИ может быть поставлена задача спрогнозировать спрос для группы схожих продуктов, скажем от Р2 до Р5, исходя из предположения, что, спрос на Р1 действительно растет, то и спрос на похожие продукты должен показать аналогичную тенденцию. Прогноз спроса для группы продуктов не должен основываться на прогнозе для каждого отдельного продукта и последующем их суммировании, он должен повторить последовательность расчетов, с учетом суммарного спроса в прошлые периоды. Таким образом, появляется логическая обратная связь, проверяющая дает ли ИИ неожиданный прогноз или его рекомендации имеют смысл.

Другой способ – позволить пользователю принять или отвергнуть результаты работы ИИ. Желательно, чтобы отказ был выражен в виде причинно-следственных связей, которые могли бы быть использованы ИИ в будущем для расчета новых результатов.

Дополнительные вводные данные от пользователя.

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

Выводы и взгляд в будущее

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

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

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

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

Улучшения, которые ИИ может дать TOC

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

Расчет размера буферов является чувствительной областью. Установление буферов для защиты, а на самом деле для стабилизации уровня выполнения заказов, на самом старте является проблемой. Но в этом месте ИИ не сможет нам помочь, потому что анализ истории до того, как начали активно использоваться решения ТОС бесполезен. Но после года-двух работы по правилам ТОС, ИИ может указать на слишком большие или слишком маленькие буферы. Динамическое управление буфером (DBM) – это процедура для управления буферами запасов, основанная на проникновении в Красную Зону может быть значительно улучшена с помощью ИИ. Еще одно потенциальное улучшение – это ответ на вопрос насколько увеличивать буфер. Аналогичные улучшения могут быть полезны при анализе слишком долгого нахождения в Зеленой зоне и сигналах о безопасном снижении буфера запасов.[iii]

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

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


[i] В тексте «limitations», специально не использую термин «ограничение», чтобы не путать с понятием «constraint». Прим. переводчика

[ii] В тексте также «limitations» — Прим. переводчика

[iii] Здесь не могу удержаться и не прокомментировать: мы значительно улучшили эту ситуацию, практически добавив ИИ в Динамическое управление буфером запасов. Подробнее ищите в материалах по Net Stock Pro. – ДЕ.

Как определяется приоритетность заказа?

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

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

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

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

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

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

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

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

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

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

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

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