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

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

Сформулируйте наблюдаемую проблему

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

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

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

Нарисуйте основу и выберите ветви

Запишите проблему справа, проведите к ней горизонтальную линию, затем добавьте наклонные ветви с названиями групп. Для рабочей встречи можно выбрать «Задание», «Информация», «Инструменты» и «Порядок работы». Это редакционный пример, а не обязательный набор категорий.

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

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

Добавьте конкретные возможные причины

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

Можно добавить ответвление, уточняющее предполагаемую связь. Но вопрос «почему?» не обязывает придумывать объяснение при нехватке сведений. Запись «неизвестно, нужно уточнить» сохраняет качество анализа.

Выберите, чем проверить версии

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

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

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

Завершите схему следующим действием

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

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

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