Сергей Жаринов пишет: Михаил, я предложил Вам прочитать на эту тему одну из моих статей.

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

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

Богданов Андрей пишет: Я не собираюсь критиковать ТОС.

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

Должен подтвердить: в таких производствах, где среднее значение OEE для всей станочной системы как правило меньше уровня 0,3, хотя отдельные станки то простаивают, то не справляются с очередью заданий, искать этот самый РОП не имеет никакого смысла.

То есть сначала придумали (вслед за Фроловым), что ТОС требует "определения РОП для единичных производств", а потом заявляете - "не имеет никакого смысла". Это называется "ломиться в открытую дверь"

Но мне остается непонятным, Виктор Васильевич, как график сдачи заказов клиентам, о котором Вы говорите, сможет решить задачу оперативного управления непосредственно в производственном подразделении? Если на этом уровне нет управления, то о выполнимоти указанного графика даже и мечтать не приходится.

Разъясните мне этот вопрос, пожалуйста.

Вот теперь вопрос поставлен конструктивно. Попробую ответить коротко (хотя на самом деле требуется целая статья). Решение для этого случая называется S-DBR, упрощеннный "барабан-буфер-канат". "Барабан" в этом случае не ресурс с ограниченной мощностью РОМ (CCR) (вы совершенно правы - он может мигрировать в условиях такого производства), а назначенный ресурс. Чаще всего в качестве ограничения выбирают требования рынка (то есть график сдачи). Таким образом график сдачи продукции клиенту выступает "барабаном" - тем, что задает темп работы всей системе.
Следующий элемент - "буфер". Это временной промежуток, за который деталь, запущенная в производство, превратится в готовое изделие. Обычно это время называют производственным циклом. Но обычно время производственного цикла для таких производств неоправданно завышено, поскольку неоправданно велико НЗП. А велико оно потому, что для загрузки оборудования мы стараемся запустить детали в производство (в обработку) как можно раньше. Эта ситуация еще более усугубляется тем, что у людей сдельная оплата труда и они естественно требуют запуска в обработку (ну не простаивать же им!). Иногда эта ситуация (высокий НЗП и длинное время ПЦ) усугубляется необходимостью (а вернее неоправданной необходимостью) поддерживать партии ("я должен час переналаживаться, чтобы 20 минут работать?"). Но еще чаще она создается на этапе переговоров с клиентами: "мы не можем делать партии по 3 штуки, мы можем делать не менее 100!"

Но ведь у нас на самом деле нужно обеспечить стабильный поток денег, а потому - стабильное выполнение сроков заказов клиентов, а не экономить на переналадках, на загрузке оборудования и рабочих. Наш приоритет №1 - график сдачи заказов. Поэтому обычное время ПЦ может быть значительно сокращено при выборе времени "буфера".

Последний элемент - "канат". Это просто механизм запуска в производство детали (заказа), когда для нее наступает время "время сдачи по графику минус время буфера". И ни в коем случае не раньше. Даже если оператор первого станка простаивает! (Не забудьте сказать "до свидания" сдельной оплате труда и нормативам)

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

В результате НЗП на производстве значительно снижается, сокращается время ПЦ и график сдачи готовых заказов выполняется намного надежнее, чем прежде. И детальное расписание для каждого станка не требуется. Требуется просто выполнение заказов в соответствии с приоритетами.

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

А что же настоящие ограничения (РОМ), которые есть на производстве и "мигрируют"? Чаще всего, количество таких РОМ при S-DBR значительно снижается (просто раньше мы создавали их искусственно). Ну а к тем, что все-же остаются -применяем 5 фокусирующих шагов, SMED, 5S и т.д. (в том числе может быть и порядок обработки немного поменять)

Сергей Жаринов пишет: "Составлять расписание для 4-х станков математикой - дебилизм." Это Вы о чём?

Вы же не подумали, что слово "дебилизм" хоть как-то касается вас? С моей стороны это был бы полный дебилизм. Вы умный и образованный человек, у вас хороший слог. Мне не все нравится, что вы говорите и наоборот - но ведь иначе не бывает
Сказанное не зря идет первым пунктом, это очень важно. Я выгрызаю из себя периодически появляющееся желание считать людей идиотами, а из-под вашей статьи эти ножки торчат, как раздавленный таракан из-под каблука. Я немного научился сомневаться в себе и оказалось, что за каждой производственной глупостью стоит узел неочевидных причин и следствий, который нельзя разрубить. Сделать можно все, но лишь с учетом множества деталей и гораздо более извилистым путем, чем в бизнес-романах
В первом пункте я имел в виду несоответствие между реальностью и моделью реальности, которую вы нарисовали и критикуете. Люди всегда выбирают самый простой метод и для 4-х станков найдут решение просто на пальцах. А для 100 станков при 100 заказах ваш пример не годится.

Я не буду открывать новую тему т.к. не смогу ее "обслужить". Планирование АЭС в самом деле намного проще, чем в многономенклатурном позаказном производстве, спорить с вами в этих вопросах мне не по карману

Алексей Васильев пишет: А где столь же последовательное и основательное изложение взглядов его оппонентов?

Кто тащит - тот и подставляется, разве не так?
Или вы сами, проводя свои изменения, окружены всеобщей любовью и уважением? все ваши оппоненты точны мыслями и лицом приятны?

Михаил Шустер пишет: ... для 100 станков при 100 заказах ваш пример не годится.

С чего Вы это взяли? Попытайтесь понять общий алгоритм и Вам станет ясно, что S-DBR это абсолютно масштабируемая вещь. Или ещё раз перечитайте про подход WIP Cap (только не у Фролова, а первоисточник). Это в точности то же самое. Или Вы полагаете, что если, например, Хэллет для иллюстрации этого подхода поместил картинку из четырёх процессов, то для пяти (а тем более для 100) процессов система уже не работает?

Вальчук Виктор Васильевич пишет:

Богданов Андрей пишет: Я не собираюсь критиковать ТОС.

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

Должен подтвердить: в таких производствах, где среднее значение OEE для всей станочной системы как правило меньше уровня 0,3, хотя отдельные станки то простаивают, то не справляются с очередью заданий, искать этот самый РОП не имеет никакого смысла.

То есть сначала придумали (вслед за Фроловым), что ТОС требует "определения РОП для единичных производств", а потом заявляете - "не имеет никакого смысла". Это называется "ломиться в открытую дверь"

Не знаю, Виктор Васильевич, что там придумал Фролов, но то, что в упомянутых Вами "5 фокусирующих шагах" первый шаг касается именно определения того самого цехового РОП, - это в ТОС утверждается. Разве не так?

Вальчук Виктор Васильевич пишет: Вот теперь вопрос поставлен конструктивно. Попробую ответить коротко...
...
Последний элемент - "канат". Это просто механизм запуска в производство детали (заказа), когда для нее наступает время "время сдачи по графику минус время буфера". И ни в коем случае не раньше. Даже если оператор первого станка простаивает! (Не забудьте сказать "до свидания" сдельной оплате труда и нормативам)

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

До этого места мне было все более или менее понятно.
А вот далше...

Вальчук Виктор Васильевич пишет: ... В результате НЗП на производстве значительно снижается, сокращается время ПЦ и график сдачи готовых заказов выполняется намного надежнее, чем прежде. И детальное расписание для каждого станка не требуется. Требуется просто выполнение заказов в соответствии с приоритетами.

Следует ли Вас понимать так, что знание производственного цикла (т.е. так называемые "опережения запуска партий ДСЕ в обработку") и приоритетов исполняемых заказов - это достаточная информация для того, чтобы в цехе все само-собой "оптимизировалось"?!

Чтобы проверить это утверждение, предположим, что в цеха, имеющим 200 станков, обрабатывается хотя бы 30 заказов (комплектов ДСЕ, каждый из которых имеет от 50 до 100 деталей, средняя глубина техпроцесса для каждой ДСЕ 10 операций, в ТП предусмотрены технологические сборы), размер партий для этих заказов варьируются от 10 до 150 штук. В цехе происходит так называемый "отрыв партий" (дробление одной партии на несколько частей) и используются кроме основных ТП их альтернативные аналоги. Это я Вам описал типичную картину, встречающуюся на мелкосерийных и единичных производствах.
А теперь давайте предположим, что все изготавливаемые заказы (а это десятки тысяч технологических операций в месяц) имеют одинаковый приоритет, например, срок их сдачи по плану составляет одно и то же число - конец месяца.

Ну и... как же все это "самоорганизуется"? - скажите мне, пожалуйста.

А что же настоящие ограничения (РОМ), которые есть на производстве и "мигрируют"? Чаще всего, количество таких РОМ при S-DBR значительно снижается (просто раньше мы создавали их искусственно). Ну а к тем, что все-же остаются -применяем 5 фокусирующих шагов, SMED, 5S и т.д. (в том числе может быть и порядок обработки немного поменять)

Знаете, сколько в цеху участков, например N, на которых происходит обработка, столько практически и ограничений буквально для каждого заказа, Скорее их число для каждого заказа можно оценить величиной N/3, т.е. в текущий момент времени приблизительно треть участков так или иначе "притормаживает" обработку деталей, входящих в конкретный заказ. Причем число этих ограничений N/3 следует умножить на число одновременно обрабатываемых заказов (в приведенном мною примере из 30), вот тогда и получим их реальное количество в единицу времени, - вот такое распределение, для примера, указанного выше, если N=10, то число одновременно "мигрирующих" ограничений в рассмотренном цехе равно 100.
(Вы что действительно верите, что "мы раньше создавали эти ограничения искусственно"?)

Ну и, Виктор Васильевич, как здесь Вы предлагаете проводить "5 фокусирующих шагов"?

А чтобы конкретно решать задачи SMED и 5S надо иметь хотя бы приблизительный пооперационный план работ на каждом рабочем месте (т.е. предварительно провести "локальную оптимизацию"), иначе это будут только декларации о намерениях.

Богданов Андрей пишет:
Не знаю, Виктор Васильевич, что там придумал Фролов, но то, что в упомянутых Вами "5 фокусирующих шагах" первый шаг касается именно определения того самого цехового РОП, - это в ТОС утверждается. Разве не так?

Не так. Первый шаг в "5 фокусирующих шагах" такой: Определить (назначить) ограничение системы. Замечу, что ограничивающим фактором системы вполне может оказаться и не РОМ, а правило: "назначать отгрузку всех заказов, принятых в предыдущий месяц, на конец месяца". Или правило: "Запускать в обработку заказы сразу, как только они поступят", или: "Не принимать заказы, если количество изделий в заказе менее 200".

Следует ли Вас понимать так, что знание производственного цикла (т.е. так называемые "опережения запуска партий ДСЕ в обработку") и приоритетов исполняемых заказов - это достаточная информация для того, чтобы в цехе все само-собой "оптимизировалось"?!

Чтобы проверить это утверждение, предположим, что в цеха, имеющим 200 станков, обрабатывается хотя бы 30 заказов (комплектов ДСЕ, каждый из которых имеет от 50 до 100 деталей, средняя глубина техпроцесса для каждой ДСЕ 10 операций, в ТП предусмотрены технологические сборы), размер партий для этих заказов варьируются от 10 до 150 штук. В цехе происходит так называемый "отрыв партий" (дробление одной партии на несколько частей) и используются кроме основных ТП их альтернативные аналоги. Это я Вам описал типичную картину, встречающуюся на мелкосерийных и единичных производствах.
А теперь давайте предположим, что все изготавливаемые заказы (а это десятки тысяч технологических операций в месяц) имеют одинаковый приоритет, например, срок их сдачи по плану составляет одно и то же число - конец месяца.
Ну и... как же все это "самоорганизуется"? - скажите мне, пожалуйста.

Андрей, я что-то не пойму - Вы хотите понять, как работает S-DBR для единичных производств, или хотите понять - как сделать так, чтобы не работало?

Объясню, если вы не поняли: Одновременно в цеху столько заказов, что они все гарантировано должны быть выполнены к предусмотренному для каждого заказа времени. И их меньше, чем у вас было до начала внедрения метода S-DBR. А меньше потому, что время буфера меньше времени производственного цикла, который у вас был до того. И мы выполняем правило "каната".

И если ваши менеджеры при переговорах назначают время сдачи ВСЕХ заказов на конец месяца, вы должны поговорить с ними, и сделать так, чтобы этого не было. Или провести переговоры с некоторыми из клиентов: готовы ли они получить свой заказ не в конце месяца, а раньше Разве не понятно, что установив размер буфера и правило "каната", вы тем самым ограничили количество заказов, которые могут быть одновременно в цеху? Так составьте соответствующий график отгрузки готовых заказов!

Знаете, сколько в цеху участков, например N, на которых происходит обработка, столько практически и ограничений буквально для каждого заказа, Скорее их число для каждого заказа можно оценить величиной N/3, т.е. в текущий момент времени приблизительно треть участков так или иначе "притормаживает" обработку деталей, входящих в конкретный заказ. Причем число этих ограничений N/3 следует умножить на число одновременно обрабатываемых заказов (в приведенном мною примере из 30), вот тогда и получим их реальное количество в единицу времени, - вот такое распределение, для примера, указанного выше, если N=10, то число одновременно "мигрирующих" ограничений в рассмотренном цехе равно 100.
(Вы что действительно верите, что "мы раньше создавали эти ограничения искусственно"?)
Ну и, Виктор Васильевич, как здесь Вы предлагаете проводить "5 фокусирующих шагов"?
А чтобы конкретно решать задачи SMED и 5S надо иметь хотя бы приблизительный пооперационный план работ на каждом рабочем месте (т.е. предварительно провести "локальную оптимизацию"), иначе это будут только декларации о намерениях.

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

Вальчук Виктор Васильевич пишет: ... Приведенный вами пример нереален. Вы же не пробовали. Сократите в два раза количество НЗП в цеху и вы увидите - большинство ваших РОМ просто испарятся.

Ну, конечно, таких предприятий, Андрей, что Вы привели в своем примере не бывает.
У нас в России бывают только маленькие "свечные заводики" на 5-10 станков в цеху с десятком несложных заказов.

Следуя этому совету, "сократите в два раза количество НЗП" (не используя при этом пресловутой "локальной оптимизации") и Вы увидите что...
и производительность станочной системы тоже снизится, скорее всего процентов на 25-30.

Михаил Шустер пишет:

Сергей Жаринов пишет: "Составлять расписание для 4-х станков математикой - дебилизм." Это Вы о чём?

... Люди всегда выбирают самый простой метод и для 4-х станков найдут решение просто на пальцах. А для 100 станков при 100 заказах ваш пример не годится.

Михаил, Вы же видите, человеку неймется.

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

Впредь по обыкновению не буду реагировать на глупые выпады в свой адрес, напомню лишь их автору мой давний ему совет: новопассит: health.mail.ru/drug/novo_passit/ .

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

Это точно. А, к примеру, Robert Stein выделяет ещё один тип ограничений: Losistical constraint - occurs when the planning and control system prevents the company from attaining its goal.

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