Год в helpdesk: первый отчёт по SLA и принтер в бухгалтерии

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

Сейчас за плечами больше года истории в системе. Решили наконец сесть и посмотреть, что там накопилось.

Что хотели померить

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

Второй вопрос - что вообще составляет основную нагрузку. Какие категории заявок едят больше всего времени? Где мы постоянно возвращаемся к одному и тому же?

Как строили отчёт

Данные выгрузили из helpdesk в CSV. Дальше - Excel, сводные таблицы, немного формул. Ничего сложного, OLAP здесь не понадобился - объём позволял работать напрямую.

Считали три основных показателя:

• Время первого ответа - от момента открытия тикета до первого комментария инженера. Не автоматического подтверждения, а живого человека.
• Время решения - от открытия до закрытия, раздельно по категориям и приоритетам.
• Повторяемость - тикеты с одинаковой темой или симптомом, сгруппированные руками.

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

Что получилось по SLA

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

По времени решения интереснее. В среднем по всем приоритетам - держимся. Но если смотреть по категориям, а не по приоритетам - всплывают аномалии. Заявки, связанные с подключением нового оборудования, в среднем закрываются втрое дольше, чем заявки на программное обеспечение. Логично: там часто надо ждать поставки или согласования с клиентом. Но в нашем SLA это не было отдельно учтено - одна категория «стандартный запрос», одно время решения.

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

Топ повторяющихся проблем

Вот тут всё стало интересно.

Десятка самых частых проблем выглядела примерно так, как мы и ожидали: проблемы с почтой, сброс паролей, подключение к принтерам, медленный интернет, «файл не открывается». Стандартный набор первой линии.

Но когда мы не просто посчитали категории, а посмотрели на конкретные инциденты - выяснилось, что около 30% всех тикетов за год сводятся к одной и той же ситуации. Принтер HP в бухгалтерии одного из клиентов. Зависает, не видит компьютер, ошибка offline, требует перезагрузки. Снова и снова.

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

Тридцать процентов. Один принтер.

Что с этим делать

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

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

Это классический случай, который в ITIL называют problem management - не реакция на инцидент, а работа с корневой причиной. Мы про ITIL v2 читаем, на конференциях слышим, некоторые коллеги уже сертифицируются по ISO 20000. Но одно дело - знать концепцию, другое - увидеть её необходимость в своих собственных данных.

Что изменим в процессе

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

• Разбить категории заявок детальнее - отделить инциденты с оборудованием от запросов на изменения, каждому дать свои целевые показатели.
• Добавить в шаблон тикета поле «повторная проблема» - чтобы инженер при открытии видел историю похожих заявок по этому клиенту и этому оборудованию.
• Ввести порог повторяемости: три тикета с одним симптомом за месяц - автоматически создаётся задача на расследование корневой причины.
• Считать отчёт ежемесячно, а не раз в год после накопления «достаточной» истории. Год - это слишком много; за три месяца принтер уже был бы виден.

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

Как выяснилось, иногда ходишь по кругу. Вокруг принтера.