ПОРЯДОК РАЗРАБОТКИ МЕТРИК ПО ПРОЦЕССАМ
Прежде всего, важно помнить, что разработка метрик — не самоцель. Про каждую метрику важно понимать, кем и для чего она будет использоваться. «Что мы хотим оценивать?» — вот первый вопрос, который необходимо задать себе перед тем, как переходить к следующему — «Что для этого нужно и можно измерять?».
Измерения, формирование отчётов, оценка потребуют от менеджеров времени и сил как на этапе внедрения и настройки метрик, так и во время их использования. Это ещё один аргумент в пользу сведения числа метрик к необходимому и достаточному для решения задач по управлению процессами и ИТ-услугами.
Однако какими бы ни были пользователи системы измерения и оценки процессов и стоящие перед ними задачи, можно с известной долей уверенности предположить, что их будет интересовать, насколько процессы реализуют своё назначение в рамках системы управления ИТ-услугами. Кроме того, формулировка назначения процессов помогает определить их границы и сформировать корректные ожидания в отношении результатов их деятельности. Например, процесс управления инцидентами может включать или не включать в себя обработку стандартных запросов пользователей, процесс управления уровнем услуг — включать или не включать в себя управление отношениями с субподрядчиками, и так далее. Итак, первым шагом в разработке метрик для какого-либо процесса управления ИТ-услугами является формулировка назначения этого процесса. На практике назначение процесса формулируется на этапе проектирова- ния процесса, и меняется нечасто. Система метрик может разрабатываться тогда же, при проектировании процесса, либо позднее, когда процесс уже более или менее сформировался и реализуется. Во втором случае при наличии процессной документации формулировку назначения обычно можно найти в описании процесса.
|
|
|
Далее для процесса можно определить комплекс практик, необходимых для реализации назначения. Библиотека ITIL называет такие практики критическими факторами успеха (Critical Success Factors, CSF - Словарь терминов и аббревиатур ITIL: CSF — фактор, который обязательно должен реализоваться для успешности ИТ-услуги, процесса, плана,
проекта или другой деятельности. )
и указывает на необходимость использования KPI для измерения реализации каждого CSF. CSF — универсальный термин, в отношении же процессов.
Более специфичным является термин «ключевые практики процесса» (Материалы ISACA, в частности, словарь терминов ISACA, определяют
ключевые практики как «Практики управления, необходимые для успешного выполнения бизнес-процесса».) . Как и в случае с назначением, предполагается, что ключевые практики определяются на этапе проектирования процесса. Однако найти их перечень в процессной документации уже действующих процессов не всегда возможно, и их определение и описание может оказаться полезным упражнением в рамках работы по разработке процессных метрик.
|
|
|
Кроме идентификации ключевых практик, на этом этапе полезно выделить важные особенности процесса, влияющие на реализацию практик, а также на измерения и оценку.
Рисунок 5. Порядок разработки KPI по процессу
При разработке метрик также можно учитывать то, как они будут использоваться: кроме оперативных задач по управлению процессом, перед менеджерами могут стоять также задачи сравнения с другими организациями и планового совершенствования системы управления ИТ-услугами.
Бенчмаркинг
По ряду процессов ITSM аналитические компании публикуют отраслевые отчёты, позволяющие сравнивать значения основных метрик этих процессов различным предприятиям отрасли. Такая сравнительная оценка (бенчмаркинг) позволяет делать выводы об успехах управления ИТ-услугами в «нашей» компании в сравнении с конкурентами и лидера- ми рынка. Чтобы такие выводы были возможны, желательно использовать метрики, сравнимые с теми, что применяют в своих обзорах аналитики. В то же время важно учитывать специфику организации процессов ITSM в своей компании и делать выводы осторожно. Например, одна из распространённых метрик — показатель мощности потока инцидентов Incident Rate, который определяет, как много инцидентов происходит в организации (подробнее об этой метрике — в разделе второй главы, посвящённом управлению инцидентами). Incident Rate — это показатель, который равен числу инцидентов, зарегистрированных за период, в отношении к числу потребителей ИТ-услуг в организации. Для всех, кто имел дело с процессом управления инцидентами на практике, оче- видно, что и число инцидентов, и число пользователей можно считать несколькими способами, тем самым существенно меняя «наше» значение Incident Rate.
|
|
|
Дата добавления: 2018-02-28; просмотров: 301; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!