Здравствуйте, коллеги.

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

Как человек весьма углубившийся в Лин и планирование, однажды я встал перед вопросом: «Как определить реальный оптимальный размер партии для деталей производственного плана? Какие данные нужны помимо самого плана производства?»

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

Имея эти параметры в базе данных и на карте потока создания ценности возможно:
- просчитать оптимальный размер партии для детале-сборочной единицы в условиях заданного спроса (плана производства)
- проработать различные сценарии реального производства запланированной продукции, ответить на вопросы «А что если…?», т.е. смоделировать «отказы» производственной системы (FMEA)
- наладить работу электронного «выравнивателя потока», определяющего размер и очередность выпуска партий полуфабрикатов для каждого рабочего места

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

Уважаемые коллеги, прошу проверить мою идею на прочность. Спасибо за Вашу критику!

Нужно учитывать лимитирующие факторы: оборудование, оснастка, операторы,наладчики и пр.

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

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

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

Специализированный механизм ответов на вопросы "а что если?.." на практике не востребован.

В вашей постановке задачи «Как определить реальный оптимальный размер партии для деталей производственного плана? Какие данные нужны помимо самого плана производства?» ключевое слово - "оптимальный" (а "реальный" совершенно излишнее").
Определите, какие критерии заложены в это понятие, после чего проблем с парадигмой планирования возникнуть не должно.

ПС Слова "оптимальный" и "работать" без однозначной расшифровки того, что в них заложено - слова-паразиты. Желательно их всячески избегать.

Речь идет о передаточной партии или партии обработки?

Что означает слово "оптимальный"? Что именно вы оптимизируете (затраты на единицу продукции, время производственного цикла)?

Игорь Киселев пишет: Этих данных я не видел ни в одной системе оперативного планирования.

Александр Карбаинов прав: в современных системах оперативного планирования производства одной из задач является задача формирования размеров партий запуска ДСЕ в обработку.
Вообще говоря, эту задачу обычно решают одновременно с задачей пооперационного планирования (при этом партии ДСЕ могут как дробиться, так и объединяться).

Вальчук Виктор Васильевич пишет: Речь идет о передаточной партии или партии обработки?

Скорее всего, Игорь имеет ввиду именно партию обработки (партию запуска в обработку), которая, как правило, кратна передаточной партии.

Александр Карбаинов пишет: В системы оперативного планирования эти данные часто закладываются по-умолчанию.

Т.е. жестко.

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

Я использую подход SMED - размер партии должен быть минимальным (в идеале = 1) при условии использования всего фонда времени оборудования. Т.е. оборудование может или переналаживаться или производить. Чем меньше партиии (при многих наименованиях), тем больше нужно переналадок. Снижать объемы НЗП можно до того предела, пока успеваем переналаживать оборудование и выполнять программу. Это и есть "оптимальный размер партии".

Александр Карбаинов пишет: Требований к снижению запасов, к максимально быстрому удовлетворению потребности клиента, обеспечению высокой гибкости и возможности переналадок в этой модели не заложено.

Угу

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

Специализированный механизм ответов на вопросы "а что если?.." на практике не востребован.

Не факт.

Александр Карбаинов пишет: В вашей постановке задачи «Как определить реальный оптимальный размер партии для деталей производственного плана? Какие данные нужны помимо самого плана производства?» ключевое слово - "оптимальный" (а "реальный" совершенно излишнее").
Определите, какие критерии заложены в это понятие, после чего проблем с парадигмой планирования возникнуть не должно.

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

Александр Карбаинов пишет: ПС Слова "оптимальный" и "работать" без однозначной расшифровки того, что в них заложено - слова-паразиты. Желательно их всячески избегать.

Согласен. Термины определяют.

Пока убегаю. По мере свободного времени буду отвечать дальше.

1. Lean планирования - нет. Есть - просто планирование. А далее - критерии этого планирования.
2. Перечисленные выше параметры (кроме "технологически оптимального" - что это?) - есть во многих APS/MES системах хорошего уровня, а учет брака мин.и кратная партия - даже в MRP, Кроме того, есть ряд софтов, которые именно тем и занимаются, что считают оптимальные и пр. размеры партий. Но нуно ли все это, если мы хотим работать (планировать) Lean?.
3. Что есть задача: "оптимальная партия запуска" или оптимальный план?
Мне ближе 2е. "Оптимальный" в какой части? Мне ближе: с точки зрения выполнения заказов клиентов "точно вовремя", "точно в количестве", с минимумом прямых издержек по всей производственной цепочке (минимум НзП получится сам собой). Опять же, для какого производства? Если - чисто позаказное - запускаемая партия = партии под заказ или - мин.технологическая партия (а лучше - все равно - "под заказ"). Если квази-серийное производство - необходимо считать экономически-выгодную. Здесь можно использовать стандартную формулу (минимум функции: стоимость переналадки (запуска) + стоимость запасов). Если партия рассчитывается для "узкого места" - (а если позаказное производство и все заказы разные - не только) - необходимо учитывать такой параметр, как стоимость часа производства в разрезе стоимости готовой продукции.

Для сложного производства все эти динамические расчеты, по моему опыту - практически нерешаемая задача. Т.е. решить можно, но рассчитав один раз, для стабильных условий. И, что важнее - не нужная и вредная. Т.к. объявляя на каком-либо переделе партию, мы вынуждены будет "собирать" под нее ДСЕ из разных, разнесенных по времени головных заказов, т.е. устанавливать некое "окно синхронизации". В результате получим локальную оптимизацию при увеличении времени выполнения заказа, следовательно, цикла, следовательно - НзП. А если продукция - многоуровневая и таких переделов - много?...

Может быть поступить по-другому? Планируем жестко под заказ (головное изделие), по всему "дереву" изделия, от сборки до заготовки , партии собираем в момент запуска. Используем консолидацию по времени (к примеру, все потребности, попадающие в 5 дней). Где-то потеряем в переналадках, но выиграе в цикле, и, в целом, в "скорости отклика" системы.

Вальчук Виктор Васильевич пишет: Речь идет о передаточной партии или партии обработки?

Партия обработки - один из параметров
Речь о партии, передаваемой по потоку создания ценности

Богданов Андрей пишет:

Игорь Киселев пишет: Этих данных я не видел ни в одной системе оперативного планирования.

Александр Карбаинов прав: в современных системах оперативного планирования производства одной из задач является задача формирования размеров партий запуска ДСЕ в обработку.
Вообще говоря, эту задачу обычно решают одновременно с задачей пооперационного планирования (при этом партии ДСЕ могут как дробиться, так и объединяться).

На основании каких данных и алгоритмов, например?

Сергей Питеркин пишет: 1. Lean планирования - нет. Есть - просто планирование. А далее - критерии этого планирования.

Согласен.

Сергей Питеркин пишет: 2. Перечисленные выше параметры (кроме "технологически оптимального" - что это?) - есть во многих APS/MES системах хорошего уровня, а учет брака мин.и кратная партия - даже в MRP, Кроме того, есть ряд софтов, которые именно тем и занимаются, что считают оптимальные и пр. размеры партий. Но нуно ли все это, если мы хотим работать (планировать) Lean?.

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

Сергей Питеркин пишет: 3. Что есть задача: "оптимальная партия запуска" или оптимальный план?
Мне ближе 2е. "Оптимальный" в какой части? Мне ближе: с точки зрения выполнения заказов клиентов "точно вовремя", "точно в количестве", с минимумом прямых издержек по всей производственной цепочке (минимум НзП получится сам собой).

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

Сергей Питеркин пишет: Опять же, для какого производства? Если - чисто позаказное - запускаемая партия = партии под заказ или - мин.технологическая партия (а лучше - все равно - "под заказ"). Если квази-серийное производство - необходимо считать экономически-выгодную. Здесь можно использовать стандартную формулу (минимум функции: стоимость переналадки (запуска) + стоимость запасов). Если партия рассчитывается для "узкого места" - (а если позаказное производство и все заказы разные - не только) - необходимо учитывать такой параметр, как стоимость часа производства в разрезе стоимости готовой продукции.

Ой, тогда затуманят всё экономисты своими себестоимостями!

Сергей Питеркин пишет: Для сложного производства все эти динамические расчеты, по моему опыту - практически нерешаемая задача. Т.е. решить можно, но рассчитав один раз, для стабильных условий. И, что важнее - не нужная и вредная. Т.к. объявляя на каком-либо переделе партию, мы вынуждены будет "собирать" под нее ДСЕ из разных, разнесенных по времени головных заказов, т.е. устанавливать некое "окно синхронизации". В результате получим локальную оптимизацию при увеличении времени выполнения заказа, следовательно, цикла, следовательно - НзП. А если продукция - многоуровневая и таких переделов - много?...

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

Сергей Питеркин пишет: Может быть поступить по-другому? Планируем жестко под заказ (головное изделие), по всему "дереву" изделия, от сборки до заготовки , партии собираем в момент запуска. Используем консолидацию по времени (к примеру, все потребности, попадающие в 5 дней). Где-то потеряем в переналадках, но выиграем в цикле, и, в целом, в "скорости отклика" системы.

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