Как провести анализ пяти почему с помощью ИИ: опишите наблюдаемую проблему и её границы, попросите модель задать почему по одному звену с указанием опоры, разрешите ветвление и unknown, а в конце получите цепочку, проверку связи и корректирующее действие. Число шагов зависит от того, какие причинные связи удаётся подтвердить.
Определите наблюдаемую проблему и её границы
Работа начинается с одного наблюдаемого события. В официальном инструменте CMS по пяти почему анализ первопричины описан как структурированный командный процесс, который помогает выявить глубинные факторы или причины события. Формулировка «клиенту ушла устаревшая инструкция» задаёт событие. Формулировка «плохая коммуникация в компании» задаёт мнение о компании и уводит разбор в сторону.
Границы фиксируют три вещи: что именно произошло, когда это заметили и где проходит край разбора. В команду по рекомендации CMS включают людей с личным знанием процессов и систем, затронутых проблемой. Для учебного примера это отправитель письма, владелец шаблона и тот, кто утверждает инструкции.
Проблему стоит записать одним предложением и держать её перед глазами. В обзоре Atlassian по упражнению пяти почему первый шаг назван так: выбрать одно утверждение о проблеме. Одно утверждение удерживает разбор от расползания на несколько инцидентов сразу.
Практический приём: рядом с проблемой выпишите, что в неё не входит. Если разбираете отправку письма, версии сайта и задержки оплаты остаются за границей. Такой список защищает от соблазна объяснить всё одной причиной.
Для ИИ границы формулируют как ограничение. Модель получает событие, список доступных свидетельств и запрет выходить за них. Дальше она задаёт вопросы по одному звену.
Учебный пример, который используется ниже: клиент получил старую инструкцию. Письмо E17 ведёт на версию v2, утверждённая актуальная инструкция — v3. Шаблон T2/version2 содержит ссылку v2. Все свидетельства и журнал вымышлены и служат разбору порядка действий.
| Что фиксируем | Пример записи | Зачем |
|---|---|---|
| Событие | Клиент получил старую инструкцию | Один наблюдаемый факт |
| Момент | Отправка письма E17 | Привязка к записи |
| Границы | Только версии инструкции | Отсекает лишние темы |
| Участники | Отправитель, владелец шаблона | Носители знания |
| Свидетельства | Журнал E17, шаблон T2 | Опора для звеньев |
Спрашивайте почему по одному звену с доказательством
Каждое звено — один вопрос и один ответ с указанием, на чём он держится. В учебном примере первый вопрос звучит так: почему ушла старая версия? Ответ: отправили ссылку v2, опора — письмо E17. Второй вопрос: почему v2? Ответ: использовали неизменённую ссылку из T2/version2, опора — журнал отправки E17, шаблон и объяснение отправителя.
Опора превращает догадку в проверяемое утверждение. Публикация MTF Institute по промпту для пяти почему советует запрашивать свидетельство на каждом причинном шаге, учитывать несколько ветвей и системные условия, различать корреляцию и причину. Тот же материал предлагает останавливаться, когда команда дошла до контролируемого условия, подкреплённого свидетельствами.
Различение корреляции и причины решает исход разбора. Совпадение по времени двух событий само по себе связь не доказывает. Связь подтверждают записью, документом или прямым объяснением участника, которое можно перепроверить.
Официальный инструмент CMS предупреждает: ответы должны быть ясными и краткими, при этом слишком простые ответы упускают важные детали. Ответ «человек ошибся» краток и упускает механизм: как ссылка попала в шаблон, кто отвечает за обновление, почему проверка не сработала.
Промпт для этого шага просит модель вести разбор по одному звену и помечать опору. Готовый вариант:
Ты помогаешь разобрать инцидент методом пяти почему.
Событие: [наблюдаемая проблема].
Доступные свидетельства: [журналы, документы, объяснения].
Правила:
1. Задавай по одному вопросу «почему» за раз.
2. К каждому ответу указывай опору: конкретный документ, запись или объяснение.
3. Если опоры нет, помечай узел как UNKNOWN и предлагай, какое свидетельство собрать.
4. Разрешай несколько ветвей причин.
5. Различай корреляцию и причину.
6. Останавливайся на контролируемом условии, подкреплённом свидетельствами.
7. Не подменяй механизм обвинением человека.
Выдай цепочку в виде таблицы: звено, ответ, опора, статус.
Что менять под себя: событие, список свидетельств и правило остановки. Если разбор идёт по техническому сбою, в свидетельства добавьте логи и метрики, а в правило остановки — порог, при котором условие считается контролируемым.
Пять шагов остаются ориентиром
Число пять дало методу имя и служит подсказкой по глубине. В документе CMS прямо сказано, что обычно требуется от трёх до пяти почему, а иногда больше пяти. Жёсткое требование дойти ровно до пятого звена заставляет дописывать причины, которых в свидетельствах нет.
Общий ориентир CMS — от трёх до пяти вопросов, иногда больше. Для конкретного инцидента глубину выбирают по подтверждённым связям. Число вопросов выбирают по свидетельствам и проверяемым связям; при недостатке данных отмечают UNKNOWN и планируют уточнение.
В учебном примере цепочка обрывается на третьем звене. Почему старая версия? Отправили ссылку v2. Почему v2? Использовали неизменённую ссылку из T2/version2. Почему шаблон не обновлён? Здесь данных не хватает: нужен вопрос владельцу шаблона и история обновлений. Узел помечается как UNKNOWN.
Остановка на unknown — полноценный результат разбора. Публикация MTF Institute советует просить ассистента помечать допущения и неопределённость, сверять фактические утверждения по первичным источникам и давать ответственным людям возможность оспорить рекомендацию до действия. Неопределённость, названная вслух, направляет сбор данных.
Инструмент CMS оговаривает, что метод пяти почему помогает найти первопричину не всегда, и в качестве другой техники называет диаграмму Исикавы. Для задач с несколькими независимыми причинами диаграмма подходит лучше линейной цепочки.
| Ситуация | Что делать | Почему |
|---|---|---|
| Одна подтверждённая линия | Продолжать по проверяемым связям | Остановиться при нехватке данных или на обоснованном контролируемом условии |
| Данных не хватает | Узел UNKNOWN | Нужен сбор свидетельств |
| Несколько независимых причин | Ветви или диаграмма Исикавы | Линейная цепочка теряет связи |
| Причина упирается в человека | Вернуться к механизму | Обвинение не объясняет процесс |
Разрешите ветвление причин и unknown
Одна линия объясняет не каждый инцидент. В учебном примере рядом с основной цепочкой появляется вторая ветвь: гипотеза о пропуске обнаружения. В чек-листе есть только проверка имени клиента, отдельной отметки о проверке версии нет. Пробел контроля мог способствовать ошибке.
Эта ветвь остаётся гипотезой. Чек-лист подтверждает пробел в контроле, при этом не показывает, какие проверки фактически выполнили при отправке E17. Следующий тест — спросить отправителя и посмотреть заполненный лист отправки, если он существует. До этого причинный вклад контроля помечается как UNKNOWN.
Ветвление требует пометок. Каждой ветви присваивают статус: подтверждена свидетельством, гипотеза или unknown. Такой статус не даёт гипотезе превратиться в вывод при пересказе.
Промпт для ветвления:
Продолжи разбор инцидента: [событие].
Уже есть цепочка: [звенья с опорами].
Задачи:
1. Предложи дополнительные ветви причин, которые не противоречат свидетельствам.
2. Для каждой ветви укажи, какое свидетельство её подтверждает.
3. Помечай ветви статусами: подтверждена, гипотеза, UNKNOWN.
4. Для каждой ветви UNKNOWN предложи конкретный следующий тест.
5. Не объединяй ветви в одну причину без свидетельств.
Выдай список ветвей с опорами и статусами.
Что менять под себя: перечень уже собранных звеньев и доступные источники свидетельств. Если ветвь упирается в данные другой команды, в следующем тесте укажите, к кому идти с вопросом.
Ветвление полезно и тогда, когда причина лежит в системе. Публикация MTF Institute называет системные условия отдельным предметом рассмотрения наряду с отдельными действиями. Системное условие объясняет, почему ошибка повторяется у разных людей.
Дайте цепочку, проверку связи и корректирующее действие
Итог разбора — три части: цепочка с опорами, проверка связи и действие. Проверка связи опирается на вопрос из инструмента CMS: если исправить последний ответ, проблема повторится? Если да, это скорее сопутствующий фактор. Если нет, звено претендует на роль корневой причины.
В учебном примере планируют проверить гипотезу: после утверждения актуального адреса и обновления шаблона новые письма должны вести на действующую инструкцию. Звено «неизменённая ссылка в шаблоне» остаётся проверяемым кандидатом в причину; результат правки ещё предстоит подтвердить. Причина отсутствия обновления и вклад пробела в чек-листе остаются UNKNOWN до сбора данных.
Действия делят на три вида. Публикация MTF Institute предлагает containment, corrective и preventive actions: сдерживающие, корректирующие и предупреждающие. В учебном примере сдерживающее действие — утвердить адрес актуальной инструкции, корректирующее — назначить владельца шаблона, предупреждающее — добавить явную проверку версии.
Проверка результата планируется заранее. В учебном примере через неделю сравнивают три новых письма с действующей инструкцией по учебному плану проверки. Число три выбрано только для этого учебного плана. Расследование и проверка в реальном продукте не проводились.
Промпт для итогового блока:
Собери итог разбора инцидента: [событие].
Цепочка: [звенья с опорами и статусами].
Сделай три вещи:
1. Для последнего звена проверь связь вопросом: если исправить этот ответ, повторится ли проблема?
2. Предложи сдерживающее, корректирующее и предупреждающее действия.
3. Для каждого действия укажи владельца и способ проверки результата.
Помечай допущения и неопределённость. Не выдавай рекомендацию за проверенный факт.
Что менять под себя: формулировку проверочного вопроса, состав действий и способ проверки результата. Если владелец действия неизвестен, оставьте поле пустым и вынесите его в список вопросов.
| Часть итога | Учебный пример | Как проверить |
|---|---|---|
| Цепочка | v2 → шаблон T2 → unknown | Сверка с журналом E17 |
| Проверка связи | Гипотеза: обновление шаблона устранит отправку старой ссылки | Проверить новые письма после правки и сохранить статус гипотезы до проверки |
| Сдерживающее | Утвердить адрес инструкции | Сверка адреса в письме |
| Корректирующее | Назначить владельца шаблона | Запись о владельце |
| Предупреждающее | Проверка версии в чек-листе | Три новых письма через неделю |
Частые вопросы
Что такое анализ пяти почему?
Это командный разбор события через последовательные вопросы «почему», при котором каждое звено опирается на свидетельство. Официальный инструмент CMS описывает анализ первопричины как структурированный командный процесс для выявления глубинных факторов события. Метод дал имя по числу шагов, при этом глубина цепочки зависит от задачи.
Почему пять шагов считаются ориентиром?
Число пять подсказывает примерную глубину разбора. В документе CMS сказано, что обычно требуется от трёх до пяти почему, а иногда больше пяти. Разбор заканчивают тогда, когда очередное звено перестаёт добавлять понимание и упирается в контролируемое условие со свидетельствами.
Как ИИ помогает на каждом звене?
Модель задаёт по одному вопросу за раз и требует опору для каждого ответа. Публикация MTF Institute советует запрашивать свидетельство на каждом шаге, учитывать ветви и системные условия, различать корреляцию и причину. Ассистент также помечает допущения и неопределённость.
Что делать, если данных не хватает?
Узел помечается как UNKNOWN, и разбор останавливается до сбора свидетельств. В учебном примере на вопросе об обновлении шаблона нужен вопрос владельцу и история обновлений. Публикация MTF Institute предлагает сверять фактические утверждения по первичным источникам и давать ответственным людям оспорить рекомендацию до действия.
Как проверить, что найдена корневая причина?
Инструмент CMS предлагает вопрос: если исправить последний ответ, повторится ли проблема? Ответ «да» указывает на сопутствующий фактор, ответ «нет» делает звено кандидатом в корневую причину. Дополнительно планируют проверку результата после корректирующего действия.