Использует ли ваша команда технической поддержки широкий набор ИТ-метрик? Хотя они могут называться “портфелем”, по сути, это лишь различные метрики, используемые для оценки работы службы ИТ. Весьма вероятно, что вы уверены в том, что ваша команда использует сбалансированный набор таких метрик, однако стоит задуматься – правда ли это? Давайте рассмотрим различные типы показателей и проблемы, с которыми сталкиваются службы ИТ, используя неправильные метрики. Это поможет нам определить, насколько сбалансирован и эффективен ваш “портфель” метрик в службе технической поддержки.

Различные типы метрик

Существует множество способов дифференциации метрик, но какой бы метод ни использовался, важно понимать различия. Например, в руководстве ITIL 4 говорится, что “отсутствие определенного типа метрики в системе измерений может привести к тому, что некоторые характеристики объекта управления останутся неизмеренными”.

Практика управления ITIL 4 “Измерения и отчетность” подробно описывает четыре основных типа метрик:

• Метрики эффективности – показывают, как деятельность выполняет свое назначение и достигает цели (целей). В качестве примера можно привести службу технической поддержки – решение проблемы по первому контакту.
• Показатели эффективности – показывают, как организация использует ресурсы для выполнения деятельности и управления продуктами и услугами. Пример ИТ-службы – среднее время решения проблемы.
• Показатели производительности – показывают объем выполненной работы и полученный результат, или “пропускную способность”. В качестве примера для службы технической поддержки можно привести количество разрешенных заявок на одного агента.
• Показатели соответствия – представляют интерес для владельцев услуг и руководящих органов. В качестве примера можно привести процент выполнения целевых показателей соглашения об уровне обслуживания (SLA).

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

Работа с метриками скорости и производительности на примерах реальных команд на уникальном курсе “Kanban Flow Metrics: управление потоковым производством на основе данных”

• Самостоятельные онлайн-занятия в любом удобном месте
• Бесплатный демо-доступ
• Любое удобное время, доступ на 90 дней
• Авторский тренажёр Cleverics на основе собственного опыта и практики
• Настоящий тренажёр: всё время обучения отводится на практику и упражнения.
• На собственной образовательной ИТ-платформе

Отстающие и опережающие метрики

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

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

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

• Среднее время восстановления обслуживания (MTRS) – среднее время восстановления обслуживания после возникновения инцидента, отражающее эффективность процесса управления инцидентами и работы службы технической поддержки.
• Показатель удовлетворенности клиентов (CSAT) – измеряет удовлетворенность клиентов и конечных пользователей предоставляемыми услугами ИТ-поддержки.
• Процент выполнения SLA – данная метрика измеряет долю заявок, решенных в оговоренные сроки.
• Количество инцидентов – количество инцидентов, зарегистрированных за определенный период времени.

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

Возможно, вы до сих пор считаете, что портфель метрик вашей команды технической поддержки охватывает все необходимые показатели и позволяет эффективно управлять улучшениями. Однако стоит задать себе вопрос – действительно ли вы знаете, какие метрики являются опережающими, а какие отстающими? Важно проанализировать, как существующие метрики ИТ-службы отражают ее эффективность и позволяют выявить возможности улучшений по всем областям:

• Операции
• Услуги
• Опыт

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

Операционный характер традиционных показателей ИТ-службы

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

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

Кроме того, часто измерения производятся не в точке потребления конечным пользователем, а в точке поставки ИТ. Например, целевой показатель уровня обслуживания при обработке инцидентов может показать, что среднее время обработки соответствует SLA, но для конечного пользователя это может быть не так. Возможно, измерение является необъективным и “часы остановились” для ИТ, но не для пользователя. Также возможно, что проблема конечного пользователя не была решена, и в результате обслуживание оказалось неудовлетворительным, несмотря на операционную эффективность.

Эти проблемы с метриками приводят к разрыву между мнением службы ИТ о своей работе и мнением конечных пользователей. На панелях показателей службы ИТ может быть “зеленое море”, но восприятие конечными пользователями оставляет желать лучшего. Это явление известно в ИТ-индустрии как “арбузные SLA” – оценка производительности “зеленая снаружи, но красная внутри”, как арбуз. Однако, это не единственная проблема. Мнение службы ИТ о том, что “все хорошо”, может привести к упущению важных возможностей для улучшения работы и сконцентрированности на неправильных аспектах. Часто эти области представляют собой то, что служба ИТ-обслуживания считает возможностями или проблемами, а не реальными потребностями конечных пользователей.

Метрики опыта

Введение показателей опыта помогает преодолеть проблему “арбузных” SLA и позволяет сдвинуть фокус измерения производительности за пределы операционной “механики”. Это позволяет учитывать оценку конечными пользователями их реальных результатов. Данные об опыте помогают ИТ-службе выявить реальные проблемы, с которыми сталкиваются конечные пользователи, и лучше понять, что для них является наиболее важным. Это обеспечивает более сбалансированное представление о работе ИТ-службы, учитывающее не только операционную эффективность, результативность и соответствие требованиям, но и бизнес-результаты работы ИТ-службы.

Оригинал статьи