Коллеги, внимание!
Форум переехал в Facebook в нашу группу «Фокусировка на главном».
Прошу задавать свои вопросы и открывать новые темы в группе, там вы сможете оперативно получить ответы.
Перейти в группу
- В этой теме 23 ответа, 4 участника, последнее обновление 8 лет, 1 месяц назад сделано
.
-
Сообщения
-
Помогите начинающему…
Рассматриваем вариант использования TOC для управления запасами (DTA).
Имеем:
1. Центральный склад (ЦС), с которого идут все поставки клиентам.
Сроки поставки на текущий момент удовлетворяют заказчиков, поэтому вопрос с региональными складами не рассматриваем.
2. Срок поставки товаров от поставщиков на ЦС от 4х до 16ти недель (заграница)
3. Минимальных партий заказа у поставщиков практически нет. Размер партии сейчас выбирается только исходя из логистических затрат.
4. Даты заказа выбираются эмпирически 🙂Смоделировал DTA для нескольких товаров. Ситуация получилась, мягко говоря, неприличная: уход запасов в ноль, упущенные продажи…
Прикладываю картинку примера такой модели (Срок поставки — 4 недели, заказ по продаже, период изменения буфера — 4 недели)
Что я делаю не так? Или это в принципе не работает и без ручной корректировки (или корректировки на основании статистики прошлых периодов) здесь не обойтись.Доброго дня, Сергей!
Не перестаю повторять, что: «Самое главное в поставках — это продажи!» (с)
Состояние «до» указывает что за год у вас произошло 20 продаж (это не гарантирует что в следующем году их тоже будет 20). В среднем по 1 продаже в месяц (исключение: июль — 6 продаж), что говорит о ярко выраженной сезонности на данную позицию. Величина единовременной продажи около 20 единиц. Повторяющиеся ли это продажи одному клиенту или просто наиболее часто закупаемая партия — вам виднее. Факт остается фактом: 7 продаж из 20 количественно близки к 20. Возможно это и есть оптимальное количество товара на складе в несезон, например, с коэффициентом 2. По факту продажи — делаете закуп.
Оптимизация размера партии в угоду выгоде на транспортных расходах — довольно типичное явление. Тут важно понимать какова стоимость доставки (транспортных расходов) в цене закупаемого товара. Если это единицы %% — подход один, если счет идет на десятки %% — совсем другой.
Разница в сроках доставки составляет по вашим словам 4 раза (от 4 до 16 недель), что дает разницу в запасах в те же самые 4 раза… Наиболее типичный срок какой? 8 недель? В частности, за год вам показалось разумным закупить продукцию 4 раза, что едва ли может считаться оптимальным. Разницу в курсе валют в данном контексте смысла учитывать нет. По сути вы вообще закупили продукцию всего 2 раза, под сезон (июнь-август). И не угадали, осталось много лишнего, а оно стоит денег, которые оказались заморожены в товаре. Если еще учесть что в ноябре мегасделки на 50+ единиц могло и не случиться, то результат мог оказаться еще более печальным.
Ответ на вопрос «что я делаю не так?» банален: вы не учитываете сезонность и длинный срок поставки товара до вас,
Николай, спасибо за ваши разъяснения.
По поставкам:
Сроки поставки в 4-8 недель — это по разным позициям, т.к. едут они из едут разных стран. По той, по которой я привел пример, срок поставки в среднем 4 недели.Как необходимо учитывать сезонность? Корректировкой буфера за период поставки? Т.е. в данном примере, в середине мая буфер должен быть увеличен втрое?
Что значит учитывать длинный срок поставки? Каким образом это необходимо делать?Длинный срок поставки означает, что от момента принятия решения, основанного на изменении состояния буфера, до момента поступления товара на склад ситуация может кардинально измениться. Пример «после» это наглядно демонстрирует:
В начале года у вас «оптимальный запас» в 50 единиц, вы его расходуете, но не восполняете, т.к. продаж мало. Размер буфера по той же причине сокращается (таков алгоритм) и к сезону у вас минимальный буфер, а должен быть максимальным! Как только продажи пошли вы заказываете, но уже поздно… 4 недели доставки не позволяют вам иметь продукцию тогда, когда ее хотят получить покупатели (минуса по июлю). Если бы срок поставки был не 4 недели, а 4 дня, то проблем бы не возникло: вы бы успевали восполнить товар быстрее, чем появится следующая сделка. Значит, необходимо заранее рисовать прогноз: прогнозируете 3 крупных сделки на июль, втрое чаще чем в другие месяца? Ок, но тогда придется к концу мая заказывать в 3 раза больше, не обязательно одной партией! Аналогично на выходе из сезона, перестаете ориентироваться на сезон в конце июня и делаете стандартные закупки в размере обычной партии раз в месяц и далее отгрузки по факту продаж. По сути с такими сроками вы для данной позиции проходите сезон поставками раньше его выполнения в реальных продажах, это и есть «длинный срок поставки».С этой неопределенностью иначе справиться не получится, только прогноз динамики. Из представленного графика в первом приближении я бы предложил начальный буфер 40(20х2), который будет увеличен до 120 (+/- в зависимости от реалий средних продаж) в конце мая и возвращен обратно к 40 к началу июля. В общем случае описываются процедуры входа/выхода из сезона, их сдвиг (соразмерно сроку поставки) чтобы не изобретать каждый раз велосипед, а просто действовать по шаблону.
Альтернативный метод может заключаться не в изменении размера буфера, а просто в увеличении частоты отгрузки: например весь июнь отгружаем каждую неделю по 20-30 единиц. Все определяется динамикой продаж, ее повторяемостью.
Динамическое управление буфером работает неверно — увеличение буфера происходит слишком поздно.
Если товар реально сезонный, можно буфер увеличивать перед сезоном «руками», или на автомате.
Коллеги,
Если управлять «руками», то каков процент таких позиций, по вашему мнению, должен быть от общего числа? Т.е. какой процент желательно автоматизировать с применением ДУБ и коэффициента сезонности? Или нужно исходить только из существующих человеческих ресурсов, т.е. сколько менеджер готов тратить время на ручную корректировку?
По сезонности:
Каков порог сезонности? Например, для вышеуказанного примера, берем порог — 40 на периоде в месяц: июль и ноябрь — выше порога (по статистике) — для них делаем корректировку исходя из планового объема.
Или необходимо использовать коэффициент сезонности, например, помесячно. Т.е. берем статистику за прошлые периоды, ставим объем продаж для января, как стартового месяца (и стартового размера буфера), 100% и далее для каждого месяца определяем коэффициент корректировки, который будем использовать.PS во всем этом меня беспокоит то, что это уже не ДУБ и я начинаю, отходя от технологии TOC, «изобретать велосипед»…
Сергей, у вас продажи вообще реальные, или это просто матмодель? Что за товар, если продажи реальные? Почему такие редкие продажи?
Сергей, а какова альтернатива? Посмотрите на ваш вариант «до»: полгода закуп курил бамбук, в итоге к середине мая на остатках ноль, возможно, вы даже упустили продажи целого месяца когда закуп очнулся от сна увидев 0 на остатках и заказал сразу 100 единиц (зачем столько?). Через месяц их торкнуло еще раз и они заказали еще 150(!), видимо о сезонности они таки догадывались. Итого вы впалили денег на 250 единиц продукции, которую продавали весь оставшийся год и еще осталось. Это лучше?
Возьмите калькулятор и подсчитайте какой вариант вам стоил дороже — это и будет ответом на ваш вопрос. И какова вероятность что в следующем году (для другой позиции) закуп будет действовать как то иначе? Из каких соображений они решили закупать 100 и 150 единиц? И что бы вы делали закажи они еще больше?* Сезонность — это всякое изменение в динамике спроса, которую не способен отработать в штатном режиме обычный алгоритм восполнения.
Виктор, это реальные продажи одного из товаров. В данном случае — это фильтрующая бумага для цитологического стекла в упаковке по 200 шт.
Подготовил еще модели по более ходовым товарам, но в итоге там так же присутствует сезонность и нужно понять как ее обрабатывать.Николай, я не против, я — за 🙂
Нужно только понять механизм управления буфером для таких (с сезонностью в продажах и длинным сроком пополнения) товаров. Я просто сетовал на то, что его нет в TOC. Если он есть у вас или у других коллег — прошу поделиться или навести на правильные мысли 🙂Я не знаю что вы хотите получить в итоге ) Свое видение плюсов и минусов работы с DBM (ДУБ) я описал тут: https://tocpeople.com/2015/10/kogda-svetofor-bespolezen/
Применяя DBM вы однозначно получите управляемый процесс, который мало зависит от конкретных исполнителей, от их желания/нежелания следовать алгоритму. Это хорошо, это наглядно, просто и в большинстве случаев достаточно. Применительно к вашему конкретному случаю все сложнее, поскольку логика реагирования на изменение состояния буфера перестает работать из-за длительности срока поставки.
Направлений решения два: прорабатывайте вопрос ускорения скорости доставки, оно наверняка будет дороже, но эффект от сокращения ТЗ это с легкостью нивелирует, либо больше внимания уделяйте планированию/анализу того кому и как много вы продаете.
Применяя DBM вы однозначно получите управляемый процесс, который мало зависит от конкретных исполнителей, от их желания/нежелания следовать алгоритму.
DBM не предназначен для этого. И эту проблему с помощью DBM Вы не решите.
Сергею: сделайте просто буфер. Заставьте каждый день менеджеров следить. Пусть вручную меняют уровень. Политику заказа в соответствии с DTA. И будет Вам счастье. Если Вы не можете заставить менеджеров работать по другому — не надейтесь DBM Вас не спасет.
[quote quote=9144]DBM не предназначен для этого. И эту проблему с помощью DBM Вы не решите.[/quote]
Роман, если вы не согласны в чем то со мной, это еще не повод делать безапелляционные заявления. Игнорирование сроков поставки и «тупое» следование алгоритму представлено во вложении (вариант «после»).
Откройте новую тему или пишите комменты под статьей, благо дизайн сайта обновился.
Николай, Вы пытаетесь сделать из DBM то для чего он не предназначен: полную замену менеджеров. Если у Вас менеджеры плохо работают — DBM Вам не поможет.
Это логика зашита в S&T DTA отсюда и моя безапеляционность. Вторая инъекция предписывает ввести буферы и ежедневно их отслеживать. Если Вы не можете заставить менеджеров это делать — Вы не выполнили инъекцию 2, а значит к 5-ой (DBM) можно не приступать.
Слова Одеда: Основной эффект от MTA/DTA в том, что мы теперь КАЖДЫЙ ДЕНЬ СЛЕДИМ ЗА ОСТАТКОМ (вспоминаем инъекцию 1). Согласитесь если бы это было возможно при старой системе — результат был бы тоже улучшен. Проблема в старой системе в том, что менеджер смотрит на остаток и не понимает — это мало или много. Мы вводим буфер и даем ориентир менеджеру (инъекция 2). Недостаточно смотреть на свой буфер ежедневно — если ты не знаешь что происходит вниз по потоку. Так как накопленный заказ там может свалиться на тебя как ком. Поэтому получаем инфу от клиента о ежедневном потреблении и соответственно отправляем вверх сами (инъекция 3). Если мы можем на основе этой информации начать часто пополнять — мы не ждем 4 недели, чтобы сделать заказ, а заказываем чаще (4 инъекция). Во втором шаге мы можем ошибиться в определении буфера, либо может измениться время пополнения или спрос — в итоге нам надо менять размер буфера. Но мы его не пересчитываем, а задаем простое правило, опирающееся на зоны буфера. МЕНЕДЖЕР обязан применять это правило, а после этого принимать решение следовать ему или нет. (инъекция 5 — DBM).
Вам почему то кажется, что DBM — это программа. Но реализация DBM в программе — это лишь облегчение работы менеджера.
Расплодилось реализаций DTA в продуктах (я как минимум 5 знаю, и еще 2-е конторы собирались делать), а эффект от их использования падает. Дошло до того, что Гедрюс перестал давать кому попало внедрять Stock-M. Все эти горе попытки только бренд ТОС портят. Не дай Бог еще и 1С что-нибудь в свое УПП ввернет — пойди потом заказчикам докажи, что это не ТОС виноват, а плохие методологи в 1С и плохие внедряторы-недо-консультанты.
- Форум «Теория ограничений: инструменты и практика» закрыт для новых тем и ответов.