[IT-стандарты, Терминология IT, Service Desk, Управление продуктом] Как определить метрики для процесса Управления проблемами (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Многие подбирают ключевые показатели (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 Если тема интересна, можно познакомиться со статьями Стюарта Рейнса:Как определять метрики для процесса Управления (перевод, оригинал)Осторожно. Как использовать метрики процессов без вреда для здоровья процессов (перевод, оригинал)
===========
Источник:
habr.com
===========
===========
Автор оригинала: Stuart Rance
===========Похожие новости:
- [Информационная безопасность, Service Desk, Развитие стартапа, Финансы в IT, IT-компании] Европейские банки в сравнении с российскими как жигули в сравнении с Porsche Cayenne
- [Учебный процесс в IT, Развитие стартапа, Управление продуктом, Карьера в IT-индустрии] YC Startup Library на русском: Как создавать и тестировать идеи для стартапов (Майкл Сибель) (перевод)
- [IT-стандарты, Терминология IT] Как создать метрики для Управления изменениями (перевод)
- [IT-стандарты, Законодательство в IT] «Налоговый маневр» в ИТ-индустрии: кто выиграет?
- [Управление разработкой, Управление продуктом] Настроили мониторинг. Что дальше?
- [Программирование, Управление проектами, Управление продуктом, Карьера в IT-индустрии] Pet-проекты: зачем они нужны, и стоит ли тратить на это время в 2020 году + опрос
- [Интерфейсы, Дизайн мобильных приложений, Управление продуктом, Дизайн] Friends of Figma Moscow
- [Управление разработкой, Управление проектами, Управление продуктом, Бизнес-модели, IT-компании] Как запустить IT-продукт за 1,5 месяца и не закрыться через полгода с колоссальными убытками
- [Управление разработкой, Управление проектами, Управление продуктом, Управление персоналом, Конференции] Управление разработкой в «горизонтальных» компаниях: расшифровка онлайн-встречи. Часть 1
- [Open source, Терминология IT, IT-компании] Google вводит обязательную инклюзивную терминологию во всех своих открытых проектах
Теги для поиска: #_itstandarty (IT-стандарты), #_terminologija_it (Терминология IT), #_service_desk, #_upravlenie_produktom (Управление продуктом), [url=https://torrents-local.xyz/search.php?nm=%23_itil\itsm&to=0&allw=0&o=1&s=0&f%5B%5D=820&f%5B%5D=959&f%5B%5D=958&f%5B%5D=872&f%5B%5D=967&f%5B%5D=954&f%5B%5D=885&f%5B%5D=882&f%5B%5D=863&f%5B%5D=881&f%5B%5D=860&f%5B%5D=884&f%5B%5D=865&f%5B%5D=873&f%5B%5D=861&f%5B%5D=864&f%5B%5D=883&f%5B%5D=957&f%5B%5D=859&f%5B%5D=966&f%5B%5D=956&f%5B%5D=955]#_itil\itsm[/url], #_kpi, #_csf, #_upravlenie_problemami (управление проблемами), #_itstandarty (
IT-стандарты
), #_terminologija_it (
Терминология IT
), #_service_desk, #_upravlenie_produktom (
Управление продуктом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:24
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Многие подбирают ключевые показатели (KPIs) для своих процессов Управления ИТ услугами по книгам (таких как ITIL Service Operation) или копируя метрики, используемые в других компаниях. Это редко приводит к хорошим результатам, потому что дословно KPIs - это дословно Показатели Результативности Ключевых задач, которыми вы занимаетесь. Хуже только ITSM процессы с огромным количеством одинаково названных показателей, которые измеряются, по ним пишутся отчеты, но результаты этого никто не использует ни для изменения деятельности в рамках процессах, ни для улучшения бизнес результатов. Ранее я уже писал заметку "Как определять метрики для процесса Управления изменениями" (перевод, оригинал) , в которой я описывал, как можно создать ключевые показатели (KPIs), которые поддерживают именно ваши цели. Читатели (оригинала) после прочтения просили привести примеры, как выделять ключевые показатели (KPIs) для остальных процессов управления ИТ-услугами. В результате я решил написать эту статью для показателей процесса Управления проблемами (problem management), потому что в большинстве компаний, где я работал, у этого процесса были очень куцые показатели. Напоминаю, что не стоит бездумно копировать приводимые здесь результаты процесса (outcomes), его критичные факторы успешности (CSFs) и ключевые показатели (KPIs). Содержание статьи стоит использовать только для понимания подхода и методологии, которые мною используются. И задуматься о том, что важно именно для вас, выделить метрики, для измерения задачи, за которые вы отвечаете. Первый шаг для определения качественных ключевых показателей (KPIs) - определить цели процесса Управления проблемами, которые его результаты должны помочь вам достигнуть. Для у “правильного” процесса Управления проблемами есть два ключевых результата:
Когда вы пересматривали в вашем процессе Управления проблемами ключевые показатели (KPIs) и связанные с ними факторы достижения успешности (CSFs) и цели?PS Если тема интересна, можно познакомиться со статьями Стюарта Рейнса:Как определять метрики для процесса Управления (перевод, оригинал)Осторожно. Как использовать метрики процессов без вреда для здоровья процессов (перевод, оригинал) =========== Источник: habr.com =========== =========== Автор оригинала: Stuart Rance ===========Похожие новости:
IT-стандарты ), #_terminologija_it ( Терминология IT ), #_service_desk, #_upravlenie_produktom ( Управление продуктом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:24
Часовой пояс: UTC + 5