В ТОС «буфер» — это НЕ «запас» и не «на всякий/непредвиденный случай», а механизм управления потоком (часть 2 — Три места нахождения запаса)

31 августа 2016, Елена Федурко

Читать первую часть

В прошлой записи мы остановились на том, что целевой размер буфера КАЖДОЙ НОМЕНКЛАТУРНОЙ ПОЗИЦИИ  В КАЖДОЙ ТОЧКЕ «ДЕРЖАНИЯ» ЗАПАСА включает в себя ТРИ «места нахождения» запаса.

Буфер, это СУММА того, что:

  • имеется НА РУКАХ НА СКЛАДЕ,
  • находится В ПУТИ,
  • регистрируется в своей системе как количества К СЛЕДУЮЩЕМУ ЗАКАЗУ.

Штуки запаса каждой номенклатурной позиции, которая управляется через свой буфер, постоянно переходят из одного из трех «мест нахождения» в буфере запаса в другое, ВСЕГДА составляя В СУММЕ то количество штук, которое было установлено в качестве размера буфера. Эта сумма штук НЕ МЕНЯЕТСЯ до момента планового изменения размера буфера. Меняется только то, ГДЕ эти штуки находятся в каждый данный момент — то есть, их распределение по «местам» в буфере.

Давайте посмотрим, как это выглядит на практике.

Для данной номенклатурной позиции был установлен целевой размер буфера в 180 единиц.

Замечание: РАЗМЕР БУФЕРА РАССЧИТЫВАЕТСЯ В СООТВЕТСТВИИ С ФОРМУЛОЙ ТОС ДЛЯ РАСЧЕТА ЦЕЛЕВОГО УРОВНЯ ЗАПАСА!

Возвращаемся к примеру трех мест нахождения буфера.

1 СЕНТЯБРЯ

На 1 сентября ВЕСЬ РАЗМЕР БУФЕРА находился на руках.

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

К концу 1 сентября у нас будет такая картина:

Slide1

 

2 СЕНТЯБРЯ

За 2 сентября из буфера было потреблено 40 единиц. Информация о выбытии из буфера 40 единиц поступила в свою систему учета, но заказ поставщику еще не отправлен.

К концу 2 сентября картина такая:

Slide2

3 СЕНТЯБРЯ

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

К концу дня 3 сентября у нас такая картина:

Slide3

4 СЕНТЯБРЯ

4 сентября мы отправили заказ на 40 единиц поставщику, и он его принял. 30 единиц мы пока не заказали. (Причины тому, почему мы, имея в системе 70 единиц к заказу, заказали только 40, могут быть разные. Например, у нас 2 поставщика и обязательства ежемесячно заказывать определенные количества у каждого поставщика, и эти оставшиеся 30 единиц мы закажем завтра у другого поставщика. Или мы работаем по предоплате и у нас сегодня нет денег, чтобы сделать оплату за все 70 единиц, но мы ждем поступлений завтра и тогда сможем заказать еще 30 единиц. И так далее.) Мы регистрируем заказанное количество 40 единиц как «В ПУТИ». 4 сентября потребления из буфера не было.

К концу 4 сентября у нас такая картина:

slide 4__

5 СЕНТЯБРЯ

5 сентября мы отправили заказ на 30 единиц поставщику, и он его принял. Мы регистрируем это количество как «В ПУТИ». Теперь в пути 40 + 30. 5 сентября потребления из буфера не было.

К концу 5 сентября:

Slide5

 

6 СЕНТЯБРЯ

6 сентября в буфер прибыла поставка первых 40 штук. За день было потреблено из буфера 5 штук. На руках: 110+40-5 = 145.

5 потребленных единиц зарегистрированы в системе К ЗАКАЗУ. В пути идет 30 единиц.

К концу 6 сентября:

Slide6

ВАЖНО: Мы хотим, чтобы НА РУКАХ колебалось в желтой зоне, изредка ненадолго заходя в зеленую зону и очень редко и очень на немного заходя в красную зону.

ПОЧЕМУ МЫ НАЗЫВАЕМ БУФЕР МЕХАНИЗМОМ УПРАВЛЕНИЯ?

Потому что он дает нам сигналы раннего предупреждения для восстановительных/выправительных действий:

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

Конкретные управленческие действия в рамках управления буфером предпринимаются в соответствии с алгоритмами ТОС для управления запасами.

То, что представлено здесь и в предыдущей записи, это только один элемент механизма Буфер Запаса.

Например, для правильного расчета целевого уровня буферов запаса (это еще один элемент концепции и механики «Буфер Запаса») необходимо:

  • учитывать профиль спроса каждой данной SKU,
  • уметь правильно рассчитать надежное время пополнения (и это НЕ ТО ЖЕ САМОЕ, что «время реакции поставщика»/»логистическое плечо» и т.д.),
  • учитывать сезонность и пики,
  • учитывать собственные акции и промоции,
  • учитывать требования поставщиков по представленности на полке и планограммам,
  • учитывать ввод нового продукта и вывод стареющего продукта,
  • понимать и учитывать поведение внутри групп продуктов (категорийный менеджмент),
  • знать, как рассчитать буфер при поставке той же SKU несколькими альтернативными поставщиками с РАЗНЫМ временем пополнения и надежностью,
  • знать, при каких условиях и каких сигналах целевой размер буфера изменяется, когда и на сколько,
  • и т.д.

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

И нужно четко понимать, что функция ПОПОЛНЕНИЯ ЗАПАСА есть в ЛЮБОЙ МОДЕЛИ УПРАВЛЕНИЯ ЗАПАСАМИ. Сам по себе факт пополнения и даже введение цветовых зон — не основание для заявления о том, что «мы управляем запасами по буферам ТОС».

Посмотрите программу модуля Управление дистрибуцией и розничной торговлей по ТОС.

Читайте продолжение

Опубликовано Еленой Федурко, 31 августа 2016

Читать/оставить комментарии

5 ответы
  1. Giedrius Balnys says:

    Пишу как разработчик и внедренец ПО для управления запасами по ТОС – СтокМ. При внедрениях системы управления запасами, не всегда у людей, работающих с системой есть глубокие знания подхода ТОС, даже наоборот — часто они о ТОС даже и не слышали. По этой причине мы должны были делать систему как можно больше понятной любому. Все три составляющие буфера (три «места нахождения запаса») отображаются в цифровом значении при каждом СКУ на каждом месте хранения в столбцах «Остаток» (на руках), «В пути» и «Заказать». Для быстрого восприятия ситуации соотношения остаток/буфер и (остаток+в пути)/буфер отображаются в соответствующих цветах буфера. Отчет показывает 2 колонки — первая показывает ситуацию на руках («остаток»), вторая — что будет, когда прибудет все что в пути. По ним очень просто понять, что у вас сейчас и чего ждать в ближайшем будущем. Если СЕЙЧАС на руках зеленое и желтое, то все хорошо. Если СЕЙЧАС красное, но второй столбец (ЧТО БУДЕТ, КОГДА ПРИДЕТ ТО, ЧТО В ПУТИ) зеленый — значит остаток маленький, но пополнение уже в пути. Стоит проверить как скоро прибудет пополнение. Ну а если оба столбца красных, то это сигнал, что у вас могут быть неприятности из-за возможного отсутствия товара.

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

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

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

    Ответить
    • Jelena Fedurko
      Jelena Fedurko says:

      Гедрюс, спасибо. Поддерживающий комментарий к тому, что Вы написали.
      Логика ТОС решений понятная и четкая. Но для того чтобы эту логику претворить в работающий инструмент, нужно также понимание механики решения и умение соотнести эту механику с конкретными условиями, в которых оперирует компания.

      Ответить
  2. Наталья Анисимова says:

    Хотела бы прокомментировать последний абзац Елены. К сожалению, часто слышим слова типа: «мы уже так и управляем в нашей компании, только не называем это буфером и цветов у нас побольше». Вторая крайность, с которой сталкиваемся все чаще, когда консультанты или ИТ-компании, не проходившие обучение и не имеющие поддержки экспертов, пытаются продать и внедрить управление запасами по ТОС. Недавно на презентации Stock-M нам рассказали о случае, когда руководитель ИТ-компаний, проводя презентацию своего продукта говорил, что он был на референс-встрече с компанией, внедрившей Stock-M, и после встречи он повторил алгоритмы управления запасами по ТОС в своем продукте. Однозначно, что данный продукт не может быть грамотным с точки зрения решения ТОС для управления запасами.
    Действительно, какие-то алгоритмы пополнения, возможно и с цветовой индикацией, могут быть во многих компаниях или предлагаться разными консультантами, но называть это теорией ограничений, неправильно. 30 минут просмотра продукта не могут дать понимания алгоритмов, зашитых внутри процедур внедрения.
    Возможно, ошибочно думают, что реализация принципа «вытягивания», когда пополняется то, что ушло со склада/из магазина – это и есть «весь ТОС» и это легко. Но, во-первых, мы часто слышим от программистов компаний, что они реализовали алгоритмы прозрачного разумного пополнения (это могут быть и ТОС-алгоритмы и какие-то свои), а сотрудники ими не пользуются. А значит важна не только программная реализация, но и работа с пользователями программы, которые понимают, что здравый смысл – это хорошо, но возникает много «а что делать, если». Некоторые из этих «если» Елена перечислила: если товару свойственны резкие сезонные колебания, или на товар объявлена акция и мы ждем резкого роста спроса, если есть товары-аналоги, если есть альтернативные поставщики с отличающимися условиями поставки и много других «если». Это хорошие рабочие вопросы, которые задаст сотрудник с опытом в управлении запасами, и, если он не получит ответ, что это реализовано в системе и реализовано также понятно и прозрачно, как механизмы буфера и динамического управления буфером, то с доверием относиться к программному продукту он не будет. Поэтому появляется во-вторых – несмотря на простоту и понятность всех решений ТОС, все алгоритмы должны быть системными. Мы должны уметь учесть различные «если» и при этом не навредить работе механизмов буфера и динамического управления буфером.
    ТОС – это методология улучшения систем, с набором конкретных практичных взаимосвязанных инструментов. ТОС — также и философия системного подхода улучшения бизнеса. Это намного глубже и эффективнее, чем «мы уже так и управляем, только не называем это буфером и цветов у нас побольше».

    Ответить

Ответить

Want to join the discussion?
Feel free to contribute!

Добавить комментарий