Как построить диаграмму Исикавы по записи разбора проблемы
От записи встречи к диаграмме Исикавы: формулировка проблемы, группы причин, ветви, учебный пример и план проверки гипотез.
Выберите одну проблему для головы диаграммы
Диаграмма Исикавы, или «рыбья кость», помогает разложить возможные причины проблемы по группам. В голове схемы указывают исследуемый результат, вдоль центральной линии размещают основные ветви, а возле них — причины и уточнения. Подписи должны быть короткими, чтобы связи можно было прочитать.
Для разбора записи сначала определите границы: какой процесс, какой период и какое наблюдаемое отклонение обсуждалось. «Поддержка работает плохо» слишком расплывчато. «В учебной выборке обращения возвращались на уточнение из-за недостающих данных» задаёт предмет поиска. Если участники одновременно обсуждали задержки, повторные обращения и оценку клиентов, выберите один результат или сделайте отдельные схемы.
Когда нужна последовательность событий и меры после сбоя, используйте шаблон постмортема по записи встречи. Диаграмма причин дополняет такой разбор: она показывает группы возможных объяснений одного результата. Не превращайте хронологию в причинную цепь только потому, что событие произошло раньше другого.
Запишите рядом с проблемой, что уже известно и чего не хватает. Например, в разговоре прозвучало «много возвратов», но количество никто не назвал. Это повод запросить данные, а не добавить в заголовок выдуманный процент. До уточнения отмечайте формулировку как предварительную.
Соберите из расшифровки карточки оснований
Получите текст записи в Транскрибаторе и сохраните аудио как источник проверки. Важные реплики сверяйте на слух: пропущенное «не», неверное число или спутанный автор могут изменить смысл предполагаемой причины. Не обещайте, что сервис сам установит причины или построит эту диаграмму.
Для каждой содержательной реплики заведите карточку: время, автор или код роли, точная цитата, краткое объяснение и статус. Отделяйте наблюдение «в форме нет обязательного поля» от гипотезы «поэтому запросы возвращаются». Первое можно проверить в форме, второе — сопоставить с историей обращений.
Слова участника являются фактом его высказывания, но не автоматическим подтверждением описанного события. Фразу «кажется, уведомление иногда не приходит» сохраните с оговоркой. Пересказ «уведомления не приходят» убирает степень уверенности и создаёт ложное основание для ветви.
Не вырезайте опровержения и исключения. Если позже другой участник уточнил, что уведомление пришло после смены статуса, свяжите обе реплики в карточке. Повтор одной мысли несколькими людьми не равен нескольким независимым доказательствам. Сохраните, на какой случай каждый из них ссылался.
Выберите понятные группы и нарисуйте ветви
Проведите центральную линию к блоку с проблемой и добавьте наклонные ветви групп причин. В традиционной схеме часто используют категории 6M; названия можно адаптировать к процессу. Для разбора обращений удобнее начать с «Входные данные», «Процесс», «Инструменты» и «Измерение». Это предложенная рабочая группировка, а не обязательный стандарт из четырёх ветвей.
Короткую гипотезу разместите возле подходящей ветви. Уточнение причинного механизма добавьте как подветвь, а источник оставьте в сопровождающей таблице. Например: «неполный запрос» → «непонятно, какие сведения нужны». Если связь пока лишь предположение команды, обозначьте её именно так. Не подменяйте механизм обвинением конкретного человека.
Одна идея может затрагивать несколько групп. Выберите основное место и поставьте ссылку на карточку в другом, если это помогает читать схему. Не считайте копии одной гипотезы разными причинами при выборе приоритетов. Участникам должно быть понятно, что это одна проверяемая мысль.
Пустая ветвь означает, что группа пока не дала объяснений, а не что факторов в ней точно нет. Вернитесь к записи и сформулируйте вопрос, который поможет проверить пробел. Для обработки жалоб по нескольким обращениям полезна таблица причин по записям обращений: она помогает собрать случаи, на которых затем проверяют ветви.
Превратите гипотезы в задания на проверку
Под каждой выбранной причиной сформулируйте ожидаемое наблюдение. Если гипотеза — отсутствие подсказки в форме, проверка должна показать, какие сведения пропущены и встречается ли это в обращениях с возвратом. Задание «улучшить форму» сразу переходит к решению и не проверяет объяснение.
Определите источник: запись подтверждает слова участников, журнал обращений — последовательность обработки, снимок формы — наличие полей. Укажите период и границы выборки. Если нужных данных нет, запишите способ их получения и человека, который может это сделать. Не назначайте реальных ответственных заочно: в рабочем процессе согласуйте поручение.
Добавьте условие, при котором гипотезу придётся пересмотреть. Например, нужное поле заполнено, но запрос всё равно вернулся по другой причине. Такое исключение не нужно прятать. Оно помогает уточнить механизм или разделить одну широкую ветвь на несколько разных ситуаций.
Выбирайте порядок проверки по влиянию на проблему, доступности данных и стоимости ошибки. Количество реплик в записи не является готовым рейтингом причин: заметная тема могла занять время из-за спора. Сохраните обоснование приоритета отдельно от числа упоминаний.
Зафиксируйте версию и вернитесь к результатам
Сохраните диаграмму вместе с таблицей карточек, датой обсуждения и версией расшифровки. В самой схеме можно оставить короткие коды П1, П2, П3; в таблице эти коды должны вести к цитате, времени и проверке. Без этой связи красивую ветвь трудно подтвердить или исправить.
После проверки изменяйте статусы: «не проверено», «есть подтверждающие данные», «есть противоречие», «отклонено» или «нужно уточнить». Формулировка статуса должна отражать объём проверки. Один найденный случай не доказывает, что причина объясняет весь период.
Если новая запись меняет вывод, сохраните прежнюю версию и причину изменения. В итоговом документе отличайте схему гипотез на момент встречи от обновлённого результата проверки. Не переписывайте первоначальную цитату так, будто участник заранее знал последующий вывод.
Готовый результат — читаемая схема одной проблемы, основания для каждой существенной ветви и конкретный план получения недостающих данных. Дальнейшие меры обсуждайте после проверки или прямо обозначайте как пробный шаг с ещё неизвестным эффектом. Диаграмма не даёт основания обещать, что выбранное действие устранит проблему.
Четыре ветви — четыре вопроса, а не четыре доказанные причины
Учебный пример полностью вымышленный: команда разбирает возвраты обращений на уточнение. В записи звучат четыре объяснения. Схема ниже сохраняет их как гипотезы; приведённые времена служат только примером привязки к разговору.
| Код и ветвь | Основание в учебной записи | Гипотеза и проверка |
|---|---|---|
| П1 — входные данные | 04:10: «В запросе не было номера заказа» | Неполные данные ведут к возврату; проверить поля и причины возврата |
| П2 — процесс | 09:35: «После передачи никто не уточнил владельца» | Передача оставляет запрос без исполнителя; сверить историю статусов |
| П3 — инструменты | 13:20: «Кажется, уведомление пришло поздно» | Задержка уведомления мешает ответу; сравнить время событий |
| П4 — измерение | 18:05: «Повторные обращения считаются новыми» | Отчёт скрывает возвраты; проверить правило подсчёта |
После встречи аналитик проверяет П1 по данным формы и истории обращений. Даже если неполные данные встречаются в отдельных случаях, остальные ветви остаются открытыми до своих проверок. В отчёт не переносится вывод «все возвраты вызваны формой».
Карточка диаграммы причин по записи
Проблема / наблюдаемое отклонение: Процесс / период / границы: Что подтверждено данными: Чего пока не знаем: Запись / версия расшифровки: Группы ветвей: Код причины / короткая гипотеза: Цитата / автор / время: Оговорки и противоречащие реплики: Предполагаемый механизм: Источник и способ проверки: Ожидаемое наблюдение: Что опровергнет или ограничит гипотезу: Проверяющий / согласованный срок: Результат / статус / дата: Версия схемы и причина изменения:
Частые вопросы
Нужно обязательно использовать шесть ветвей?
Категории должны помогать разбирать выбранный процесс. Можно адаптировать названия и число групп, сохраняя понятную структуру причин и уточнений.
Можно строить схему только по расшифровке?
Можно подготовить перечень гипотез. Важные реплики проверяют по аудио, а причинные объяснения — по подходящим данным о процессе.
Фраза участника доказывает причину?
Она подтверждает, что такое объяснение прозвучало. Для вывода о причине нужно проверить описанное событие и связь с исследуемой проблемой.
Как поступить с одной причиной в двух группах?
Сохраните один код гипотезы и поясните связь с обеими группами. Не превращайте повторное размещение в два независимых основания.
Когда диаграмма готова?
Когда у существенных ветвей есть понятные основания, границы выводов и способ проверки. Схема гипотез может быть готова к обсуждению раньше, чем закончен поиск причин.