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

Эта статья — продолжение моего разбора реального аудита Service Desk на основе выгрузки из Jira и интервью с командой поддержки.

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

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

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

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

Экран был перегружен: показатели, цифры и таблицы конкурировали за внимание, и не сразу было понятно, что к чему относится. Но один элемент выделялся хорошо — крупная оценка качества поддержки.

4,5 из 5.

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

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

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

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

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

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

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

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

Второй отчёт. А где мои 19 тысяч?

Следующий отчёт показывал распределение задач по статусам и возрасту.

Стандартный отчёт Jira честно показывал всё, что умел.

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

Но такого отчёта не было.

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

Вот здесь разница между данными и полезной информацией стала особенно наглядной.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из эксплуатации у меня осталась простая привычка: любой экран должен подсказывать следующее действие. Какое решение я приму после того, как посмотрю на него? Если никакого — отчёт, скорее всего, существует ради самого отчёта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21 962 маршрутизации. Медианное время маршрутизации — около четырёх минут.

Кто способен решить обращение за четыре минуты?