Портал №1 по управлению цифровыми
и информационными технологиями

Не все First Call Resolutions (FCR) одинаково полезны

sigmaИногда очень полезно возвращаться к истокам. Свежий взгляд на одну из часто используемых метрик процесса управления инцидентами в разделе блогов компании SysAid опубликовал Грег Сэнкер (Greg Sanker).

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

Класс!

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

Грег считает, что главная ценность процесса управления – это знания которые мы получем о действующей инфраструктуре. Эти знания должны использоваться в первую очередь процессами непрерывного совершествования услуг, чтобы делать их лучше. Высокий показатель FCR говорит о том, что мы мало изменяем имеющуюся инфраструктуру, но готовы быстро разрешать возникающие инциденты снова и снова. Мы не создаем знаний которые мы можем использовать и соответственно не создаем ценности.

Это спорно, но рациональное зерно в этом есть. Смотреть на услуги глазами пользователей полезно всегда. К разным услугам наши потребители предъявляют разные эксплуатационные требования. Для одних услуг подход максимально быстрого восстановления – супер принципиален, а для других, скоростью разрешения можно пожертвовать, если это позволит уменьшить частоту обращений или сбоев в инфраструктуре.

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

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

Нужен ли вашей первой линии высокий показатель FCR? Почему? Для каких услуг?

«VAP: Построение системы KPI для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

Комментариев: 2

  • Каждая метрика имеет свое применение. Нет метрик безусловно полезных или безусловно вредных. Для L1 FCR, как правило, полезна: при прочих равных, чем выше значение FCR, тем лучше работает L1. Для высшего ИТ-руководства, которое отвечает за проактивность ИТ-подразделения, FCR не является адекватным KPI. В этом с автором трудно спорить.

    Но никакого парадокса я здесь не вижу. Аналогичная ситуация может быть предложена почти для любой метрики. Это же "с чем сравнивать". Например, своевременность решения инцидентов – тоже не абсолютная метрика, потому что своевременность на уровне 99%, вероятнее всего, просто означает заниженные нормативы на решение. Для многих организаций решение вовремя 99% инцидентов при нормативе 2 дня хуже, чем решение вовремя 90% инцидентов при нормативе 4 часа.

    "Ну и так далее".

  • Иван Круглый

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

    Собственно FCR (без указания рядом общего кол-ва обращений) не указывает напрямую на количество сбоев, а скорее демонстрирует компетентность поддержки.


Добавить комментарий для Иван КруглыйОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM