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

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

Это если говорить про физические (точнее, ресурсные) ограничения. А что касается ограничений организационных (political constraints, которых обычно море в наших системах), то там "узкие места" вообще некуда пришить.

Сергей Жаринов пишет: Роман, если интересует моё мнение, то я вообще не противопоставляю ТОС и канбан. Более того, считаю, что в определённых ситуациях канбан может быть неплохим средством subordination. Сам достаточно часто использую этот механизм.

Спасибо за поддержку. Точно так же считаю что каждому инструменту - свое место.

Сергей Жаринов пишет: (1) Разработчики TPS интуитивно выстроили замечательную логистическую систему. Но - применительно к конкретному достаточно специфическому типу производства (сборка автомобилей, в классификации ТОС - "завод типа I").

Точно не помню, но вроде Голдратт писал что то подобное:

- Я встретился с доктором Оно и спросил его: "Почему работает Ваша система?"
- Он ответил: Не знаю. Она противоречит логике, но она работает!

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

Вальчук Виктор Васильевич пишет: Есть большая разница между тем, когда применяют разные инструменты (ТОС, ТРИЗ, TQM и Лин), понимая суть, ограничения и преимущества каждого из подходов и их инструментов, и когда зная только один-два подхода, остальные необоснованно и "глубокомысленно" уничижают и отвергают. И все бы ничего, но ведь это делается публично... А потому такое поведение может кого-то завести в тупик, отодвинуть время получения финансового результата.

Абсолютно согласен. К сожалению, защищая "отодвинутый" инструмент, мы иногда сами рисуем черно-белую картину. Собственно я про Ваш комментарий на tocpeople про несовместимость ТОС и канбан . Он несколько напряг наших клиентов (они Вас знают как одного из метров производственного консалтинга).

Однако надо поблагодарить Вас за него. В попытке Вам доказать, что ТОС+канбан иногда лучше всех других решений, высветились яркие несоответствия ТОС-у и тут пришло более глубокое понимание сути системы. Я думаю ее создали интуитивно, опираясь на Lean и ТОС.

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

Не знаю встречался ли кто-нибудь с подобным. Может даже часто? По крайней мере я раньше такого опыта не имел.

Роман Пантелеев пишет:
Точно не помню, но вроде Голдратт писал что то подобное:

- Я встретился с доктором Оно и спросил его: "Почему работает Ваша система?"
- Он ответил: Не знаю. Она противоречит логике, но она работает!

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

Надо сначала объяснить, почему с точки зрения Голдратта система TPS не должна была работать.
Отсюда и вопрос: Как это так? Почему она таки работает? Ведь по моей логики (ТОС) она не должна работать.

Роман Пантелеев пишет: К сожалению, защищая "отодвинутый" инструмент, мы иногда сами рисуем черно-белую картину. Собственно я про Ваш комментарий на tocpeople про несовместимость ТОС и канбан . Он несколько напряг наших клиентов (они Вас знают как одного из метров производственного консалтинга).

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

Роман Пантелеев пишет: ... сборка и ограничение - это один рабочий центр ... .

Если внимательно посмотреть на логистику TPS, то станет понятно, что она выстроена идеально с точки зрения ТОС. Последний этап перед отгрузкой клиентам - сборочное производство. Фактически это один рабочий центр (хотя физически - целый завод), на котором последовательно выполняются три основных процесса: изготовление кузова, окраска и конечная сборка. В терминологии ТОС это производство изначально выбрано в качестве внутреннего физического ограничение всей системы (ПЕРВЫЙ ШАГ Five Focusing Steps, FFS). Оно задаёт ритм работы всем остальным процессам, иными словами, выполняет функцию "барабана".

Заметьте, что внутри сборочного производства НЕТ НИКАКИХ КАНБАНОВ, а используя сложные расчёты на каждый рабочий день (за два дня до запуска) составляется чёткий график прохождения корпусов по всем процессам. То есть реализован ВТОРОЙ ШАГ FFS.

Дальше, когда определено внутреннее ограничение и решено, как оно должно эксплуатироваться, то нужен ТРЕТИЙ ШАГ FFS (самый важный и сложный), - подчинение остальных процессов графику работы ограничения. Тут, казалось бы, самое место для DBR; прокинуть верёвки и позаказно делать каждую деталь. Если бы время производственного цикла + время доставки деталей и комплектующих (как покупных, так и собственного изготовления) составляло меньше двух дней, то такое решение могло бы работать. Однако, думаю, что даже в условиях Тойоты это весьма проблематично. Хотя бы потому что многие обеспечивающие производства часто расположены территориально далеко от сборочных заводов (часто в другом городе, регионе и даже стране).

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

Наконец, ЧЕТВЁРТЫЙ ШАГ FFS. В арифметике ТОС - увеличить ресурсы ограничения (что может привести к тому, что внутреннее ограничение перейдёт в другое место, например, в какое-то производство по изготовлению деталей). В высшей математике ТОС - постараться удержать ограничение на старом месте, ведь мы им уже умеем хорошо управлять. На Тойоте и тут интуитивно применили стратегический подход ТОС. Там на месяц вперёд составляют объёмные планы поставки всех деталей и комплектующих и предлагают всем участникам процесса гарантировать бесперебойную работу сборочного производства. Занимайтесь кайдзенами, устранением потерь, быстрыми переналадками, чем хотите (не получится - дополнительных людей набирайте), но установленные объёмы и ритм поставок должны обеспечить. Всё!

Сергей Жаринов пишет: внутри сборочного производства НЕТ НИКАКИХ КАНБАНОВ, а используя сложные расчёты на каждый рабочий день (за два дня до запуска) составляется чёткий график прохождения корпусов по всем процессам.
На Тойоте на месяц вперёд составляют объёмные планы поставки всех деталей и комплектующих и предлагают всем участникам процесса гарантировать бесперебойную работу сборочного производства.

Это возврат к централизованному планированию на новом уровне?

Александр пишет: Это возврат к централизованному планированию на новом уровне?

Почему возврат? Насколько я понимаю, так на Тойоте было по крайней мере последние 40-50 лет. Для сборки составлялись ежедневные графики; использовался "метод преследования цели" (goal-chasing method), описанный Монденом ещё 30 лет назад. С тех пор, вероятно, конкретные алгоритмы усовершенствовали, но идея осталась той же - выравнивание сборочного производства и, соответственно, потребностей в вытягиваемых по канбану деталях, узлах и комплектующих. Всё в полном соответствии с идеологией ТОС. Сборка выбрана в качестве внутреннего ограничения, и только для неё формируется подробный график. Как лучше всего эксплуатировать любой рабочий центр? Понятно как - нагружая его более-менее равномерно. Именно это и сделано.

Зачем формируются объёмные планы? На самом деле не на один, а на три месяца вперёд (на ближайший месяц - более точный). Чтобы поставщики деталей, узлов и комплектующих заранее представляли себе - проходят такие объёмы через их внутренние ограничения или нет. Если да, то всё хорошо. В идеале для каждого поставщика активное ограничение всегда должно быть внешним (потребности сборочного производства). Если не проходит, есть пара месяцев чтобы либо "расшить" это ограничение, либо заранее поставить в известность заказчика о необходимости привлечения других поставщиков. Либо - в крайнем случае - скорректировать графики сборки по возможностям питающих потоков, но при этом сохранить сборку в качестве барабана всей системы.

ТОС с канбаном изобрели арабы :

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

Если поток I или A - запуск по первой операции логичен. Но когда сначала V, потом для части потоков снова V, потом A, потом I, потом ограничение, потом снова I... Либо APS, либо три веревки - на начало V и на начало A. А материальные потоки по вытягиванию - или канбану. APS будет делать _тоже_ самое.

PS Кстати там и программа есть - она план ограничения держит и веревки реализует.
PPS До кучи на самом входе поток A, но это отдельная песня - вот там MTIA вполне логичен.