Управление смешанным производством на заказ и для обеспечения наличия

Управление смешанным производством на заказ и для обеспечения наличия

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

Критически важное понимание, появившееся в Tеории ограничений (ТOC) около двухтысячного года:

Должно быть четкое разделение между заказами клиентов, в которых установлены объемы и сроки, а также заказ-нарядами на склад!

Это НЕ обычная практика, которая стремится объединить объемы, необходимые для обеспечения заказов клиентов, с объемами запасов на складе, необходимыми по прогнозу. TOC явно решила не объединять заказы клиентов с разными сроками выполнения в один рабочий заказ. Но ранее даже ТОС использовала назначение искусственных сроков выполнения для заказов на склад. С пониманием, что для заказов на склад не нужно назначать срок выполнения, ТОС достигла подлинного разделения между производством на заказ (MTO) и на склад (MTS) / для обеспечения наличия (MTA). Это значительно упростило процесс производства, выделив два разных типа потока с двумя разными типами буферов: времени и запасов.

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

В некоторых случаях комбинация MTO и MTS применяется к одному и тому же товару (SKU). Например, товар обычно производился на склад (MTA), но если появилось несколько очень больших заказов, которые могут быть больше, чем весь буфер запасов, тогда лучше применить МТО. Еще один довольно распространенный случай касается поставок крупным клиентам, таким как производители автомобилей, которые дают поставщику скользящие прогнозы на несколько недель вперед, но затем ожидают получить несколько другие количества. Здесь также предпочтительным решением является комбинация MTO и MTA.

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

Существуют ли общие проблемы в управлении производством продуктов, которое содержит как MTA, так и MTO?

Буфер MTO основан на времени. Заказ запускается в производство по приоритетности срока его выполнения. Таким образом, потребление буфера является линейным – буфер потребляется изо дня в день в одном и том же темпе. Важным шагом в методологии TOC было использование Планируемой загрузки, загрузки самого слабого звена / ограничения, чтобы определить «безопасную дату» для любых входящих заказов. Это обеспечивает механизм сглаживания временных пиков спроса за счет увеличения обещанного клиенту срока выполнения заказа на основе входящего спроса. Механизм безопасной даты смягчает загрузку ресурсов и тем самым обеспечивает стабильную работу. В непиковые периоды компания может, в зависимости от своей стратегии, предлагать более короткие сроки выполнения заказов. Это предложение должно быть тщательно продумано, поскольку это может вызвать негативные последствия для клиентов, ожидающих быстрой доставки в любое время и, при необходимости, готовых платить больше за реально быструю поставку.

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

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

Эта разница в поведении заказов не должна вызывать у нас вопроса: если у нас есть два заказа в «красном», один MTO и один MTA, какой из них более срочный?

Необходимо понимать, что:

Управление буфером эффективно, пока есть возможность своевременно поставить ВСЕ заказы в «красном»!

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

Задержка какого заказа нанесет меньший ущерб?

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

Еще рекомендуем:  Малые производственные предприятия должны быть динамичными, а не бережливыми?

Таким образом, если конкурирующие заказы MTO и MTA скоро перейдут в «черные» (просроченные), тогда решающим фактором будет предсказанный ущерб, и он может быть больше как для MTO, так и для MTA заказа.

Когда компания управляет комбинацией MTO и MTA, возникает вопрос:

Каково соотношение потребления мощности самого слабого звена между заказами MTO и MTA?

Причина необходимости «резервировать мощность», скажем, 40% для MTO и 60% для MTA, заключается в том, чтобы обеспечить сглаживание нагрузки для MTO заказов через механизм «безопасной даты». Для этого мы предполагаем, что, в среднем, каждый день 40% доступной мощности будет отдано МТО. Таким образом, мы можем рассчитать запланированную загрузку для заказов MTO, что означает расчет времени, необходимого самому слабому звену для обработки всех текущих заказов MTO. Это время преобразуется в дату, когда учитывается только 40% дневной мощности. Вычисленная дата дает знать, когда самое слабое звено будет свободно для обработки только что полученного заказа MTO. Безопасной датой для этого заказа является расчетная дата планируемой загрузки плюс половина буфера времени для этого заказа.

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

Соотношение 40/60 может создать неправильное впечатление о том, что слабое звено, потенциальное ограничение мощности, планируется использовать на 100% его мощности. Это серьезная ошибка. Обязательства по надежности при поставке МТО заказов и поддержании отличной доступности для МТА всегда требуют определенного уровня защитных мощностей. Даже когда механизм определения безопасных дат для MTO работает правильно, по-прежнему существует потребность в защитной мощности для покрытия непредвиденного времени простоя, необходимости переналадки и, в основном, неточных данных о мощности.

Поддержание отличной доступности продуктов MTA требует БОЛЬШЕ защитной мощности из-за воздействия случайных пиков нагрузки.

Голдратт требовал, чтобы общий объем использования мощности любого ресурса в среде MTA и смешанной среде не превышал бы 80% от доступной мощности. Озабоченность Голдратта была вызвана не просто колебаниями спроса на продукты MTA, но и обеспечением достаточного времени для действий при увеличении общего спроса. Моделирование показывает, что если спрос растет, в какой-то момент количество «красных» заказов внезапно резко возрастает, и это просто вопрос времени, пока многие позиции окажутся в дефиците. Обратите внимание, что поддержание больших буферов компенсирует отсутствия защитной мощности только на короткое время. Использование динамического управления буфером в этот момент делает ситуацию ХУЖЕ, поскольку увеличение буферов увеличивает конкуренцию множества «красных» заказов за ограниченную мощность самого слабого звена, которое превращается в бутылочное горлышко. На этом этапе экстренная политика должна сводить к минимуму буферы, и как можно быстрее стремиться нарастить мощности. Не стоит лишний раз экспериментировать с защитной мощностью, особенно для MTA.

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

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

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

Эта идея основана на важном знании, которое хорошо подходит для завершения статьи:

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

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

Eli Schragenheim,
CEO of Elyakim Management Systems (1992) Ltd

А что вы думаете?

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.