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

“Здесь играем, здесь не играем …”

Для оценки качества работы первой линии часто используются такие метрики как: «Доля обращений, решённых на первой линии (First Line Resolution – FLR)» и «Доля обращений, решённых в течение первого контакта (First Contact Resolution – FCR)». Причина их появления довольно очевидна – стремление увеличить количество обращений, разрешаемых на первой линии. В свою очередь, это должно привести к снижению стоимости обработки обращений за счёт использования более дешёвых ресурсов первой линии и повышению удовлетворённости пользователей за счёт сокращения времени обработки обращений (нет эскалации – нет потерь времени на реакцию).

Применение этих метрик выглядит оправданным и легко реализуемым. В большинстве случаев расчёт предлагается производить по формуле (аналогичные формулы приведены в книге «ITSM. Руководство по измерению»):

  •  FLR=R/N (где R — количество обращений, решённых на первой линии поддержки, N — общее количество обращений, поступивших на первую линию за отчётный период);
  • FCR=C/N (где C — количество обращений, решённых в ходе первичного контакта с пользователем, N — общее количество обращений, поступивших в заданную группу за отчётный период).

Однако, использование этих показателей на практике оказывается не совсем тривиальной задачей.
Часто сталкиваются с двумя затруднениями:

  1. Излишняя задержка обращения на первой линии (излишнее удержание звонка при первом контакте) в попытке разрешить максимальное количество обращений;
  2. Определить N для формул, приведённых выше.

С первой сложностью более или менее понятно – вводим ограничение на время обработки обращения на первой линии (при первом контакте) или «противовесный» показатель типа «доля звонков, принятых без превышения времени ожидания абонента на линии», или «среднее (максимальное) количество абонентов в очереди входящих звонков» и дальше с этим можно жить. 

Со второй проблемой сложнее. Особенность в том, что далеко не все обращения возможно разрешить на первой линии. Часть заявок физически невозможно решить удалённо, часть нельзя выполнять из-за ограничения регламентов или политик, а часть в связи с отсутствием необходимого уровня доступа у сотрудников первой линии. В результате получается, что либо мы сознательно идём на искажение результатов, учитывая все обращения, и делаем данный показатель плохо применимым для оценки (существует фактор на который первая линия никак не может влиять), либо должны учитывать только те заявки, которые первая линия могла решить. И тут возникает вопрос: как это реализовать? 

В тех решениях, которые я встречал, применялась следующая схема (иногда с некоторыми, незначительными изменениями):

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

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

Более «красивое» решение – использование моделей инцидентов. В модели мы определяем, на какой линии должны решаться подобные инциденты, а дальше используем этот атрибут для фильтрации инцидентов при формировании отчётности.

В заключение хотелось бы спросить у вас, коллеги: используете ли вы подобные показатели, если да, как определяете общее количество обращений релевантных для подобной оценки?
 

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

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

  • Антон Герасимов

    Очень полезная информация, больше бы таких, спасибо!


Добавить комментарий

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM