Метод 5 почему: как разобрать повторяющуюся проблему в работе команды

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

Что даёт метод 5 почему

Метод 5 почему помогает последовательно разбирать причины конкретного сбоя. Команда записывает проблему, спрашивает, почему она возникла, затем исследует причину предыдущего ответа. Получается цепочка объяснений, которую нужно проверить по событиям и устройству процесса.

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

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

После встречи должно быть понятно, какое объяснение команда проверила, что собирается изменить и по каким наблюдениям решит, помогла ли мера. Пять заполненных строк сами по себе ничего не исправляют.

Возьмите один сбой и сохраните его следы

Начните с нарушения понятного правила: сколько ожидали, что получили и где это произошло. «Поддержка плохо работает» для разбора слишком широко. «Заявка A-17 получила первый ответ через 52 минуты при обещании ответить за 20 минут» уже задаёт границы.

В примере поддержка меняет смену в 18:00. За десять рабочих дней через общий канал поступило 40 обычных заявок в последние десять минут перед сменой. Четыре получили первый ответ позже обещанных 20 минут. Срочные обращения и заявки, требующие согласования с другим отделом, в эту группу не входили.

Среди своевременных обращений 28 назначили ещё до передачи смены. Другие восемь вечерний сотрудник нашёл, вручную открыв общую очередь. Четыре задержанные заявки остались неназначенными, а сотрудник следующей смены работал только в стандартном списке. Эти пути восстановлены по учебным журналам и рассказам очевидцев; для A-17 порядок событий разобран подробнее.

Команда выбрала A-17: сообщение пришло в 17:58, исполнитель появился в 18:41, ответ отправлен в 18:50. Клиент ждал 52 минуты, включая 43 минуты без назначения. Обещанный срок истёк в 18:18.

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

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

Оптимизация клиентского опыта: стратегии и методы

Заполненный пример: от задержки к проверяемой причине

На встречу пришли участники обеих смен и администратор системы. Ведущий сверял ответы с историей A-17 и возвращал разговор к событию всякий раз, когда вместо сведений появлялись оценки людей. У каждого перехода команда искала ожидаемый след: что обнаружится, если объяснение верно?

Почему клиент не получил ответ вовремя?

Рабочая версия: обращение долго не попадало в обработку, поскольку оставалось без назначенного исполнителя. Журнал подтверждает 43 минуты без назначения. После назначения до ответа прошло ещё девять минут. Так разделили два отрезка ожидания.

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

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

Почему заявка оставалась неназначенной после передачи смены?

В стандартном рабочем списке вечерней смены показывались только назначенные обращения. A-17 оставалась в общей очереди без исполнителя. Сотрудник вечерней смены сказал: «Я открыл привычный список и не увидел новых задач». Это учебная реплика очевидца, отдельно от технического факта.

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

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

Отдельная ветвь: почему не помогло уведомление?

Уведомление могло привести сотрудника к заявке в обход списка. Это другая ветвь обнаружения обращения: она не объясняет настройку фильтра. Команда сохранила обе ветви к общему результату «первый ответ отправлен позже срока».

Журнал доставки показал адресата уведомления: сотрудник заканчивающей смены. Вечерняя смена это уведомление не получала. Настройка маршрута совпала с журналом. Сотрудник утренней смены сообщил, что после завершения работы рассчитывал на просмотр общей очереди коллегами.

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

Почему такие настройки сохранились?

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

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

Слева показано, как заявка появляется при включении неназначенных обращений в список. Справа виден адресат из журнала доставки: прежняя смена. Это схематичный учебный пример, не интерфейс WebAsk. Вклад двух барьеров в полную задержку пока не установлен. История появления настроек неизвестна.

Проверьте другие объяснения

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

Для четырёх задержек сравнили час перед передачей и первые полчаса после неё с передачами без задержек. В учебной выборке состав смены и тип обращений совпадали. Перед сбоями за час приходило от 11 до 13 заявок; на сопоставимых передачах без сбоя встречались 12–16. Пока A-17 ожидала в общей очереди, в журнале вечернего сотрудника были периоды без зарегистрированных действий по назначенным заявкам.

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

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

Это проверка видимости, а не времени ответа. Вклад перегрузки в задержку A-17 остался неизвестным: сравнения небольших групп для его исключения недостаточно. Команда получила подтверждённый барьер и основание испытать изменение списка, но пока не установила полную причину 52 минут ожидания.

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

Выберите одно изменение и условия проверки

Администратор включил неназначенные обращения в стандартный список вечерней смены. Руководитель поддержки взял на себя проверку результата. Маршрут уведомлений, штат и автоматическое назначение не меняли. Так проверяется действие одного изменения; одновременная переделка всего процесса скрыла бы его вклад.

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

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

В учебном плане условие принятия правки такое: минимум 40 подходящих заявок за десять передач или дольше, ни одного превышения срока в этой группе и подтверждённая видимость неназначенных обращений. Защитный показатель для остальной очереди: доля первых ответов позже 20 минут не выше исходной. Это правило команды для примера, универсального порога у метода нет.

После изменения набралось ещё 40 подходящих заявок. Превышений срока в этой группе не зарегистрировали: до правки было 4 из 40, после стало 0 из 40. В остальной очереди до правки позже срока ответили на 12 из 240 обращений, после на 10 из 240. Защитный показатель не вырос. На схеме одна клетка соответствует одной заявке. Янтарным отмечены первые ответы позже 20 минут. Клетки сгруппированы для подсчёта, порядок поступления не показан.

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

Команда назначила следующую проверку через месяц и отдельный разбор при первом повторе. В протоколе сохранили старую настройку и критерии наблюдения. Иначе через месяц никто не вспомнит, какое именно объяснение проверяли.

Протокол рабочего совещания: образец, решения, ответственные и сроки

Шаблон протокола для своего разбора

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

Карточка события

Сбой: что произошло, где и когда; какое правило нарушено?
Граница: какие случаи включены и исключены; почему?
Хронология: события, время и ссылки на записи.

Повторяемый блок причинного перехода

Переход: какое условие, по нашей версии, вызвало предыдущий результат?
Механизм: как оно действует?
Ожидаемый след: что увидим, если версия верна?
Источники: записи и отдельные рассказы очевидцев.
Альтернатива: другое объяснение того же результата.
Различающая проверка: какое наблюдение отделит версии?
Результат: что получили, чего проверить не удалось?
Граница вывода: что поддержано, что отклонено, что неизвестно?

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

Изменение и наблюдение

Мера: что меняем и кто это сделает?
Наблюдение: какие обращения считаем, сколько их всего, срок и критерий принятия?
Защита клиента: кто подхватит сбой, как запишем вмешательство?
Возврат к разбору: кто и когда проверит результат; какое событие откроет разбор раньше?

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

Как собрать рассказы сотрудников в WebAsk

Перед встречей удобно собрать отдельные описания события от участников. В WebAsk для этого достаточно полей ввода и выбора одного варианта. Эти типы перечислены на странице возможностей платформы. Причинный разбор команда ведёт в своём рабочем документе.

Первое поле: «Код события или заявки». Затем выбор роли в эпизоде: принимал обращение, передавал смену, начал обработку или наблюдал со стороны. После него открытые вопросы: «Что вы видели лично?», «Какое действие сделали и когда?», «Где можно проверить эту запись?», «Чего вы не знаете об этом эпизоде?» Оставьте код обязательным, чтобы ответы разных людей можно было сопоставить по одному событию.

Одна отправка формы относится к одному событию. Попросите не вставлять переписку с персональными сведениями клиента; ссылки на внутренние журналы должны оставаться доступны только уполномоченным сотрудникам. Роль в событии помогает понять точку наблюдения, она не назначает виновного.

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

Ответы помогут подготовить встречу: найти очевидцев и записи, которые стоит сверить. Анкета не устанавливает первопричину; журналы назначения и фильтры чужой системы проверяет команда с администратором. Формулировки, заранее подсказывающие версию, разобраны в статье про наводящий вопрос.

Когда пяти почему недостаточно

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

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

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

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

Lean Enterprise Institute включает в решение конкретное описание проблемы, контрмеры и дальнейшие проверки. Наблюдайте тот же сбой по заранее выбранным условиям.

Частые вопросы

Обязательно задавать почему ровно пять раз?

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

Как сформулировать проблему для разбора?

Укажите событие, время, ожидаемый результат и отклонение. Вместо «поддержка медленная» запишите конкретную заявку и превышенный срок ответа.

Достаточно ли согласия сотрудников с причиной?

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

Что делать, если причин несколько?

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

Можно ли остановиться на отсутствии исполнителя?

Это промежуточное состояние. Проверьте, почему оно возникло и как связано с задержкой. Если сведений нет, зафиксируйте неизвестное и задачу проверки.

Доказывает ли улучшение, что причина найдена?

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

Можно ли провести весь разбор в анкете?

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