Как определить метрики для процесса Управления проблемами

IT-стандартыТерминология ITService DeskУправление продуктом
Автор оригинала: Stuart Rance

Многие подбирают ключевые показатели (KPIs) для своих процессов Управления ИТ услугами по книгам (таких как ITIL Service Operation) или копируя метрики, используемые в других компаниях. Это редко приводит к хорошим результатам, потому что дословно KPIs - это дословно Показатели Результативности Ключевых задач, которыми вы занимаетесь. Хуже только ITSM процессы с огромным количеством одинаково названных показателей, которые измеряются, по ним пишутся отчеты, но результаты этого никто не использует ни для изменения деятельности в рамках процессах, ни для улучшения бизнес результатов.

Ранее я уже писал заметку "Как определять метрики для процесса Управления изменениями" (перевод, оригинал) , в которой я описывал, как можно создать ключевые показатели (KPIs), которые поддерживают именно ваши цели. Читатели (оригинала) после прочтения просили привести примеры, как выделять ключевые показатели (KPIs) для остальных процессов управления ИТ-услугами. В результате я решил написать эту статью для показателей процесса Управления проблемами (problem management), потому что в большинстве компаний, где я работал, у этого процесса были очень куцые показатели.

Напоминаю, что не стоит бездумно копировать приводимые здесь результаты процесса (outcomes), его критичные факторы успешности (CSFs) и ключевые показатели (KPIs). Содержание статьи стоит использовать только для понимания подхода и методологии, которые мною используются. И задуматься о том, что важно именно для вас, выделить метрики, для измерения задачи, за которые вы отвечаете.

Первый шаг для определения качественных ключевых показателей (KPIs) - определить цели процесса Управления проблемами, которые его результаты должны помочь вам достигнуть. Для у “правильного” процесса Управления проблемами есть два ключевых результата:

  • уменьшение количества возникающих инцидентов

  • уменьшение влияния на бизнес от инцидентов, которые не смогли предотвратить

Мы можем просто измерять количество инцидентов и их общее влияние на бизнес. Это точно будет полезно знать, но я не уверен, что они смогут показывать, как хорошо работает именно процесс Управления проблемами, т.к. слишком много факторов на него влияет. Я немного разбавлю их и предложу несколько критических факторов успешности (CSFs), которые могут поспособствовать получению результатов:

  • определение проблем, которые являются причиной множественных инцидентов

  • создавать среду, которая снижает влияние от инцидентов

  • инициирование изменений, которые уменьшают количество инцидентов

Стоит сказать, почему я не упомянул поиск корневых причин проблем (root cause analysis, RCA). Я видел много людей в управлении проблемами, кто думал только о поиске корневых причинах, но это не давало им особого результата, потому что RCA - это не более чем одна из техник, используемых в Управлении проблемами. Худшие ключевые показатели, которые можно придумать, - это “среднее время обнаружения корневой причины”, “доля проблем, у которых ключевая причина была выявлена не хуже 3 дней” и т.п. Использование таких показателей провоцирует участников Управления проблемами на поведение, которое мне бы не хотелось получить. Это равносильно заявлению, что в сложной многофакторной ситуации нужно искать единственную корневую причину. Для меня более правильный способ - это проведение постоянного анализа, даже если в его результате удастся идентифицировать только одну значимую причину.

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

Мое предложение нескольких ключевых показателей (KPIs), которые могут помочь показать достижение критичных факторов успешности (CSFs), которые я приводил выше. Еще раз напомню, что не стоит бездумно их копировать, используйте похожий подход для определения ключевых показателей (KPIs), которыми можно измерять ваши задачи.

CSF1 - определение проблем, которые являются причиной множественных инцидентов

  • увеличение доли инцидентов ассоциированных с записями о проблемах или известными ошибками

  • отчет о топ 5 проблем создается каждый месяц

CSF2 - создавать среду, которая снижает влияние от инцидентов

  • увеличение доли инцидентов, для которых в базе знаний есть статьи с решениями

  • увеличение доли инцидентов решенных пользователями с использованием инструментов самостоятельного решения

  • уменьшение влияния инцидентов, ассоциированных с топ 5 проблем прошлого месяца

CSF3 - инициирование изменений, которые уменьшают количество инцидентов

  • уменьшение количества инцидентов, ассоциированных с топ 5 проблем прошлого месяца

  • уменьшение беклога незавершенных проблем

Я сформулировал эти ключевые показатели, как “Увеличение…” или “Уменьшение…”, так как мне не хватает необходимыми данными для установки точных целей. Вы можете использовать метрики похожие на эти, но подставить в них оцифрованные цели, с точкой отсчета, которую вы определите после первых измерений и их анализа.

На сколько метрики, измеряемые в вашем процессе Управления проблемами, соответствуют потребностям ваших заказчиков?
Когда вы пересматривали в вашем процессе Управления проблемами ключевые показатели (KPIs) и связанные с ними факторы достижения успешности (CSFs) и цели?

PS Если тема интересна, можно познакомиться со статьями Стюарта Рейнса:

Как определять метрики для процесса Управления изменениями (перевод, оригинал)

Осторожно. Как использовать метрики процессов без вреда для здоровья процессов (перевод, оригинал)

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

Теги:itil\itsmkpicsfуправление проблемами
Хабы: IT-стандарты Терминология IT Service Desk Управление продуктом
+3
2k 17
Комментарии 4

Похожие публикации

IT Recruiter
от 800 до 1 300 $IT X100Можно удаленно
IT Recruiter / IT Рекрутер
от 50 000 ₽BeGetСанкт-Петербург
IT Рекрутер
от 1 000 до 2 000 $Brain ShellsМожно удаленно
IT Recruiter (trainee/junior)
от 20 000 до 50 000 ₽SMYTМожно удаленно
Рекрутер в сфере IT
от 80 000 ₽Tilda PublishingМоскваМожно удаленно

Лучшие публикации за сутки