Метрики ИТ-процессов. 
Управление ит-проектами и процессами

В табл. 13.1 приведены ключевые показатели эффективности для различных процессов. Здесь рассмотрим основные требования к системе метрик и KPI.

Метрики и KPI не являются синонимами. Основное различие в том, что обычно метрики, являющиеся объективно собираемыми и рассчитываемыми количественными значениями, не имеют целевого значения, непосредственно не связаны с системой мотивации сотрудников и могут быть недоступны для контроля извне процесса (внешним наблюдателем). В то время как KPI строятся на основе метрик, но имеют целевое значение, часто встраиваются в систему мотивации сотрудников и могут быть объективно проконтролированы внешним по отношению к процессу наблюдателем.

Метрики могут собираться внутри процесса для внутреннего или внешнего контроля его исполнения и поиска возможности улучшений. Набор метрик обычно шире, чем набор KPI.

Целью сбора метрик является определение текущего уровня эффективности процессов, включая оценку удовлетворенности потребителей его результатов (а также взаимодействующих процессов). В соответствии с общей теорией качества нельзя улучшить то, что нельзя измерить. Это определяет значение метрик в развитии ИТ-услуг.

Набор метрик должен в основном соответствовать целям бизнеса, целям развития ИТ-услуг и целям процессов. Если внедряются метрики, не привязанные к целям основной деятельности, это может привести к негативным результатам в связи с искажением целей. Примером подобных метрик является внедрение «палочных» показателей в деятельности правоохранительных органов, когда их эффективность измерялась количеством выявленных правонарушений. Тот же результат получим, если подобные метрики будут внедрены в работе внутренней службы безопасности банка или службы операционных рисков — полезная деятельность организации будет в значительной степени заблокирована в связи с непрерывной «охотой на ведьм». Корректной метрикой деятельности для подобных служб является, например, размер ущерба, полученного банком за отчетный период в результате инцидентов безопасности или операционных сбоев. Деятельность этих служб должна быть направлена в итоге на снижение ущерба в рамках своей компетенции, а не на поиск «воображаемых» угроз или завышенных рисков.

Если процессы недостаточно развиты, то сбор объективных количественных метрик затруднен — процессы не имеют контрольных точек. Если процессы не носят повторяющийся характер (на низких уровнях зрелости), то метрики либо невозможно собрать, либо они не имеют информационной ценности.

Часть метрик может представлять собой «сырые» данные, непосредственно собираемые, например, системами мониторинга. Основное количество метрик является расчетными на основе первичных данных. Они более репрезентативны и облегчают анализ.

Оценка процесса или подразделения на соответствие модели зрелости CMMI является допустимой и ценной метрикой, поскольку обеспечивает возможность сравнения эффективности деятельности подразделений или процессов с разнородными функциями и целями. Единственной альтернативной сравнительной метрикой является опрос удовлетворенности заказчиков или менеджеров взаимодействующих процессов, например, по шкале Лайкерта^[1].

Внедрение метрик часто положительно изменяет поведение сотрудников само по себе, даже без привязки к системе мотивации. Например, в рамках одного из крупных проектов, реализованных автором, группой тестирования была предоставлена информация о значительной разнице в эффективности деятельности разработчиков. Руководством проекта было принято решение о еженедельной публикации в свободном доступе на внутреннем портале двух показателей для каждого разработчика: 1) количество разработанных и предоставленных на тестирование функций; 2) количество найденных ошибок в предоставленном на тестирование ПО.

В результате регулярного раскрытия информации повысилась эффективность деятельности всех разработчиков — «осторожные» разработчики, поставлявшие более качественное программное обеспечение, но с меньшей скоростью (англ, time to market), нарастили скорость поставки без потери качества. «Торопливые» разработчики, поставлявшие обновления с высокой скоростью, но большим количеством дефектов (что приводило к частым возвратам на исправление), значительно повысили качество поставок практически без потери скорости. Здесь обратите внимание на то, что было внедрено две встречные взаимодополняющие метрики. По отдельности они не являются репрезентативными и не привели бы к повышению эффективности.

Кроме того, приведенный пример иллюстрирует требование объективного сбора данных и расчета метрик незаинтересованной стороной. Показатели характеризовали деятельность разработчиков, но контролировались группой тестирования.

Часто допускаемой ошибкой при формировании набора метрик является их использование для «наказания», а не мотивации сотрудников. Неэффективность подобного подхода многократно доказывалась на практике^[2].

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

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

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

Различные метрики могут предоставляться различным аудиториям. Не все метрики должны быть общедоступны. Обычно аудитории для предоставления метрик подразделяются на следующие группы: клиенты, пользователи, сотрудники ИТ, руководство. Например, если мы намерены информировать клиентов о росте качества и надежности наших ИТ-услуг, то нежелательно предоставление в открытом доступе информации непосредственно о количестве зарегистрированных инцидентов, даже если оно снижается из года в год, но при этом допустимо размещение информации о процентной динамике снижения количества инцидентов.

Ошибочно мнение о том, что отдельные процессы или подразделения не поддаются внедрению метрик. Обычно такая ошибка допускается в отношении контролирующих подразделений, например, финансового мониторинга. Любая деятельность поддается внедрению эффективных метрик, например, для приведенного подразделения могут быть внедрены следующие метрики: средняя задержка в предоставлении финотчета (любая деятельность должна быть плановой и иметь устойчивый повторяющийся характер), степень достоверности финпрогноза за период (достоверность финансового планирования должна расти со временем) и др.¹

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

Для более широкого рассмотрения темы метрик и KPI рекомендуем обратиться к работе П. Брукса «Метрики для управления ИТ-услугами».

• [1] Орлов А. Организационно-экономическое моделирование. Экспертные оценки.
• [2] Брукс П. Метрики для управления ИТ-услугами. М.: Альпина Бизнес Букс, 2008.