Диаграмма Исикавы («рыбья кость»): как найти причину проблемы

Диаграмма Исикавы — причинно-следственная схема, которая помогает собрать и упорядочить возможные причины одной проблемы. Её называют «рыбьей костью»: в голове находится наблюдаемый результат, а на ветвях — факторы, которые могли к нему привести.

Важно различать гипотезу и доказанную причину. Заполненная схема ещё не объясняет, почему упали продажи или сорвался релиз. Она показывает, какие версии стоит проверить и каких данных не хватает. Ни количество стикеров, ни уверенность руководителя не заменяют такую проверку.

Когда нужна диаграмма Исикавы

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

Начните с конкретного наблюдения: «В сентябре доля заявок, закончившихся оплатой, снизилась с 12% до 9%». Формулировка «отдел продаж плохо работает» не подходит: она уже назначает виноватого и не задаёт измеримый результат. Если требуется восстановить сервис после аварии, сначала устраните последствия, а разбор причин проведите после стабилизации.

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

Из чего состоит «рыбья кость»: 6M, 4P и 4S

Справа запишите проблему — «голову». К ней ведёт основная горизонтальная линия. Крупные наклонные ветви обозначают категории, небольшие ответвления — причины и причины следующего уровня. Записывайте одну мысль на карточку: её легче обсуждать, перемещать и проверять.

В производственных задачах часто используют 6M: люди (Manpower), оборудование (Machine), методы (Method), материалы (Material), измерения (Measurement) и среда (Mother Nature / Environment). Это подсказки для обсуждения, а не обязательная классификация. Для отдела продаж «материалы» могут означать презентации и коммерческие предложения, а «оборудование» — CRM и телефонию.

Для сервисной команды встречается 4P: Policies, Procedures, People, Plant — правила, процедуры, люди и рабочая инфраструктура. Вариант 4S объединяет Surroundings, Suppliers, Systems, Skills — окружение, поставщиков, системы и навыки. Названия в разных практиках различаются: договоритесь о смысле категорий перед началом, чтобы не тратить встречу на спор о буквах.

Не пытайтесь заполнить все ветви одинаковым числом причин. Пустая категория допустима; перегруженную можно разделить. Если одна версия подходит в две группы, выберите основную и отметьте связь. Смысл схемы — помочь исследованию, а не выиграть конкурс аккуратной классификации.

Как построить диаграмму Исикавы за шесть шагов

1. Определите проблему. Зафиксируйте метрику, период, границы процесса и отличие от нормы. Договоритесь, что именно команда хочет объяснить.
2. Выберите категории. Возьмите 6M или понятные команде группы. Для цифрового продукта это могут быть требования, разработка, тестирование, инфраструктура, коммуникация и внешние зависимости.
3. Соберите версии. Дайте участникам несколько минут записать идеи самостоятельно. Затем объедините дубли, не удаляя неудобные гипотезы.
4. Уточните цепочки. Для общих формулировок задавайте «почему?». Остановитесь там, где нужно проверить предположение, а не продолжайте выдумывать ответы ради числа пять.
5. Выберите проверки. Оцените возможное влияние, имеющиеся свидетельства и стоимость проверки. Голосование помогает расставить приоритеты, но не доказывает причинность.
6. Составьте план. Для каждой выбранной версии укажите данные, ответственного, срок и критерий вывода. Вернитесь к схеме после проверки.

Удобно помечать карточки словами «наблюдение», «гипотеза», «проверено». Цвет можно использовать дополнительно, но смысл должен читаться и без него. Для версии «заявки теряются» запросите конкретные примеры и журнал событий; для «клиентам дорого» — записи отказов и сравнение сопоставимых предложений.

Пример 1: падение продаж

Ниже учебная ситуация, а не результаты клиента Эсборд. Продажи компании снизились на 18% за сентябрь. Сначала нужно разделить две возможности: пришло меньше подходящих заявок или прежнее число заявок хуже превращается в оплаты. Без этого команда может обсуждать совершенно разные проблемы под одним заголовком.

На ветке «Люди» появляется отсутствие наставника у новых менеджеров. На «Процессах» — заявки, которые ждут ответа до следующего дня. В «Материалах» — старые цены в презентации. На ветке инструментов — пропущенные уведомления CRM, в измерениях — разные определения целевой заявки, в среде — сезонный спад спроса.

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

План проверки может выглядеть так: аналитик до четверга готовит выборку за два месяца; руководитель продаж проверяет десять спорных карточек; через неделю команда сравнивает сопоставимые группы. Условия сравнения записывают до эксперимента, чтобы потом не выбирать удобную метрику задним числом.

Пример 2: срыв сроков релиза

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

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

Пример 3: жалобы клиентов в поддержке

Фраза «клиенты недовольны» слишком широка. Сузьте её до «выросла доля повторных обращений по настройке доступа». Возможные ветви: непонятная инструкция, разница ролей, устаревший ответ оператора, незаметное сообщение об ошибке, несогласованные обещания при продаже.

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

Как провести сессию на онлайн-доске

Пригласите людей, которые знают разные участки процесса. Ведущий следит за вопросом и временем, владелец проблемы уточняет границы, участники предлагают наблюдения, один человек фиксирует договорённости. Руководитель тоже записывает версии, но не объявляет правильный ответ в начале.

На встречу можно выделить 50 минут: 5 на проблему, 10 на самостоятельный сбор, 15 на группировку и уточнение, 10 на выбор проверок и 10 на план. Это рабочая заготовка, а не универсальный норматив. Для большой темы разумнее провести две короткие встречи, чем обсуждать десятки ветвей без данных.

На доске для мозгового штурма удобно заранее разместить проблему, ветви и область действий. Дайте каждому возможность высказаться письменно до общего обсуждения. Если голосование недоступно в вашем тарифе, приоритеты можно отметить вручную; проверка гипотез всё равно остаётся отдельным шагом.

Частые ошибки

• Искать виноватого. «Невнимательный сотрудник» замените описанием наблюдаемого действия и условий, в которых оно произошло.
• Смешивать проблемы. Падение выручки, рост возвратов и долгий ответ поддержки могут требовать разных схем.
• Считать мнение фактом. Рядом с версией записывайте источник или вопрос, на который пока нет ответа.
• Останавливаться на схеме. Без владельца проверки и срока даже красивая диаграмма не меняет работу.
• Искать единственную причину. Результат может возникать из сочетания факторов; не исключайте их взаимодействие.

Что делать после разбора

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

Сохраните исходную версию схемы и рядом — решения после проверки. Через две недели сравните метрику с исходной точкой, учитывая изменения условий. Если улучшения нет, вернитесь к гипотезам: это нормальная часть исследования, а не повод объявлять сессию провалом.

О методе и категориях: материал American Society for Quality. Примеры и сценарий встречи в этой статье — учебные.

Как оформить результат проверки

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

Результат может быть положительным, отрицательным или неопределённым. В последнем случае объясните, чего не хватает: малого числа наблюдений, доступа к журналам или сопоставимого периода. Не отмечайте причину как подтверждённую только потому, что опровергнуть её не получилось. Если данные противоречивы, сохраните обе версии и выберите следующую проверку.

Отдельно договоритесь, кто может изменить процесс после проверки. Аналитик способен показать задержку, но не всегда имеет полномочия изменить график дежурств. Владелец действия должен понимать ограничения и получить согласие тех, чья работа изменится. Иначе команда найдёт убедительное объяснение, но не сможет повлиять на результат.

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

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

Вопросы и ответы

Что показывает диаграмма Исикавы?

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

Почему диаграмму называют «рыбья кость»?

Проблема напоминает голову рыбы, главная линия — позвоночник, а ветви причин — кости.

Обязательно ли использовать 6M?

Нет. Можно выбрать категории, соответствующие процессу, и заранее объяснить их команде.

Чем Исикава отличается от «5 почему»?

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