5 почему (5 Whys)

На производстве Toyota сварочный робот внезапно остановился посреди операции. Тайити Оно, отец Производственной системы Toyota, разобрал случай пятью последовательными «Почему?»: робот остановился, потому что перегорел предохранитель от перегрузки цепи; цепь перегрузилась, потому что подшипники были недостаточно смазаны и заклинило; смазки не хватило, потому что маслонасос качал недостаточно; насос качал недостаточно, потому что забился заборник; заборник забился металлической стружкой, потому что на нём не было фильтра. Только на пятом «Почему?» команда нашла системный пробел — отсутствие фильтра, — устранение которого предотвращает весь дальнейший каскад отказов, а не просто чинит сгоревший предохранитель.

Метод «5 Почему» — не про магическое число пять, а про дисциплину не останавливаться на первом удобном ответе (обычно — «виноват конкретный человек») и идти дальше, к системной, процессной причине, которую можно устранить так, чтобы проблема не повторилась.

Происхождение и исследовательская база

Технику приписывают Сакити Тоёде, основателю Toyoda Automatic Loom Works (предшественника Toyota) — он применял последовательные вопросы «почему?» для разбора производственных проблем ещё в 1930-х годах. Формализовал и сделал технику центральной частью Производственной системы Toyota (TPS) Тайити Оно в 1950-х — именно его версия с примером сварочного робота стала наиболее цитируемым каноническим изложением метода. Международную известность техника получила в 1980-1990-х вместе с распространением бережливого производства (Lean) за пределами Toyota.

«Основа научного подхода Toyota — повторяя „почему" пять раз, проясняется и природа проблемы, и её решение» — Тайити Оно.

Формализовал технику как систематическую практику Тайити Оно, архитектор Производственной системы Toyota, в книге «Toyota Production System: Beyond Large-Scale Production» (впервые издана в Японии в 1978 году, английский перевод — 1988). Именно из этой книги происходит хрестоматийный пример со сварочным роботом, который открывает эту статью, — Оно использовал его как учебную иллюстрацию для инженеров Toyota.

Ключевые идеи и принципы

1. Принцип: данные и факты, а не предположения

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

   В производственной системе Toyota этот принцип формализован отдельным термином — genchi genbutsu (現地現物, «пойди и увидь сам»): прежде чем спрашивать «почему», ответственный обязан лично прийти на место события — к станку, на склад, на встречу с клиентом — и зафиксировать факт, а не полагаться на пересказ через несколько рук. Оно связывал именно с этим принципом надёжность всей последующей цепочки «Почему?»: недостоверный факт в основании делает бессмысленной сколь угодно логичную цепочку рассуждений над ним.

2. Принцип: процесс, а не человек

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

3. Принцип: логическая связность на каждом шаге

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

4. Принцип: пять — ориентир, а не жёсткий лимит

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

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: Останавливаться на симптомах.

   Первое «Почему?» получает ответ вроде «потому что сотрудник ошибся» — и на этом цепочка обрывается, хотя это симптом, а не причина.

   Как избежать

   Проверять каждый ответ вопросом «это уже то, что можно изменить в процессе, чтобы проблема не повторилась, или это ещё одно следствие чего-то более глубокого?» — и продолжать, пока ответ не станет процессным.

2. Ошибка 2: Искать виноватого, а не процессную причину.

   Цепочка вопросов явно или неявно сводится к «кто виноват», а не «что не так с процессом» — даже если формально доходит до пятого «Почему?», по факту решение — наказать человека, а не изменить систему.

   Как избежать

   На каждом шаге, где ответ называет конкретного человека, спрашивать следующее «Почему?»: «а что в процессе позволило/вынудило его так поступить?» — и идти дальше именно оттуда.

3. Ошибка 3: Не проверять логическую связность цепочки.

   Ответы на последовательные «Почему?» звучат тематически близко, но не следуют друг из друга напрямую — итоговая «корневая причина» логически не объясняет исходную проблему.

   Как избежать

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

4. Ошибка 4: Отвечать предположениями вместо проверенных фактов.

   Ответы формулируются как правдоподобные версии («наверное, дело в загрузке команды»), а не как факты, установленные проверкой процесса или данных.

   Как избежать

   Для каждого ответа спрашивать: «откуда мы это знаем?» — если единственный источник это чьё-то мнение, факт нужно сначала проверить, а не сразу продолжать цепочку.

5. Ошибка 5: Найти корневую причину и не довести до решения.

   Команда доходит до системной причины, фиксирует её и на этом останавливается — конкретное действие, устраняющее причину, не формулируется и не внедряется.

   Как избежать

   Обязательно завершать разбор конкретным решением с ответственным и сроком, и отдельно продумывать, как проверить, что проблема действительно перестала повторяться.

План внедрения

1. Неделя 1: сформулировать проблему фактами

   Чётко и без обвинений описать, в чём проблема — как её видит команда, как её видят клиенты, каковы наблюдаемые симптомы. Собрать команду людей, реально знающих процесс.

2. Неделя 2: пройти цепочку «Почему?» до процессной причины

   Последовательно задавать «Почему?», на каждом шаге проверяя логическую связность (если причина А, то следствие Б?) и фактическую опору ответа, пока причина не станет процессной, а не человеческой.

3. Неделя 3: сформулировать и проверить решение

   Определить конкретное изменение процесса, устраняющее найденную причину. Проверить: устранение действительно предотвратит повтор, а не только смягчит текущий случай.

4. Неделя 4: внедрить и проконтролировать

   Реализовать изменение процесса и убедиться, что проблема не повторяется — по факту, а не по ощущению.

5. Далее: закреплять как привычку команды

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

Как реализовать этот план с помощью фрейма «5 Почему» в OrgDevTools

Фрейм — две вкладки: «5 почему» и «Итоги» с вычисленным вердиктом.

На вкладке «5 почему»: карточка «Проблема (факты, без обвинений)» — сюда вносится формулировка из недели 1 плана; затем пять последовательно расположенных карточек «Почему 1»–«Почему 5», визуально соединённых стрелками — каждая заполняется ответом на предыдущий шаг (неделя 2 плана); далее карточки «Корневая причина» и «Решение» рядом (неделя 3).

Вкладка «Итоги» вычисляет вердикт по стадиям заполнения: проблема не сформулирована → предложение начать с нее; проблема есть, цепочка не начата → предупреждение начать цепочку; часть «Почему?» заполнена → фрейм явно показывает, сколько шагов из пяти пройдено, и напоминает не останавливаться на симптоме (прямая защита от ошибки 1); цепочка пройдена, но корневая причина не сформулирована → отдельное предупреждение; причина найдена, но решения нет → предупреждение (прямая защита от ошибки 5); все поля заполнены → зелёный вердикт с текстом решения. Кнопка «Создать задачу →» формирует задачу на внедрение решения корневой причины — соответствует неделе 4 плана.

Книги по теме

Джеффри Лайкер — «The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer» (2004, рус. изд. «Дао Toyota», Альпина Паблишер). Контекст TPS, внутри которой сформировалась техника «5 Почему».

Майк Ротер, Джон Шук — «Learning to See» (1998, рус. изд. «Учитесь видеть бизнес-процессы», Альпина Бизнес Букс). Практическое применение анализа причин в картировании потока создания ценности.

Джеймс Вумек, Дэниел Джонс — «Lean Thinking» (1996, рус. изд. «Бережливое производство», Альпина Паблишер). Место «5 Почему» в более широкой системе принципов бережливого производства.

Пример применения

Проблема: падение продаж в регионе.

• Почему падают продажи? — Меньше встреч с клиентами.

• Почему меньше встреч? — Менеджеры заняты отчётностью.

• Почему заняты отчётностью? — Новая CRM-система требует много ручного ввода данных.

• Почему система требует ручного ввода? — При внедрении не настроена интеграция с телефонией и почтой.

• Почему интеграция не настроена? — На этапе внедрения не был выделен ответственный за технические интеграции.

Корневая причина — процессная, не про менеджеров: отсутствие ответственного за интеграции при внедрении CRM. Решение — назначить ответственного и донастроить интеграции, а не требовать от менеджеров работать быстрее вручную.