ИТ-скептик (в миру Роб Ингланд), споря со статьей Симона Хиггинсона на портале The ITSM Review, предлагает несколько собственных KPI для управления проблемами.

Есть несколько замечаний:

У проблемы обычно несколько причин. Объявлять единственную причину «корневой» – значит быть субъективным. Например, если время диагностики ограничено: «ой, наше время вышло, волевым решением объявляем обнаруженную причину корневой».

Продолжительность диагностики и продолжительность исправления нужно измерять, чтобы выявлять тенденции. Но можно ли использовать их в качестве целевых показателей? «Доктор, вам нужно продиагностировать всех пациентов за два часа». Или: «Пожарный, вы должны устранять маленькие пожары за три дня, средние за восемь часов, а огромные пожары за два часа». Надо помнить, что SLT (Service level targets) это не просто метрики. Это пороги, при превышении которых кто-то понесёт ответственность. Если они не справедливые, то работать не будут, и я не считаю, что целевые уровни продолжительности всегда справедливы.

Так что для управления проблемами мне кажутся приемлемыми следующие KPI:

• Среднее время реакции на проблемы, по приоритетам
• Удовлетворенность сервис-деска и команд управления инцидентами тем, как управляются проблемы
• Снижение комплексного индекса рисков для портфеля проблем
• Доля решенных проблем
• Доля повторно появляющихся проблем
• Доля «стандартизованных проблем», то есть документированных процедур исправления повторяющихся проблем
• Затраты и нагрузка на ресурсы, которую создает процесс управления проблемами
• Доля нерешаемых проблем («висяков»)
• Количество статьей в базе знаний (особенно обходных решений), которые создают сотрудники управления проблемами

А есть ли у вас собственные любимые метрики процесса управления проблемами? Поделитесь в комментариях! Кстати, мы о своих уже рассказывали: раз, два, три.

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Построение системы KPI для ИТ

Как обеспечить управление процессами, проектами, услугами, персоналом