Общие проблемы при применении 5-ти методов в технике и как их преодолеть

Введение

Метод 5 Whys является одним из самых простых, но наиболее эффективных инструментов, доступных инженерам для анализа первопричин. Этот метод, разработанный в производственной системе Toyota и популяризированный Taiichi Ohno, включает в себя многократный вопрос «Почему?», обычно пять раз, до тех пор, пока не появится основная причина проблемы. При правильном применении он может предотвратить повторяющиеся сбои, уменьшить отходы и обеспечить постоянное улучшение инженерных дисциплин от механического проектирования до разработки программного обеспечения.

Несмотря на кажущуюся простоту, многие инженерные команды изо всех сил пытаются получить долгосрочные результаты от 5 причин. Они либо останавливаются слишком рано, становятся жертвами когнитивных предубеждений, либо не привлекают нужных людей. Результатом является исправление на поверхностном уровне, которое лечит симптомы вместо коренных причин. В этой статье рассматриваются наиболее частые подводные камни, возникающие при использовании 5 причин в инженерном контексте, и предлагают действенные стратегии для преодоления каждого из них. Уточнив, как вы применяете эту классическую технику, вы можете существенно повысить надежность своих усилий по решению проблем и создать более надежные решения.

5 причин, почему техника

Основная предпосылка 5 причин элегантно проста: начните с четкого изложения проблемы, затем спросите: «Почему это произошло?» Для каждого ответа, пробурите глубже, задавая другой «Почему?», пока вы не достигнете причины, которая может быть решена корректирующим действием.

В технике, метод часто используется в качестве части анализа первопричины (RCA) наряду с другими инструментами, такими как диаграммы кости рыб, анализ дерева неисправностей или FMEA. Он работает лучше всего, когда проблема относительно содержится и команда имеет непосредственное знание процесса. Например, если критический крепеж продолжает ослабевать на сборочной линии, 5 Whys может привести от «свободного болта» к «недостаточному крутящему моменту» к «оператору, не соблюдающему спецификацию крутящего момента» к «отсутствию четкой учебной документации» к «программе обучения, не обновленной после изменения конструкции».

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

Общие проблемы при применении 5 причин в инженерии

Даже опытные инженеры могут попасть в ловушки, подрывающие эффективность 5 Whys. Ниже приведены самые значительные проблемы, каждая из которых объясняется конкретными примерами из реальных инженерных настроек.

1. остановка на симптоматических причинах (поверхностный анализ)

Наиболее частой ошибкой является слишком быстрое завершение вопросительной последовательности. Инженеры часто определяют причину, которая кажется правдоподобной, и останавливают процесс, не проверяя, существуют ли более глубокие коренные причины. Например, команда, исследующая отказ насоса, может ответить на первое «Почему?» с «Эродированный импеллер». Если они остановятся на этом, они просто заменят импеллер. Но дальнейший вопрос — «Почему импеллер разрушался быстрее, чем ожидалось?» — может показать, что жидкость содержала абразивные частицы, которые сами указывают на отсутствие фильтра в процессе восходящего потока.

Остановка при первом ответе предотвращает обнаружение того, что график обслуживания фильтра был неадекватным.

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

2. Личное и организационное предубеждение

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

Например, в настройках разработки программного обеспечения команда может обвинить сбой сервера в «недостаточной памяти», потому что это то, что они подозревали с самого начала. Они останавливаются после одного или двух «Почему», никогда не спрашивая, почему использование памяти резко возросло. Если бы они нажали, они могли бы обнаружить утечку памяти, введенную недавним кодовым обязательством. Предвзятость к самому простому объяснению - в сочетании с нежеланием изучать изменения кода - оставила реальную причину неоткрытой.

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

3. Отсутствие командного сотрудничества и различные перспективы

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

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

4. Ошибочные симптомы по причинам

С поверхностным анализом связана тенденция записывать симптомы, как если бы они были первопричинами. Инженеры могут перечислить «слишком высокую температуру» как причину, когда это на самом деле является симптомом отказа системы охлаждения. В 5 Почему необходимо быть осторожным, чтобы различать то, что наблюдается (симптомы) и то, что производится основным механизмом (причины).

Эта путаница часто возникает, когда само заявление о проблеме является расплывчатым. Если команда начинает с «Машина перестала работать», первым Почему может быть «Потому что она перегрелась». Перегрев является симптомом, а не причиной. Команда должна продолжать спрашивать, почему она перегрелась. Если они не переформулируют вопрос, чтобы вызвать причинно-следственную связь, они останутся застрявшими на уровне симптомов.

5.Сфера охвата Creep и чрезмерный анализ

Хотя недостаточная глубина является распространенной ловушкой, некоторые команды заходят слишком далеко в другом направлении, преследуя причины в областях, которые невозможно решить или не имеют отношения к непосредственной проблеме. 5 Почему не требуется отображение каждого фактора, способствующего происхождению Вселенной. Классическая ловушка задает вопрос «Почему?» так много раз, что команда в конечном итоге ставит под сомнение основополагающие предположения бизнеса, такие как «Почему компания решила использовать этого поставщика?», когда более простого исправления, такого как обновление контрольного списка обслуживания, будет достаточно.

Чрезмерный анализ тратит время и ослабляет фокус. Цель состоит в том, чтобы достичь причины, которую можно контролировать или на которую можно повлиять. Если ответ на пятый вопрос указывает на фактор, не зависящий от команды (например, правительственные постановления), анализ должен остановиться на четвертом вопросе и предложить действие в сфере влияния команды.

Стратегии преодоления этих вызовов

Каждая из вышеперечисленных проблем может быть смягчена путем преднамеренной практики и структурных улучшений процесса 5 Whys. Инженерные команды, которые последовательно производят эффективные RCA, принимают следующие стратегии.

1. Институционализировать глубокое расследование с помощью правила «Пять причин»

Чтобы бороться с поверхностным анализом, необходимо соблюдать правило, согласно которому команда должна спрашивать «Почему?» по крайней мере пять раз, даже если первые три ответа кажутся убедительными. Запишите каждый ответ и продолжайте до тех пор, пока последний ответ не будет выражен не как причина, а скорее как системное условие, такое как «Наш график профилактического обслуживания не включает эту проверку» или «В спецификации дизайна не было вызова крутящего момента».

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

2. Повышение объективности посредством данных и упрощения процедур

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

Назначить нейтрального посредника, который не заинтересован в результате. Роль этого человека заключается в том, чтобы оспаривать предположения, перенаправлять, когда появляется предвзятость, и обеспечивать каждому члену команды равный голос. Многие организации используют обученных посредников RCA, которые вращаются между командами, чтобы поддерживать объективность. Посредник также может удержать группу от сползания в вину, перефразируя вопросы необвинительным образом, например: «Что в процессе позволило этой неудаче произойти?»

3. Создание кросс-функциональных команд и поощрение сотрудничества

Никогда не проводите анализ 5 Whys только с людьми, наиболее близкими к проблеме. Включите хотя бы одного человека из другого отдела или технической специальности. Для механического сбоя пригласите коллегу из отдела проектирования качества, технического обслуживания, операций и, если возможно, инженера-конструктора. Для ошибки программного обеспечения включите тестировщика, менеджера по продуктам и, возможно, инженера по безопасности.

Запланируйте специальную 45-минутную сессию для 5 Whys и используйте доску или инструмент цифровой совместной работы, чтобы захватить цепочку рассуждений в режиме реального времени. Убедитесь, что все участники понимают, что они должны вносить как вопросы, так и ответы, а не просто наблюдать. Если участник молчит, фасилитатор должен подсказать им: «С вашей точки зрения, есть ли еще один фактор, который мы не рассмотрели?»

4. Отличить причины симптомов с четкими заявлениями о проблемах

Перед началом 5 Whys, вложите время в создание точного, основанного на данных заявления о проблеме. Вместо «Машина перестала работать», напишите «Производственная линия была отключена на 47 минут 15 марта, потому что насос охлаждающей жидкости потерял давление». Хорошее заявление о проблеме описывает отклонение, воздействие и известные факты. Эта ясность предотвращает команду от ошибочного принятия симптомов по причинам.

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

5. Установить границы для сферы охвата и действенности

Чтобы предотвратить чрезмерный анализ, определите границы RCA заранее. Согласитесь, что команда остановится, как только определит причину, которая соответствует двум критериям: (а) она будет действовать командой или организацией, и (б) исправление ее предотвратит повторение конкретной проблемы. Если после пяти причин команда достигнет причины, такой как «Изменился рынок», они должны отступить и спросить, было ли упущено предыдущее Почему — изменение рынка редко является основной причиной, но это может быть ограничение, которое требует другого типа решения.

Используйте ворота для принятия решения: перед переходом к следующему Почему, спросите: «Если мы исправим эту причину, прекратится ли первоначальная проблема?» Если ответ «да, но только временно», продолжайте копать. Если ответ «да, навсегда», то вы достигли хорошей точки остановки. Это правило сохраняет процесс эффективным и целенаправленным.

Пример: применение 5 причин в производственном сценарии

Рассмотрим алюминиевый экструзионный пресс, который производит детали с забивкой поверхности. Заявление о проблеме: «Экструдированные профили показывают видимые продольные царапины, что приводит к увеличению скорости лома на 12% за последние две недели». Межфункциональная команда, включая оператора пресса, технического специалиста по техническому обслуживанию, инженера-технолога и инспектора качества, собирается для выполнения 5 Whys.

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

Коренная причина, выявленная на пятом уровне, - сбой системы связи. Команда реализует корректирующее действие: устанавливает физическую сигнальную доску на прессе, которая меняет цвет, когда происходит изменение цвета, и пересматривает стандарт передачи смены, чтобы включить устное подтверждение. Скорость утилизации снижается до 1% в течение недели. Здесь 5 Whys преуспели, потому что команда оставалась объективной, включала различные перспективы и не останавливалась на «грязной смерти».

Заключение

Метод 5 Whys остается одним из самых доступных и мощных инструментов в инструментальном наборе для решения инженерных проблем. Его простота, однако, может быть обманчивой. Без преднамеренного внимания к глубине, предвзятости, сотрудничеству, ясности причинно-следственной связи и масштабу команды, вероятно, будут генерировать поверхностные исправления, которые растрачивают ресурсы и подрывают доверие к процессу.

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

Для дальнейшего чтения о технике 5 Whys и ее происхождении см. руководство ASQ по анализу первопричин и Объяснение Института бережливого предпринимательства 5 Whys . Для более глубокого погружения в предвзятость в решении проблем Harvard Business Review предлагает практические советы .