Третья статья из цикла «Аналитик в чужом процессе»
Во второй статье я остановился на простой мысли — снимок в моменте обманывает. Цифра сама по себе почти ничего не говорит. Важно, как она меняется — и что стоит за этим изменением.
Логичный следующий шаг — посмотреть на метрики в динамике.
Откуда взялась идея
После истории с дашбордами у меня остался вопрос — если процесс действительно устроен так, как я его понял, это должно проявляться не только в разовых наблюдениях, но и во времени.
Я начал с того, что уже знал — первая линия. 21 962 маршрутизации. Медианное время — около четырёх минут. Это не «решённые заявки». Это решения другого типа — куда отправить дальше.
Фактически первая линия здесь работает как диспетчер: не чинит, а определяет, кто будет чинить. Если смотреть на процесс через эту призму, появляется другая метрика — насколько часто первая линия попадает «с первого раза».
По данным — около 20% заявок возвращаются обратно. Каждая пятая маршрутизация оказывается неточной.
Это уже не просто цифра — это характеристика процесса.
Попытка увидеть эффект в данных
У меня в голове было известное изменение — один из подрядчиков перестал обслуживать часть систем. Если это повлияло на процесс, это должно быть видно в метриках.
Я выбрал для проверки «пинг-понг» между группами. Если проблема была в границах между командами, после изменения она должна была измениться. График показал идеальную картину — пинг-понг падает почти до нуля в один месяц.
Первая проверка
Всё оказалось точно — часть специалистов перевели внутрь, отказавшись от подрядчика. Функция осталась. Люди частично остались. Помялось только имя группы.
Где именно сломалась метрика
Мой расчёт опирался на названия групп. Скрипт сделал всё правильно. Он посчитал ровно то, что я ему задал. Проблема была в постановке задачи.
Я измерял не процесс, а его представление в структуре. Как только структура изменилась — метрика перестала соответствовать реальности.
Вторая проверка
Я пересчитал метрику, объединив группы по функции и исключив те, где возврат — часть процесса. Картина изменилась:
Пинг-понг никуда не исчез. Он остался примерно на том же уровне — просто «переехал» под другим именем. То, что выглядело как решённая проблема, оказалось артефактом реорганизации.
Надо отметить, что позже я узнал от представителя бизнеса, что польза от реорганизации всё же была — финансовая.
Неожиданное продолжение
На этом месте можно было остановиться. Но дальше всплыло ещё одно наблюдение. Я вернулся к метрике качества маршрутизации — и увидел странный разъезд. До середины 2024 года две линии шли примерно вместе. После — начали расходиться:
доля «успешных маршрутизаций» растёт
доля задач без возврата — падает.
На первый взгляд — противоречие. Если маршрутизация становится лучше, возвратов должно становиться меньше.
Здесь — наоборот.
Что на самом деле произошло
Разъезд оказался не деградацией процесса, а изменением состава очереди. В данных появились две группы с особым поведением. Первая — «ИБ». До весны 2024 на неё уходило меньше 1% маршрутизаций. С лета — уже 6–14%. У неё очень высокий возврат — 70–95% задач возвращаются на первую линию. Но при этом dispatch_failure выставляется только в 25–45% случаев.
Вторая — «Общие сервисы». Её вообще не было до осени 2024. Потом она быстро набрала объём — до 25–30% потока — с тем же паттерном: возврат есть, failure нет.
Если убрать эти две группы из расчёта, разница между метриками почти исчезает.
Что это означает
Стало видно, что я измеряю сразу два разных явления одной парой показателей.
dispatch_failure отвечает на вопрос «ошибся ли маршрутизатор»
возврат на первую линию — «закончился ли процесс за один шаг» Для согласующих или промежуточных групп вроде ИБ возврат — нормальная часть процесса.
Это не ошибка. Это этап. Но метрика FCR трактует это как неуспех.
Теперь понятно, что проблема не в данных, а в том, что разные типы поведения свёрнуты в одну цифру.
Про тренды (и почему они тоже обманывают)
После этого я снова посмотрел на динамику качества маршрутизации. Рост есть — примерно с 70–75% до 85–89%. Но если взять длинный период, видно, что рост начался раньше и продолжается после реорганизации. В точке изменения нет ни перелома, ни ускорения.
Соблазн связать улучшение с конкретным событием остаётся — оно рядом по времени. Но «рядом» — не значит «из-за».
Как я теперь смотрю на графики
Перед тем как делать выводы, я проверяю:
не изменилась ли структура под метрикой
не изменился ли состав потока
есть ли реальный перелом в тренде
Если хотя бы один пункт не проходит — вывод откладывается.
Что осталось неочевидным
После всех проверок картина получилась странной:
пинг-понг — стабильный
качество маршрутизации — растёт
часть метрик конфликтует из-за структуры процесса
По отдельности — всё понятно, вместе — нет.
Вопрос, который остался
Возникает естественная мысль: если смотреть не на одну метрику, а на несколько одновременно — появится ли закономерность?
Например:
пинг-понг
точность маршрутизации
время решения
Сейчас они живут как будто отдельно. Если смотреть на них как на систему — возможно, там есть зависимость, которая не видна по отдельности.
Пока это не оформилось в метод. Только ощущение, что следующая точка роста именно здесь.
Вопрос к тем, кто уже пробовал глубже
Если у вас есть опыт смотреть на процесс не через одну метрику, а как на систему показателей — интересно, как вы к этому подходили? Не корреляцию «на глаз», а воспроизводимый способ:
увидеть связь
проверить её
использовать для решений
Итог
Динамика даёт больше, чем статический срез. Но сама по себе она не защищает от ошибок. Если не учитывать структуру процесса и её изменения, график легко превращается в иллюзию. И чем он убедительнее — тем сложнее заметить, что он врёт.
Во второй статье речь была о том, что метрика должна вести к действию. Здесь добавляется ещё одно требование — она должна оставаться корректной, когда система меняется. Иначе это уже не инструмент управления, а просто более красивая форма заблуждения.
Что дальше
В следующей части — про то, что происходит, когда ты пытаешься что-то изменить на основе этих выводов. Потому что понять — это только половина работы.
