Itil\itsm

Многие подбирают ключевые показатели (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 Если тема интересна, можно познакомиться со статьями Стюарта Рейнса:

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

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

Я уже писал о там, как можно опеределить метрики (metrics) и ключевые показатели (KPIs) для некоторых процессов управления ИТ услугами (IT service management). В статье Как определить метрики для процесса Управления изменениями (перевод, оригинал) я рассуждал о важности идентификации заинтересованных лиц и определения факторов достижения успеха (CSFs), и дальнейшего использования этого при поиске ключевых показателей (KPIs) для измерений и отчетности. В статье Как определить метрики для процесса Управления проблемами (перевод, оригинал) продолжил тему и показал, как ключевые показатели (KPIs), предлагаемые в лучших практиках (например, ITIL), могут не подходить под реальные ситуации.

В ITIL (книга ITIL Practitioner)предлагается любопытная методика определения метрик в виде последовательного декомпозита Факторов достижения успеха процесса (CSFs) - Ключевые показатели процесса (KPIs) - Метрики (Metrics). Если очень кратко, то

• CSFs - это качественное описание результатов успешной работы процесса

• KPIs - количественное описание результатов успешной работы процесса

• метрики - что именно измеряем для расчета KPIs

В ответ на эти статьи я получил несколько запросов продолжить цикл и особенно часто встречался запрос на описание метрики для процесса Управления инцидентами (Incident Management). Ниже, что я думаю о том, как можно определять метрики для Управления инцидентами (Incident Management).

Первый вопрос, на который нужно ответить: Что такое управление инцидентами? Какая у него цель?. Ответы могут не совпадать, но большинство компаний получат что-то похожее на:

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

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

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

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

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

• Мы рационально используем наши ресурсы в процессе Управления инцидентами (Incident Management)

В идеале наши ключевые показатели должны помогать понимать достигнуты ли эти цели и показывают тренды, для определения, что требуется улучшить. Теперь давайте подумаем о том, что можно для этого измерять. Пожалуйста, не забывайте, что это все только пример, показывающий как можно думать об Управлении инцидентами (Incident Management).

Часть ключевых показателей (KPIs) могут идеально подойти одним компаниям и совершенно не подойти другим. Например, некоторые измеряют решение при первом контакте (First Call Resolution, FCR), т.е. какая доля обращений была решена в течение звонка на техподдержку (service desk) с обращением о наличии инцидента. Для многих компаний это отличный способ измерения того, что они быстро решают инциденты и рационально используют ресурсы, но если вы развиваете инструменты самообслуживания, то можете обнаружить, что показатель решения при первом контакте ухудшается, при том что качество услуг повысилось.

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

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

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

  • процент инцидентов 1-го приоритета решенных не хуже требования в Соглашении об уровне обслуживания (SLA)

  • процент инцидентов 2-го приоритета решенных не хуже требования в Соглашении об уровне обслуживания (SLA)

  • процент инцидентов 3-го приоритета решенных не хуже требования в Соглашении об уровне обслуживания (SLA)

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

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

  • количество жалоб заказчиков или обращений для поднятия приоритета инцидента

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

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

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

  • процент пользователей давших оценку 4 или 5 в опросе удовлетворенности решением инцидента

  • изменения удовлетворенности заказчиков работой процесса Управления инцидентами (Incident Management) по итогам ежегодных опросов

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

  • число проблем зафиксированных техподдержкой (service desk)

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

• Мы рационально используем наши ресурсы в процессе Управления инцидентами (Incident Management)

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

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

  • средняя цена решения инцидентов (в разрезе приоритетов)

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

После прочтения ответьте для себя на пару вопросов:

• На чем основаны ваши текущие ключевые показатели (KPIs) процесса Управления инцидентами (Incident Management)?

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

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

На этом все надеюсь статья была интересна