Игорь Балакерский пишет: ...есть очень-очень узкий круг предприятий, которым в действительности требуется ведение полновесных комплексов работ по СМК

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

Игорь Балакерский пишет: К эйфории Михаила - в смысле "везде" - отношусь с пониманием

К которой эйфории?
Я битый много и разнообразно. Мне просто неинтересно быть пессимистом.
Все, о чем пишу - сухой остаток личного опыта. Сделать можно все - если хотеть

...как там говориться: "для адекватного понимания"

Михаил Шустер пишет: ...Неважно, как ты называешь. Главное-что ты делаешь.

С этим согласен, что называется, на 200% вот, по-этому, и пишу здесь, что в современных условиях беспереспективно подходить к производственным и коммерческим задачам на основе одноЙ - "ГЛАВНОЙ" - методологии (СМК, ТОС, ТРИЗ, ЛИН, 6-сигма, ФСА, Сист.Дин, SPC и т.д., продолжать могу бесконечно). Всегда, будет МИКС

...пишите

К примеру, на заводе У, Свердловск, начались проблемы с качеством поставок после того, как там ликвидировали участок заготовки и перешли на кооперацию с заводом А, Волгодонск. Ругались насмерть...А потом объединили усилия, заслали в А бригаду конструкторов-технологов и порылись в технологии.... В результате разработали контрольные карты, где учли слабые места и заставили А выполнять приемку по этим картам. Качество на входе в У резко возросло..

...осмысляя этот пример, естественно, возникает вопрос: где начало, где пружина успешного решения задачи? По моему мнению, их несколько:
1. "Объединили усилия...". Все современные методы решения проблем, что перечислял выше предлагают ГРУППОВОЕ РЕШЕНИЕ ПРОБЛЕМ и СОЗДАНИЕ РЕЖИМА ДИАЛОГА
2. Порылись в технологии (нашли "слабые места"). В современных методах решения задач есть особый этап - ЭТАП ПОИСКА РЕШЕНИЯ -и этот этап не имеет никакого отношения к регламентации в ИСОшном понимании. Да, стат. методы великолепный инструмент обнаружения проблем, но, преобразовывать систему, ставить мысленные эксперименты по изменению системы, разрешать противоречия в операционных зонах системы, увы, стат. методы не умеют. Ну, в конце концов, не для того они и нужны
3. "В результате разработали контрольные карты..." Всё правильно, любые изменения контролируем на статистиках
4. ...и только,во-о-т, теперь настал "звёздный час" СМК и пр.

Мне кажется вполне хороший пример последовательности методов.

Во всей этой кухне, пожалуй, профессионалам (не в смысле, кто деньги этим зарабатывает, продавая услуги консалтинга, а в смысле, применяющим инструменты разнообразных методологий ("...Гробы <только> не могём. Потому - с гробами долбежу много." ") , так вот, профи самое интересное ГДЕ ГРАНИЦЫ ТОГО ИЛИ ИНОГО МЕТОДА. Собственно, об этом сам пишу много, и жду это от других (где ТРИЗ не работает, где ТОС проседает, где СМК не тянет, где СистДин - "из пушки по воробьям" и т.д.)

Игорь Балакерский пишет: ...как там говориться: "для адекватного понимания"

Согласен, я увлекся. Остапа понесло
Сам же вначале говорил про границы применения СМК и сам же их перешел, как самураи у реки

Михаил Шустер пишет: К тому же раздражает термин "встроенное качество"
А какое оно еще бывает?
Я бы еще понял "встроенный контроль", типа "самозащищенность" для АЭС.

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

Дмитрий Ким пишет: Наши наставники с Тойоты, тоже не употребляют этот термин. Хотя до знакомства с ними, я думал, что этот термин их придумка) Они говорят - "автономизация". Т.е. каждый процесс, оператор, бригада, должны быть автономны - наделены всеми необходимыми полномочиями и обеспечены ресурсами для выполнения своих операций точно-в-срок и с заданным качеством.

Можно также говорить о термине "встроенное некачество". Это когда мы заранее планируем процессы со слэком на расхлябанность, брак, waste, переделку... и прочую муду. Зачем напрягаться? Все равно придет пьяный рабочий и напортачит. А по сему забьем побольше материала на переделку, увеличим буфер, наставим побольше людей...И лодка поплывет в безоблачном небе. ОТК и 7 футов под килем!

PS Термин Built-in quality используется у Деминга, у Ишикавы (The next worker in line is your Customer) еще с 50-х годов прошлого столетия. TQC.
Обычно приводится пример, когда методами SPC снижают брак до 5-6%, а встроенным качеством (poka-yoke, jidoka, andon, self-diagnostic, etc), последовательной проверкой друг друга на линии уровень брака снижается до 0.5% (цифры - для порядка).

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

"Планируем процессы" - это как?
Как в этих спланированных процессах отражена расхлябанность и др или их отсутствие?

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

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

"Планируем процессы" - это как?
Как в этих спланированных процессах отражена расхлябанность и др или их отсутствие?

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

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

Михаил Шустер пишет: К тому же раздражает термин "встроенное качество"
А какое оно еще бывает?
Я бы еще понял "встроенный контроль", типа "самозащищенность" для АЭС.

А бывает ещё "качество как получится, хрень отбракуем".

Не могу не согласиться с тем, что ИСОобразное СМК - системный подход в отношении обеспечения хм... даже не совсем готов назвать объект, в отличие от улучшайзинговых идеологий-методов типа ТОСа, "встроеного качества" 6 сигм, реинжиниринга бизнес-процессов и т.п.
Однако, нет смысла их противопоставлять. Это всё хорошие и полезные штуки при умелом применении, как и и оклевётанная "потогонная" система Тейлора. И в то же время, нет среди них всех ,включая и СМКшный подход, "золотой пули", способной ощасливить любое предприятие.

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

Я думал с этого начать… Может все-таки потратить время и начать с полной ревизии? Поставив первоочередную цель - ликвидировать все не работающие документы, а затем "шлифовать" поочередно отдельные направления?

И, относительно идеолога - я считал, что идеологом любых масштабных изменений в организации, должен быть директор (CEO и/или акционер). В случае с ИСО, я понимаю, что идеологом быть не могу. Но, после Вашего ликбеза, Михаил, думаю, что смогу быть конструктивным оппонентом идеолога
Может ли быть идеологом не директор? Из кого готовить идеолога? Какая базовая подготовка желательна, с чего начать его обучение?

Дмитрий Ким пишет:

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

Я думал с этого начать… Может все-таки потратить время и начать с полной ревизии? Поставив первоочередную цель - ликвидировать все не работающие документы, а затем "шлифовать" поочередно отдельные направления?

Дмитрий, критерий "неработающие" документы, это очень часто не триггер, а спектр состояний.
Что если документ в целом работает, а приложение А устарело? Или раздел 3 не совсем точно отражает объективную реальность. И наконец, как быть с документом, о существовании которого уже забыли, но никто его не отменял? Вспомнить и отменить?