Вторая статья из цикла «Аналитик в чужом процессе»

Когда анализатор наконец перестал ошибаться, я решил проверить себя.

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

Я открыл первый дашборд.

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

Первый отчёт. 4,5 звезды

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

4,5 из 5.

Я остановился на этой цифре. Она казалась неправдоподобно хорошей для процесса, который я только что два дня разбирал вручную.

— Как считается? — спросил я.

— По звёздочкам. После закрытия заявки клиент может поставить оценку.

— Может или должен?

— Может. Добровольно.

Проблема здесь не в том, что цифра обязательно завышена. Проблема в том, что без данных о доле ответивших и анализа выборки 4,5 из 5 нельзя считать достоверной оценкой удовлетворённости всей клиентской базы. Довольные и недовольные клиенты оставляют оценки с разной вероятностью. Смещение есть — в какую сторону и насколько, неизвестно.

Но именно эта цифра занимала центральное место на главном экране как главный KPI качества поддержки.

Второй отчёт. 19 тысяч «проблемных» задач

Следующий экран показывал около 19 тысяч задач — кандидатов на проблемы.

Число было красным. Создавало ощущение системного кризиса.

Но я уже знал, откуда эта цифра. Это были результаты анализатора первой версии — до того, как я поговорил с командой и понял реальный процесс. 19 тысяч кандидатов на аномалии из 145 тысяч задач — 13% всей базы — выглядело тревожно.

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

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

Третий отчёт. Нарушения SLA

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

Когда я посмотрел на реальные задачи из очереди «Отложенные», картина оказалась иной. Там было почти 400 открытых задач в статусе ожидания. Большинство из них — не потому что команда забыла или не успела. А потому что задача зависла на этапе согласования со стороны бизнеса, ожидает ответа от клиента, или требует действия от другой команды.

Поддержка физически не могла продвинуть эти задачи самостоятельно. Но в отчёте по SLA они выглядели неотличимо от задач, где задержка действительно была на стороне ИТ.

Метрика отвечала на вопрос «сколько задач нарушило SLA». Но не отвечала на вопрос «по чьей причине». А именно второй вопрос нужен, чтобы принять какое-то решение.

Открытие, которого я не ожидал

В тот момент я неожиданно понял простую вещь.

Плохой дашборд опаснее отсутствия дашборда.

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

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

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

Три типа вопросов

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

Оказалось, что вопросы очень разные — по срочности и по природе.

Есть вопросы, которые руководитель задаёт каждое утро:

• Что требует внимания прямо сейчас?

• Где появились задачи без исполнителя?

• Где образовалась пробка?

Есть вопросы, которых достаточно задавать раз в неделю:

• Где начинает накапливаться проблема?

• Где время ожидания растёт от недели к неделе?

• Какие задачи движутся к нарушению срока и почему?

Есть вопросы, ответы на которые нужны раз в месяц:

• Куда движется процесс в целом?

• Есть ли улучшения за последние несколько недель?

• Какие категории задач растут непропорционально?

Это три совершенно разных инструмента с разной частотой использования. Один экран без явного разделения этих горизонтов почти неизбежно смешивает срочные сигналы, тенденции и стратегические показатели — и в итоге не отвечает ни на один из них по-настоящему.

Сначала решение, потом метрика

После этого я изменил подход к построению любого отчёта.

Первый вопрос теперь не «какие данные у нас есть». Первый вопрос — «какое решение руководитель должен принять с помощью этого отчёта».

Звучит просто. Но большинство метрик этот тест не проходят.

«Общее количество открытых задач» — не проходит. Если цифра выросла, непонятно, что делать. Это рост нагрузки или изменение настроек фильтрации?

«Количество задач в статусе “Отложен” дольше 30 дней» — проходит. Глядя на эту цифру, руководитель знает конкретное действие: зайти в каждую и выяснить, что именно ждёт и кто должен действовать.

Разница не в сложности вычисления. Разница в том, ведёт ли метрика к действию.

Шесть вместо двадцати

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

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

Получился такой набор:

• Живая очередь — что требует внимания прямо сейчас.

• Маршрутизация — куда и с какой скоростью движется поток заявок.

• Классификация — где задачи начинают застревать ещё до начала работы.

• Отложенные задачи — что давно ждёт решения и почему.

• Межсистемные процессы — где задачи “пинг-понгом” переходят между командами.

• SLA по причинам — какие нарушения зависят от поддержки, а какие вызваны ожиданием бизнеса или внешних систем.

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

Что изменилось

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

Настоящий дефицит был не в метриках. Он был в понимании того, какие решения эти метрики должны поддерживать.

Но самое неожиданное открытие ждало меня впереди.

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

Потом я увидел одну цифру.

21 962 маршрутизации.

И понял, что всё это время смотрел совсем не на ту профессию.