Проблема не в том, что вы не нашли причину. Проблема в том, что вы слишком рано поверили в первую версию
У повторяющихся бизнес-проблем почти всегда один и тот же сценарий.
Сначала появляется симптом. Потом команда быстро придумывает объяснение. Потом запускается срочное действие. Потом на короткое время становится тише. Потом проблема возвращается.
Подробное руководство тут:
В этот момент компания обычно делает неправильный вывод. Ей кажется, что «исправление не сработало». Хотя часто не сработало не исправление. Не сработала сама логика поиска причины.
Диаграмма Исикавы полезна именно здесь. Не как академический артефакт и не как обязательный ритуал из учебника по качеству, а как способ сломать удобную управленческую иллюзию: будто у сложной проблемы есть одно быстрое, очевидное и психологически комфортное объяснение.
В статье это хорошо приземлено: fishbone — один из базовых инструментов качества, он особенно уместен там, где причин много, они живут в разных слоях процесса, а симптом понятен, но корень ещё не доказан. При этом у проблемы может быть не одна «главная» причина, а связка contributing factors. И это критично для бизнеса, потому что привычка рано назначать одного виноватого почти всегда ухудшает качество решения.
Самая взрослая мысль в этом материале вообще не про схему.
Она про то, что RCA чаще ломается после анализа. Статья отдельно опирается на обзорный слой вокруг RCA: у root cause analysis давно есть репутация полезного, но не самодостаточного подхода, а слабые действия после разбора — дополнительное обучение, формальное усиление правил, ещё одна памятка — регулярно критикуются как удобные, но не самые сильные меры. Там же приводится пересказ обзора 302 RCA, где такие действия встречались слишком часто. То есть даже хороший разбор причин не спасает, если выход из него управленчески слабый.
Что отсюда полезно забрать без всякой романтики.
1. Проблему нельзя формулировать “по ощущениям”. Нужны метрика, период, масштаб и сегмент. Пока у вас «что-то просело», у вас нет объекта анализа.
2. Обсуждать причины без данных — плохая привычка, а не скорость. Минимум до сессии: было/стало, сегменты, изменения за период, события, жалобы, ограничения.
3. Ярлык — не причина. «Люди халтурят» — это раздражение, замаскированное под анализ. «Статус заказа меняется с задержкой на 40 минут» — уже версия, которую можно проверить.
4. “5 почему” нужно не для красоты. Обычно настоящая причина начинается там, где заканчивается первая удобная формулировка.
5. Хорошая диаграмма без приоритизации почти бесполезна. В статье есть практичная модель: влияние × повторяемость × управляемость × подтверждённость. Она не стандартная догма, но для бизнеса очень здравая: убирает шум и помогает не хвататься за всё сразу.
Особенно сильным материал становится на примере селлера: рост возвратов с 5,8% до 11,9% после обновления поставки и карточки не сводится к бытовому «товар стал хуже» или «поддержка недожимает». Корень уходит в разрыв между контентом, фактической партией и отсутствием владельца шага сверки. И вот это уже взрослый управленческий сюжет: проблема жила не в одном человеке, а в ничьей зоне между функциями.
Сильная ценность полного разбора не в том, что он ещё раз объясняет fishbone. Ценность в другом: он показывает, где именно метод помогает, где его не надо тащить насильно, как он дружит с 5 Why, Pareto, блок-схемой и FMEA, и почему вопрос «что делать после диаграммы» важнее самой диаграммы.