Диаграмма Исикавы: как собрать и проверить возможные причины проблемы

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

Сначала задай границы проблемы

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

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

В описании укажи:

• Объект: какие заявки рассматриваешь.
• Отклонение: какой срок нарушен.
• Границы измерения: от поступления заявки до завершения работы.
• Период и масштаб: условный месяц, 18 просрочек из 60 заявок.

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

Не включай причину в формулировку проблемы. Запись «заявки просрочены из-за невнимательности» заранее сужает разбор и подменяет проверку обвинением.

Как собрать ветви диаграммы

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

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

1. Собери версии участников без выбора победителя.
2. Уточни, как каждая версия может привести к отклонению.
3. Замени общие оценки наблюдаемыми условиями.
4. Объедини дубли, сохранив связи между ветвями.
5. Отдели известные факты от предположений.

Вместо «человеческий фактор» запиши «на время отсутствия согласующего не назначен заместитель». Вместо «неудобная система» - «исполнитель не получает уведомление о назначении». Такие условия можно проверить по событиям и документам.

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

Хочешь навести порядок в задачах и процессах команды? Начни с одного маршрута в Legend BMS. Зарегистрироваться →

Пример диаграммы причин задержек

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

• Люди: у исполнителя нет нужного доступа; для отсутствующего согласующего не назначен заместитель.
• Способ работы: заявки передают пакетами один раз в день; критерий готовности результата не определён.
• Входные данные: не хватает сведений; исходный файл содержит противоречивые требования.
• Системы: уведомление о назначении не доходит; статус обновляется с задержкой.
• Условия: срочные обращения меняют очерёдность; внешнее согласование доступно в ограниченные часы.
• Измерение: начало срока фиксируют по-разному; завершённую работу отмечают на следующий день.

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

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

Как составить план проверки гипотез

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

Для каждой версии заполни карточку. Например:

• Гипотеза: неполные входные данные увеличивают вероятность просрочки.
• Ожидаемый признак: до завершения обработки возникает запрос недостающих сведений и ожидание ответа.
• Данные: состав заявки при поступлении, время запроса и ответа, время завершения, тип и сложность заявки.
• Проверка: сравнить полные и неполные заявки внутри сопоставимых категорий, затем испытать проверку комплектности на одном типе заявок.
• Критерий решения: версия получает предварительную поддержку, если различие сохраняется внутри сопоставимых групп и история показывает предполагаемый механизм. Если различие исчезает, пересмотри объяснение; если данных мало, оставь вывод открытым.
• Ответственный и срок: руководитель обработки собирает данные и возвращает вывод к заранее назначенной дате.

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

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

Расчёт на условных данных

Предположим, разбор тех же 60 заявок дал следующие результаты:

• Неполные данные: всего 20 заявок, просрочено 12, доля просрочек 60%.
• Полные данные: всего 40 заявок, просрочено 6, доля просрочек 15%.
• Вся выборка: всего 60 заявок, просрочено 18, доля просрочек 30%.

Формула: доля просрочек = число просроченных заявок / число всех заявок в соответствующей группе × 100%.

Для неполных заявок: 12 / 20 × 100% = 60%. Для полных: 6 / 40 × 100% = 15%. Для всей выборки: 18 / 60 × 100% = 30%. Разница между группами: 60% - 15% = 45 процентных пунктов.

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

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

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

Как зафиксировать вывод и следующий шаг

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

Не выбирай причину по должности участника или числу записей на ветви. Формулировку «усилить контроль» замени действием, которое меняет проверяемое условие: например, проверкой состава заявки перед передачей исполнителю.

Если на диаграмме собраны причины задержек, но непонятно, кто и как их проверяет, перенеси план в конструктор бизнес-процессов Legend BMS: задай шаги сбора данных, роли участников и условия перехода к разбору результата. Настроенные поля и переходы контролируют введённый результат, но не гарантируют качество самой проверки. Зарегистрируйся и создай процесс проверки одной гипотезы с первым шагом «Собрать исходные данные по заявкам».