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

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

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

Процесс 3.б именуется в ИТ как " Канбан ". Оптимум по цене качеству есть, хотя бы потому что, по "ячейкам" будет туда-сюда ходить не полностью всё решение, а только дефектные его части, при том они не будут проходить полный цикл во всех случаях.

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

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

"Про иглу" мы недавно рассматривали здесь в другой теме. Выяснилось, что виноват точильщик, которого сократили, потому что игла тупая и когда тупая - ломается.

Суть не в этом. Вывод неправильный. И решения аналитиком в данном случае пошли вкривь и вкось. [Он стал оптимизировать "скорость x ткань x крепление иглы"], логически правильно, но "неоптимально" . Игла тупая.

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

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

Если поболтать - то тогда можно и по-примерам...

Андрей Сазонов пишет: В ITIL есть инцидент, а есть корневая причина (одного или нескольких инцидентов). Например если мы заменим одну иглу - инцидент будет исчерпан, а если мы заменим поставщика игл, то снизится количество простоев в целом. А если заменим поставщика да еще и крепить будем аккуратней - то еще больше снизится.

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

Александр пишет: Я надеюсь, что можно для каждой группы инцидентов(несоответствий) можно найти причину (ряд причин), что позволит найти конкретное решение, устраняющее эти причины.

Короче, вы хотите в финале иметь рыбу (Диаграмму Ишикавы), в голове у которой будет КОНКРЕТНЫЙ дефект, а на костях - КОНКРЕТНЫЕ причины (ряд причин). ?

Андрей Сазонов пишет: Есть следующий процесс:

требования -> план -> разработка -> тестирование -> развертывание

1. Список возможных причин: неточность требований, неполнота требований, неполнота плана, разработка при очень зажатых сроках, неполное тестирование, тестирование без учета требований, развертывание без учета вопросов дальнейшей эксплуатации (список явно неполный, но для начала сойдет).
3. Из пункта два вытекает как минимум следующее:
а. Нужен испытательный стенд, который будет моделировать собой среду эксплуатации,

Для этого случая есть классической решение! С проблемой большого количества ошибок разработчики ПО столкнулись в 60 годах прошлого века. Анализ показал, что проблема в том, что отсутствует технология разработки требований. В результате были разработаны десятки таких технологий, однако в настоящее время стандартом стала методология структурного анализа и проектирования (SADT), которая сейчас обозначается IDEF.
А теперь ответьте на вопрос - в каких фирмах по разработке ПО используют этот стандарт? Нет, у нас идут по другому пути - создают отделы тестирования, которые ищут ошибки в разработанных программах. А ведь идея структурного программирования ставила своей целью написание ошибок, в которых не будет ошибок.

Александр Филонов пишет: Короче, вы хотите в финале иметь рыбу (Диаграмму Ишикавы), в голове у которой будет КОНКРЕТНЫЙ дефект, а на костях - КОНКРЕТНЫЕ причины (ряд причин). ?

Нет, такую "рыбу" я не хочу! Диаграмма Исикавы предназначена для поиска возможных причин, а точнее тех факторов, которые могу влиять на несоответствие! Конкретную причину можно найти только дополнительным анализом на основе конкретных данных.

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

А начинать анализ с чего будете? С Диаграммы Исикавы?

Александр Филонов пишет: А начинать анализ с чего будете? С Диаграммы Исикавы?

Да, те факторы, которые выявлены в диаграмме Исикавы, могут служить основанием для проведения детального анализа по этим факторам. Кроме это в каждом конкретном случае, могут потребоваться дополнительные данные. Например, модель технологического процесса, дерево отказов и т.д. После этого, делается предположение о причине дефекта, собираются дополнительные данные, по которым можно оценить достоверность этого предположения.

Александр пишет: Да, те факторы, которые выявлены в диаграмме Исикавы, могут служить основанием для проведения детального анализа по этим факторам.

Выявлены кем? "Простым рабочим" или "аналитиком"?

PS Не забудьте Ваш тезис о ДИ предназначен только для решения "простых задач".