Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Многие подбирают ключевые показатели (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 Если тема интересна, можно познакомиться со статьями Стюарта Рейнса:
Как определять метрики для процесса Управления (перевод, оригинал)
Осторожно. Как использовать метрики процессов без вреда для здоровья процессов (перевод, оригинал)
