Найти причину задержек

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

Строить цепочку, которую можно проверить

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

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

Очередь и пропускная способность

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

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

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

Считать там, где есть данные

Допустим, перенос данных занимает 8 минут на заявку, а таких заявок 30 в неделю. Получается 240 минут, или 4 часа работы. Это оценка занятости, которую потенциально можно сократить. Она не означает, что денежные расходы автоматически уменьшатся на стоимость четырёх часов: освободившееся время ещё нужно использовать, а инструмент — настроить и поддерживать.

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

Проверять необходимость действия

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

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

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

Собрать альтернативы

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

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

Проверить механизм

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

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

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

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