Александр Запорожцев пишет:

Андрей Николаевич пишет: 7. Начинайте повышать точность планирования. Если у вас ежедневное переходите к почасовому, а потом к поминутному.
8. Далее надо строить тянущую систему. .

Мне кажется, что пункт 8 противоречит пункту 7. Зачем повышать точность планирования вплоть до минуты, если Вы откажетесь от планирования и будете использовать тянущую систему?

В тянущей системе сигнал тоже проходит за некий промежуток времени.

PS: Один из японцев мне сказал "Игорь, перестань думать часами и минутами, начинай думать секундами"

Александр Запорожцев пишет: Мне кажется, что пункт 8 противоречит пункту 7. Зачем повышать точность планирования вплоть до минуты, если Вы откажетесь от планирования и будете использовать тянущую систему?

План в тянущей системе никуда не девается. Он так же составляется только ещё более детально, только запуск происходит не по плану, а по канбанам. План нужен для оценки возможности и для диспетчирования исполнения заказов (отстаем или опережаем).

Андрей Николаевич пишет: Это очень серьёзная проблема, если вы не знаете сроков выполнения операций, то вы спланировать ничего не сможете. Следовательно, вы этот хаос не преодолеете.

Андрей Николаевич, стоп!
Я не указал в своем сообщении, что не знаю сроков выполнения операций!
Я указал, что имею достаточную вариабельность процессов, которые зависят как от параметров процесса, особенностях материала, так и от состояния и опытности оператора, выполняющего процесс... Поэтому рассматривая план/фактовый анализ в большом отчетном периоде (месяц) я имею вариабельность на уровне +/- 5%, а при суточном рассмотрении или при оценке план/факт по конкретному заказу - уже вариабельность может доходить до 30-50%!

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

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

Ну и конечно никто не отменял:
1. Борьбы с потерями - т.е. задача повышения эффективности и скорости выполнения операции посредством различного инструментария...
2. И далее при повышении эффективности и фиксации роста ФАКТа по отношению к ПЛАНу - пересмотр норм-часов, взятие за основу средний показатель ФАКТа
и т.д и т.п

И вся загвоздка в том, что при отсутствии такого ПО - я ограничен в эффективности управления...

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

Игорь Рыжкин пишет: PS: Один из японцев мне сказал "Игорь, перестань думать часами и минутами, начинай думать секундами"

1. Как Вы его поняли?
2. Что этой фразой он хотел сказать?
3. Изменилось ли Ваше понимание после того, как Вы нашли ответ на второй вопрос?

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

1. У Медоуз есть замечательная фраза - управленцы интуитивно чувствуют каким рычагом нужно пользоваться, чтобы управлять ситуацией, однако этот рычаг они толкают не в ту сторону. Это называется контринтуитивным поведением системы.
2. Мне нравиться следующее понимание ограничение у Голдрата - если вы знаете где ограничение, то вам не нужно следить за всей системой (составлять детальное расписание для всех станков) вам нужно управлять только этим ограничением.
Это не замечание и не совет - это мысли вслух!

Евгений пишет: Андрей Николаевич, стоп!
Я не указал в своем сообщении, что не знаю сроков выполнения операций!

Прошу прощения опечатка, естественно продолжительность исполнения операций.

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

Вот с этим я и предлагаю побороться.

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

Программе нужны нормативы времени. Их необходимо знать! Не какие-то виртуальные нормы, а реальность. Ровно это я и отразил в плане выше.

Евгений пишет: ...И вся загвоздка в том, что при отсутствии такого ПО - я ограничен в эффективности управления...

На кривых данных вы не сможете планировать ни с ПО, ни без него. Кстати, форма оплаты труда у вас на предприятии какая? Привязка к выработке есть?

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

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

Александр Запорожцев пишет: 1. Как Вы его поняли?
2. Что этой фразой он хотел сказать?
3. Изменилось ли Ваше понимание после того, как Вы нашли ответ на второй вопрос?

Если кратко. Это был 2014 год. Конвейер по сборке твэл. Конвейер изготавливает 360 твэл/смена. А надо делать 432 твэла, т.е. приходилось работать 1,5 смены. Когда я об этом сказал японцу, то он мне в ответ и выдал этот перл. Больше ничего. В результате я стал считать, что конвейер изготавливает 1 твэл за 70 секунд, а чтобы избавиться от дополнительной 0,5 смены нужно, чтобы 1 твэл изготавливался за 60 секунд. Дальше я проанализировал работу каждого оборудования, входящего в состав конвейера. В результате я выяснил, что только 2 единицы оборудования не справляются с такой скоростью (Ттакта). Дальше расшил эти места. И все. В дальнейшем мы замахнулись на такт в 48 секунд, т.к. потребителю стало нужно еще топливо для станций. Тоже самое произошло и с последующим конвейером по сборке твс.
И сейчас, каждый раз приходя на новое предприятие, я ребятам всегда говорю эти слова. Тогда многое становится ясным

Андрей Николаевич пишет:

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

Вот с этим я и предлагаю побороться.

Это называется борьба с "ветряными" мельницами - потратить кучу усилий и времени вспомогательного персонала для детального оцифровки процесса, чтобы по каждому конкретному заказу я имел вариабельность в пределах +/- 10% или 1%? Или может быть цель поставить 0,1%?
А как быть с работником? Один делает с одной выработкой, а другой немного медлительный - тоже учитывать и свойства работника?
А еще порой время на устранение брака?
И на это нормативное время не учитывается - ибо это простой!

Ну допустим достигли мы в месяц вариабельность ПЛАН/ФАКТ = 0.9999..
А по конкретному заказу - вариабельность была 5% - т.е. допускаю, что сменный план в дневную смену могли недовыполнить на 5-10%, а в ночную смену - разогнались на 10! И в сутках уже 100% эффективности...

И получается, что созданный детальный суточный план на первой операции имеет вариабельность в 5%, а на втором этапе - уже может быть и 20%, а порой и вообще без плана стали работать, ибо по плану заказ должен быть на участке, а он еще в работе на предыдущем...

Поэтому я склонен не к детальному планированию - а к указанию приоритетности выполнения доступных заказов в конкретный момент времени на конкретном участке (т.е. из всех доступных заказов, которые сейчас в очереди - система должна предложить Работнику тот, который имеет минимальное остаточное время до срока сдачи с максимум продолжительности рабочих операций.

Андрей Николаевич пишет: Кстати, форма оплаты труда у вас на предприятии какая? Привязка к выработке есть?

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

Александр Запорожцев пишет: ... сомневаюсь, что запуск ради повышения уровня НЗП это разумно. ... еще один вопрос - должны ли быть синхронизированы запуски S-DBR или MTA? ...

Александр, я не призываю чего-либо запускать ради повышения уровня НЗП. Ситуация такая: у вас есть несколько сформированных для запуска заданий, часть "по заказу" (DBR), часть " по уровню" (MTA). Вопрос: их запускать? Все или не все? Если не все, то какие сначала, а какие потом? Важнейшим элементом моей модели является обеспечение стабильности потоков. Это означает, что уровень НЗП в потоке должен находиться в некотором диапазоне оптимальных значений. Если по факту он ниже, то можно что-то запустить. Если выше, то ничего запускать не следует. Если запускать можно, то что? Предлагаемый мной ответ - в порядке приоритетов заданий на текущий момент. Точно так же и в процессе движения по потоку. Если приоритет опустился, то притормаживаем, если поднялся - ускоряем. Это не FIFO, а настоящее вытягивание. (Надеюсь, Вы понимаете, что FIFO - это не вытягивание, а выталкивание.)

Игорь Рыжкин пишет:

ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ] [ Нажмите, чтобы скрыть ]

Если кратко. Это был 2014 год. Конвейер по сборке твэл. Конвейер изготавливает 360 твэл/смена. А надо делать 432 твэла, т.е. приходилось работать 1,5 смены. Когда я об этом сказал японцу, то он мне в ответ и выдал этот перл. Больше ничего. В результате я стал считать, что конвейер изготавливает 1 твэл за 70 секунд, а чтобы избавиться от дополнительной 0,5 смены нужно, чтобы 1 твэл изготавливался за 60 секунд. Дальше я проанализировал работу каждого оборудования, входящего в состав конвейера. В результате я выяснил, что только 2 единицы оборудования не справляются с такой скоростью (Ттакта). Дальше расшил эти места. И все. В дальнейшем мы замахнулись на такт в 48 секунд, т.к. потребителю стало нужно еще топливо для станций. Тоже самое произошло и с последующим конвейером по сборке твс.
И сейчас, каждый раз приходя на новое предприятие, я ребятам всегда говорю эти слова. Тогда многое становится ясным

Игорь, всё правильно, но если бы Вы к 2014 году знали ТОС, то и без японца поступили бы таким же образом - 1) нашли бы ограничение, 2) нашли бы, как его максимально использовать. Про остальные шаги умалчиваю, так как Вы о них не говорите. Тут дело не в том, в каком масштабе Вы рассматриваете процесс, а на ЧТО смотрите.
Конечно, это при условии, что конвейер - ограничение всей системы, то есть, твэлы нигде не накапливаются (не могу знать всё )
То, что Вы описали - естественный ход действий того, кто следует ТОС.