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

“Из-за чего производители недовольны своими ERP системами”. Перевод материалов блога Эли Шрагенхайма

После долгого перерыва Эли Шрагенхайм начал публиковать одну статью за другой. Статья, которой я хочу с вами поделиться, с одной стороны – рекламная, продвигающая новый проект, который связан с внедрением подходов ТОС в производство. Гораздо более глубоком и очень полезном внедрении, нежели это можно сделать просто прочитав книгу “Цель”

Похоже, что Эли нашел команду, которая готова автоматизировать ДЕСЯТИЛЕТИЯ его методических наработок в части планирования и управления производством.

И хотя в статье есть ссылки на ресурсы и, вроде бы, мне не очень хорошо публиковать “чужую” рекламу, но… Это не просто реклама, в ней просто и доходчиво объяснены основные ключевые моменты, почему ERP и APS не решают проблемы производства.

И что должно быть в настоящей производственной системе, поддерживающей принятие решений (DSS).

А еще, уже не раз бывало так, что Эли выпускал свои публикации в тот момент, когда у нас появлялось какое-то решение, которое УЖЕ содержит в себе рекомендуемые им методические подходы.

Так и в этот раз. Эли выложил свою статью 29 ноября 2023, а 15 декабря 2023 мы официально объявили о выходе производственной системы, в которой ВСЕ ЧЕТЫРЕ критических открытия, о которых пишет Эли – реализованы.

Вот ссылка:

Так что, читайте, просвещайтесь, комментируйте крутого Эли Шрагенхайма.

Как обычно, ссылка на оригинал и все медиафайлы из блога автора.

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

P.S.: И статья ОГРОМНАЯ и резать ее в этот раз я не стал, так что удачи в борьбе с “многабукаф”. Русские субтитры в Youtube вполне адекватны


Включите субтитры, если вы хотите смотреть это видео без звука

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

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

Я жду ваших комментариев здесь или здесь: on my Linkedin post.

Фундаментальный базовый разрыв

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

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

Вот очень обобщенное описание этих двух критических проблем:

  1. ЧТО ОБЕЩАТЬ: что мы можем пообещать нашим клиентам, гарантируя высокую вероятность исполнения обязательств?
  2. КАК ВЫПОЛНИТЬ СВОЕ ОБЕЩАНИЕ: как только мы взяли на себя обязательства перед клиентом, как мы можем обеспечить выполнение в срок и в полном объеме?

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

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

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

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

Вопрос к разработчикам ERP:

Каким образом, этот огромный объем данных, уже собранный вашей ERP, помогает преодолеть две критические проблемы ваших клиентов?

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

Производственные компании выглядят очень сложными. Хотя описание всего процесса от подтверждения заказа клиента до его исполнения – задача нетривиальная, инструменты ERP достаточно хорошо справляются с таким уровнем сложности. Но синхронизация всех запущенных заказов на производство, которые конкурируют за мощность ресурсов – это большая проблема. Следовательно, несмотря на то, что выполнение одного конкретного заказа с высоким приоритетом не является проблемой, достижение высоких показателей OTIF (on-time, in full – в срок и в полном объеме) кажется очень сложным.

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

Обещайте, а потом выполняйте

Отслеживание показателей мощности – задача также нетривиальная. Только необходимость иметь дело с переналадками значительно усложняет ситуацию. В 90-е годы с появлением мощных компьютеров, способных обрабатывать миллионы записей данных, появилась идея создания оптимизированного расписания, которое бы учитывало все открытые заказы, все технологические маршруты, доступную мощностью на любой момент времени, которая привела к появлению волны программных продуктов, которые были названы APS (advanced planning and scheduling systems – продвинутые системы планирования и построения расписания). Предполагалось, что эти системы позволят обеспечить идеальное планирование, что означало бы что его можно выполнять просто, обеспечивая достижение всех задач плана. Если бы это сработало, то была бы решена и вторая проблема.

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

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

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

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

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

Здесь нам на помощь приходят открытия Теории ограничений (TOC).

Ключевое открытие № 1:

Очень небольшое число ресурсов, обычно всего один, на самом деле лимитируют результат системы.

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

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

Ключевое открытие № 2:

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

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

В производстве мы различаем производство под заказ (make-to-order (MTO)) и производство на склад (make-to-stock (MTS)).  Подавляющее большинство производственных компаний производят как под заказ, так и на склад, иногда в рамках одного заказа на производство находится объем, который был обещан к определенной дате (MTO) в то время, как производственная партия включает в себя и объем продукции, предназначенный для покрытия будущего спроса (MTS). Это создает большую путаницу и делает жизнь руководителя производства, которому необходимо найти все элементы для конкретного заказа клиента, в непрекращающийся кошмар.

Вы будете удивлены, но даже самые популярные ERP системы не делают различий между MTO и MTS. Если вам интересно, почему компания, совершенно очевидно работающая в среде MTS, управляет своим производством в режиме MTO, проверьте настройки по умолчанию в их ERP системе (и посмотрите мое видео, где я подробнее это объясняю).

Моя команда обнаружила одну ERP систему – Odoo, которая четко различает MTO и MTS. Это делает Odoo сильным претендентом на то, чтобы стать платформой, на которой можно разработать необходимый функционал, который поддержит ключевые открытия ТОС. Мне не терпится увидеть как эти функции уже отвечают на два критических вопроса, и я жду, чего еще мы можем достичь в будущем. Вообще говоря, эти возможности реализуемы и на других ERP системах.

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

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

Ключевое открытие № 3:

Статус буфера предоставляет ОДНУ четкую схему приоритетов!

В TOC мы называем это «Управление буфером». Идея состоит в том, чтобы определить статус буфера как процент его остатка. Как уже упоминалось, в производственной среде чистое время обработки «тач-тайм» (touch time) заказа – это очень маленькая часть фактического времени производства (production lead time). Большая часть времени производства тратится на ожидание того, когда рабочий центр закончит работать над предшествующими заказами. Таким образом, если конкретный заказ становится высокоприоритетным, время ожидания для такого заказа будет значительно сокращено, а значит и время производства тоже сократится.

Заказы в среде MTO используют буферы времени, тогда как заказы в среде MTS используют буферы запаса. В идеале мы должны отслеживать как заказы MTO, так и заказы MTS orders в одной очереди, как показано на рисунке 1 ниже. Когда до даты поставки остается только треть или меньше буфера времени или на руках только треть или меньше буфера запаса, статус буфера этого заказа рассматривается как КРАСНЫЙ, что означает, что заказ имеет наивысший приоритет. Как только красный приоритет получает максимальный приоритет, время ожидания редко сокращается. Руководитель производства столкнувшись со списком из нескольких красных заказов, может решить меры по их ускорению, чтобы обеспечить быстрый поток красных заказов, что все они были завершены к дате отгрузки.

Для среды MTS статус буфера – это процент запаса, оставшегося на руках в сравнении буфером запаса, который включает в себя еще и незавершенное производство. Следование одной схеме приоритетов, использующей как буферы запаса, таки буферы времени значительно улучшает вероятность достижения высокого уровня исполнения обязательств. Это возможно главным образом тогда, когда существует  некоторый уровень избыточной мощности, даже на ограничении, и еще больше на небольшом числе других относительно сильно загруженных ресурсов. Однако, когда спрос растет, то в какой-то момент времени число заказов в КРАСНОМ резко возрастает. Когда эта ситуация происходит, это подает сигнал: не существует способа выполнить свои обязательства без значительного увеличения мощности.  Мы можем назвать оповещение такого типа «слишком много в Красном».

В управлении буфером проникновение в красную зону инициирует мероприятия по экспедированию конкретного заказа на производство (и связанных с ним заказов на производство). Когда количество КРАСНЫХ заказов, тех, которые попали в красную зону, резко возрастает -–возникает настоящее «бутылочное горлышко» (Рисунок 1)

Ключевое открытие №4:

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

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

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

1. Мы получаем точный прогноз времени исполнения нового заказа!

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

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

Плановая загрузка должна пересчитываться каждый день. Отличие сегодняшней плановой загрузки от завтрашней состоит в том, что заказы, обработанные ресурсом сегодня, исчезают из расчета, а поступившие сегодня новые заказы – добавляются. Когда плановая загрузка  ограничения растет (см. правый экран на Рисунке 2), это означает, что поступает заказов поступает больше, чем ограничение способно обработать. Если эта тенденция продолжится в течение какого-то времени, это может означать: появляется «бутылочное горлышко». Вы или окажетесь неспособны выполнять заказы в срок (и страдать от неудовлетворенности клиентов) или будете вынуждены увеличить сроки исполнения заказов (и, следовательно, потерять часть доходов, если ваши конкуренты смогут работать быстрее). Если тенденция показывает снижение (как показано на левом экране на Рисунке 2), это означает, что мы получаем меньше заказов и можем их исполнять быстрее.

Тенденция изменения Плановой загрузки ресурса с ограниченной мощностью (CCR) – это индикатор того, станет ли CCR «бутылочным горлышком» или все еще сохраняется значительная защитная мощность (Рисунок 2).

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

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

Тщательная балансировка между спросом и мощностью

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

Ценность сочетания управления буфером и плановой загрузки была тщательно проверена с помощью разработанного мной в 90-е симулятора MICSS, который был разработан для проверки различных политик в отношении производства и их влияния на бизнес. Когда рыночный спрос начинает расти, то через какое-то время неожиданно увеличивается количество «красных» заказов. Существующие на тот момент показатели исполнения заказов все еще остаются адекватными ситуации. Но если продолжить симуляцию еще в течение одной-двух недель, то ясно видна катастрофа с исполнением заказов. Я надеюсь и желаю, чтобы реальность вашего предприятия была значительно лучше такой ситуации!

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

Я и моя команда в Enterprise Space, Inc. полны решимости добавлять новые алгоритмы и визуализацию данных в ERP системы, которые позволят менеджерам концентрироваться только на действительно важных вопросах.

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

Включите субтитры, если вы хотите смотреть это видео без звука

Обоснование метода “Упрощенный Барабан-Буфер-Канат”

Прежде, чем продолжить говорить про использование подхода “Упрощенный Барабан-Буфер-Канат” в управлении поставками, стоит сделать небольшое отступление.

Изначальный вариант решения для производства, который появился во всех книжках, называется “Барабан-Буфер-Канат” (Drum-Buffer-Rope). В этом решении было два буфера: один буфер, который измерялся во времени, защищал работу ограничения, а второй буфер защищал наши обязательства перед клиентом.

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

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

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

Итак, во второй половине 90-х правило двух буферов было поставлено под сомнение. И Эли Шрагенхайм обосновал подход, который сейчас называется “Упрощенный Барабан-Буфер-Канат”. Идея этого подхода состояла в том, что клиентам все равно, где находится наше внутреннее ограничение. Никого из наших клиентов не интересует, где находится наше внутреннее ограничение.

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

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

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

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

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

И в книге “Синдром стога сена”, эта ситуация рассматриваетс, но надежного ответа – нет. В книге описана необходимость создания каких-то сложных защитных связей между ограничениями.

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

Это была революционная история!

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

Вопрос: а зачем она берет столько времени на исполнение заказа?

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

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

Но чтобы это работало, нужна еще одна дополнительная штука: мы должны знать сколько мы уже на напринимали заказов. То есть в дополнение к буферу заказа нам нужно добавить еще обязательный механизм: контроль загрузки нашей мощности. Для производства критически важно, потому что если мы напринимали заказов и, грубо говоря, мы обещаем клиенту 10 дней, и у нас технологическое время один день, и одновременно у нас уже принято 10 заказов, то, когда мы пообещаем клиенту время исполнения закза, а на самом деле мы точно будем опаздывать. Потому что пока очредедь дойдет до этого заказа, мы уже опоздаем. Поэтому применение метода “упрощенный Барабан-Буфер-Канат” на производстве требует одновременного использования контроля загрузки мощности.

О необходимости контроля мощности

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

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

В уже упоминавшейся книге «Управление цепями поставок с невероятной скоростью» Эли Шрагенхайм предлагает очень полезный механизм контроля за мощностью — метод Планируемой загрузки (Planned Load). Суть его состоит в том, что мы учитываем технологическое время, необходимое для производства всех заказов (в нашем случае — на пополнение склада) и сравниваем его со стандартным сроком производства (пополнения). Пока суммарное технологическое время по открытым заказам много меньше, чем срок пополнения, у нас все в порядке, но… Как только у нас появляется ресурс, планируемая загрузка по которому начинает достигать 80% от срока пополнения — это сигнал, что у нас потенциальные проблемы с мощностью и нужно предпринимать дополнительные усилия по поиску возможностей дополнительного увеличения мощности за счет вывода дополнительных смен, сверхурочных, поиска контрагентов и т.п. Я рекомендую ознакомиться с материалом на эту тему[1].

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

  1. Достаточность оборотного капитала. Необходимо постоянно мониторить достаточность оборотных средств для поддержания необходимого уровня запасов в цепи поставок. Нехватка или ограничение оборотного капитала способны похоронить любые перспективы. Это параметр следует постоянно держать под контролем. Если вы попадаете в ситуацию с нехваткой оборотного капитала, то первое, что вы должны делать — это предпринимать максимум усилий по выходу из этой ситуации. Это очень опасная и нежелательная ситуация.
  2. Производственная мощность. Это способность выпустить требуемый ассортимент в разумные сроки.
  3. Складская мощность. Если на ваших складах невозможно разместить хотя бы половину ваших буферов, то, скорее всего, проблемы с наличием вам гарантированы.
  4. Транспортная мощность. Ее дефицит часто не сразу заметен, но между тем он также способен подорвать уровень наличия в цепочках поставки.

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


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

Еще раз про DDMRP и сравнение с подходами НЕТ Сток Про

Причиной, побудившей меня написать этот пост, стал комментарий к моему посту про сравнение решений управления наличием Теории ограничений и DDMRP, который (судя по его содержанию) оставили наши друзья-коллеги-конкуренты из Украины, которые занимаются продвижением этой методологии на территории РФ и пост-советского русскоязычного пространства.

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

Итак, методология DDMRP была разработана Кэрол Птак (Carol Ptack) и Чэдом Смитом (Chad Smith), которые сегодня являются со-президентами Института DDMRP. Оба являются выходцами из Теории ограничений, Кэрол – соавтор нескольких основополагающих методических книг в области решений Теории ограничений по управлению наличием в цепях поставок и интегрированными цепочками поставок. Почему и как они приняли решение развивать самостоятельный бренд – мне неизвестно. Но конфликта между DDMRP Institute и TOCICO нет, Кэрол выступала на ежегодной конференции 2020 года, которая прошла онлайн.

ОФФТОП: с 2020 года стоимость членства в TOCICO для россиян составляет $97 в год, вместо $275 в год, как было раньше, и дает доступ к огромному массиву видеоматериалов и записей вэбинаров, в том числе можно посмотреть и выступление Кэрол Птак в 2020 году

На картинке можно посмотреть на плечах каких “гигантов” стоят разработчики DDMPR:

Этот слайд я использую в курсе “Глобальная закупочная логистика”, которую преподаю магистрам в Высшей школе управления и бизнеса в Политехе.

На этом же слайде видно, где находятся наши программные продукты NET Stock Pro (система управления наличием в цепях поставок) и NET Operations (система поддержки принятия решений для производства в “смешанной” среде), которые мы относим к классу DSS – Decision Support Systems и обозначаем как ViableDSS – жизнеспособная система поддержки принятия решений.

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

Для тех, кому лень ходить по ссылкам, коротко повторю основные выводы:

  1. При длинных сроках пополнения и достаточно больших минимальных партиях поставки решение DDMRP выигрывает у “классического” решения ТОС.
  2. Адаптированное нами решение управления наличием показывает чаще всего лучшие или сопоставимые результаты с DDMRP.
  3. В DDMRP “из коробки” нет решений для управления в среде “под заказ”, в этом случае, все передается на откуп алгоритмам MRP.

Если вы обратите внимание на картинку, то можно увидеть пунктирную стрелку, которую я провел от DDMRP к нашему программному продукту NET Operations.

В отличие от TOCICO в DDMRPI есть система сертификации ПО, на предмет соответствия методологии DDMRP. И мое погружение в методологию было связано с тем, что мы рассматривали возможность получения compliance DDMRP для нашего NET Stock Pro.

В ходе общения с Чэдом Смитом и изучения требований и методики было принято решение, что мы не будем УХУДШАТЬ возможности программного продукта, чтобы пройти по формальным критериям соответствия методике.

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

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

И второй момент из DDMRP, над использованием которого я продолжаю размышлять, это изменение правил для проведения ЖЕЛТОЙ границы буфера и величины ЗЕЛЕНОЙ зоны. Потому что в подходах DDMRP есть полезная смысловая интерпретация этих величин.

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

И я приоткрою “мааааленький” секрет почему – Кэрол и Чэд так и не решились отказаться от использования средних значений. Поэтому они остались в рамках проклятия “Среднестана” (как его называл Нассим Талеб), а мы рискуем ходить в “Крайнестан” и возвращаться оттуда с добычей.

Но это уже отдельный большой разговор…

Видео-отзывы наших клиентов. Часть 3. Компания “ПИР”

Это завершающий 2019 год пост в моем блоге. Поэтому я решил опубликовать видео-отзыв, который дала нам Екатерина Еселева, коммерческий директор компании “ПИР”, производящей снэки.

С наступающим 2020 годом всех вас и повышения эффективности ваших бизнесов в новом году.

До встречи в новом 2020 году!

У меня еще много чего есть, чем стоит поделиться :))

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

Видео-отзывы наших клиентов. Часть 2. Компания “Стройком” Санкт-Петербург

Продолжаю публиковать отзывы наших клиентов.

С Андреем Михайловичем Ледовских мы познакомились на проекте в компании “СтройКом”. Теперь он работает исполнительным директором в компании РемСтройГрупп и продолжает использовать наработки, которые нам удалось получить в процессе проекта.

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

Слово клиенту:

Представляю решение для управления производством NET Operation

У нас с партнерами есть правило, которое выглядит сегодня быть может сильно старомодным, но… Мы сначала делаем, потом об этом рассказываем.

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

Это решение, которое поддерживает алгоритмы Теории ограничений для смешанной среды в производстве.

И мы готовы представить его на суд публики. Для этого мы создали отдельный плейлист на Ютубе. Он влючает в себя 15 видео роликов с кратким обзором возможностей нашего продукта.

А первое видео из этого плейлиста я размещаю здесь: