Как измерять процессы управления информационными технологиями

Управление – довольно широкое понятие. Покопавшись в различных энциклопедиях, вы без труда можете найти пять-шесть различных определений этого термина. В данной статье под управлением мы будем понимать «Особый вид профессионально осуществляемой деятельности, направленной на достижение определённых целей путём рационального использования материальных и трудовых ресурсов...» [1]. В данном определении есть два важных момента. Первый момент – объектом управления являются не только материальные, но и трудовые ресурсы (люди). В русскоязычной литературе данный вид управления иногда называют словом «менеджмент» для того, чтобы отличать его от управления, скажем, автомобилем или банковским счётом. В данной статье мы для простоты будем считать термины «управление» и «менеджмент» синонимами. Второй важный момент в определении – управление представляет собой деятельность, работу (в отличие от власти, полномочий). Эта деятельность включает в себя различные аспекты, один из которых – необходимость принятия управленческих решений. 

Как следует из приведённого выше определения, управленческие решения касаются постановки целей и использования ресурсов. Например, перераспределения ресурсов с целью снижения рисков нехватки персонала или компетенции. Или разработки новых продуктов и услуг. И так далее. Для того чтобы принимать подобные решения, необходимо понимать текущее и плановое состояние объекта управления, в нашем случае – деятельности, связанной с применением и развитием информационных технологий. В крупных организациях не только плановое, но и текущее состояние объекта управления не всегда известно, то есть существует некоторая мера неопределённости.

Измерение представляет собой «выраженное в количественных величинах сокращение неопределённости на основании одного или нескольких наблюдений» [2]. Таким образом, измерение является одним из аспектов управления, и его важность возрастает с ростом сложности объекта управления.

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

Суть метода

Суть метода не нова. Она заключается в том, чтобы связать с процессом набор так называемых метрик. Здесь метрика – технически или процедурно измеряемая величина, характеризующая объект управления (в нашем случае – процессную деятельность). И опять выделим в этом определении два важных момента. Первый – метрика не обязательно измеряется технически (рассчитывается средствами автоматизации процесса). Существуют весьма важные метрики, значения которых можно получить только опросом участников процессов или потребителей услуг. Да, они могут восприниматься как более субъективные. Но, возможно, именно этот субъективизм и ценен. Например, точка зрения потребителя является важным аспектом управления качеством. Борьба за повышение качества в целом, а тем более качества услуг, без учёта точки зрения потребителя невозможна, поскольку противоречит определению качества.

Второй важный момент в приведённом определении метрики – метрика характеризует объект управления. Этот, на первый взгляд, банальный факт пригодится нам чуть позже, когда мы будем рассматривать, как разрабатываются процессные метрики.

И так, предположим, мы разработали набор метрик, характеризующий наш объект управления (процессную деятельность) достаточно полно (достаточно для обоснованного принятия сформулированных нами управленческих решений). Разумеется, работа управленца на этом не заканчивается. Напротив – она только начинается. Фактически метрики (а в более общем смысле – измерение в целом) помогают принимать управленческие решения на различных уровнях управления. На оперативном – в рамках оперативного контроля. Например, так можно принимать решения, направленные на повышение результативности процесса посредством стимулирования ключевых исполнителей. На тактическом уровне – в рамках планирования деятельности в среднесрочной перспективе. Например, так можно принимать решения о перераспределении полномочий по управлению процессом или о «настройке» интерфейсов между несколькими процессами.

Это значит, что измерение процессов – просто один из этапов в регулярном контроле, оценке и совершенствовании процессов. Организация цикла контроля, оценки и совершенствования – является важнейшим аспектом внедрения или повышения зрелости процессов [4].

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

Подводя итоги, суммируем суть метода измерения процессов в следующих двух пунктах:

1. разработка системы метрик для измерения процессов;
2. применение системы метрик в рамках цикла контроля, оценки и совершенствования процессов для принятия более обоснованных управленческих решений.

Разработка системы метрик

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

1. Метрики результативности. Данные метрики формулируются, исходя из назначения, целей и задач процесса. Концепция назначения, целей и задач процессов (purpose, goals and objectives) используется авторами ITIL® во всех книгах, однако без должного объяснения. Небольшая заметка о назначении, целях и задачах процесса представлена в [5]. Примеры метрик результативности для процесса управления инцидентами представлены в таблице ниже. 

    

    

   Характеристика процесса	Метрика результативности
   Назначение: обеспечение качества ИТ-услуг за счёт скорейшего устранения инцидентов и своевременного выполнения запросов на обслуживание.	Среднее время устранения инцидентов в разбивке по уровню влияния (особенный интерес представляет измерение в динамике). Единица измерения – минуты.
   Цель: в 1Q 2011 сократить превышение норматива времени на приём в работу до 5%.	Доля инцидентов, принятых в работу с соблюдением норматива на время приёма в работу. Единица измерения – проценты.
   Задача: организация накопления и повторного использования знаний по устранению инцидентов.	Доля инцидентов, решённых с помощью обходных решений из базы знаний. Единица измерения – проценты.

    

    

   Обратите внимание, что если цель процесса сформулирована с соблюдением принципов SMART [4], метрика для контроля достижения данной цели «извлекается» непосредственно из формулировки цели.

2. Метрики рациональности. Данные метрики характеризуют количество ошибок, возникающих при исполнении процесса, использование тех или иных механизмов, предусмотренных для сокращения трудозатрат и так далее. Например, для процесса управления изменениями это может быть метрика «доля изменений, возвращённых на повторное оформление в результате проверки менеджером процесса [%]». Для процесса управления инцидентами это может быть «доля обращений, зарегистрированных пользователями самостоятельно посредством web-портала [%]».
3. Метрики, характеризующие степень соответствия процесса нормативной документации. Например, «доля изменений, прошедших выборочную проверку у менеджера процесса при закрытии [%]» (если соответствующий норматив определён в регламенте процесса). Или «доля фактически проведённых аудитов CMDB от общего количества аудитов, предусмотренных годовой программой аудита CMDB [%]».
4. Метрики, характеризующие объём работ по исполнению процесса. Например, «количество изменений, обработанных за месяц [штуки]». Или метрика потока обработки проблем, рассчитываемая по формуле (N+C)/(O+C), где C – количество проблем, закрытых за период, O – количество проблем, открытых по итогам периода, N – количество проблем, зарегистрированных за период, но не закрытых к его окончанию (подробнее данная метрика обсуждается в [6]).

За годы выполнения проектов по организации тех или иных процессов управления ИТ мной и моими коллегами были сформулированы (или усвоены) некоторые хорошие практики по разработке метрик. Вот основные из них:

1. Метрик не должно быть слишком много. Про каждую метрику разработчик должен быть в состоянии объяснить, кому и когда значение этой метрики помогает принять то или иное решение. «Все» метрики всё равно не придумать – важнее научить менеджера процесса разработке метрик и их использованию в управлении процессом.
2. По назначению, всем целям и всем задачам процесса метрики обязательны. Такие метрики позволяют судить о результативности процесса, а это очень важно для управленца – для стимулирования исполнителей, для оценки экономического эффекта, выполнения иных управленческих функций.
3. Помимо метрик, представляющих собой общую характеристику процесса (на основании которых нельзя сделать вывод «хорошо или плохо»), например «количество изменений, зарегистрированных за период», обязательно также наличие метрик-индикаторов (KPI), по значениям которых можно делать вывод о текущем состоянии процесса. Такие метрики, как правило, выражаются в процентах, изменяются в фиксированном диапазоне от 0 до 1, с ними относительно легко связать целевое значение. При этом желательно, чтобы все подобные метрики имели общую «направленность», например «чем ближе к 1, тем лучше».
4. Помимо метрик, характеризующих процесс в целом, необходимы метрики, характеризующие работу ключевых ролей в процессе. Эти метрики могут (и должны) быть использованы при формировании системы мотивации, стимулирующей качественное исполнение процесса. Например, «доля инцидентов, принятых в работу своевременно (в соответствии с установленным нормативом)» – отличная метрика для оценки работы старшего группы, которой инциденты передаются на обработку. Очевидно, метрики связываются с ролями процесса на основании таблицы RASCI.
5. При наличии нескольких метрик, характеризующих ту или иную роль, необходим механизм их агрегирования (то есть комбинирования значений для получения интегральной оценки успешности работы исполнителей данной роли).
6. Необходимо внимательно проверять метрики, чтобы исключить возможность лёгкого манипулирования значениями со стороны оцениваемых ролей. Например, в одном из проектов, в котором мы осуществляли контроль качества, внешний консультант предложил заказчику метрику «доля проблем, решённых в установленный срок» для оценки работы аналитиков проблем. При этом срок решения проблемы устанавливался самим аналитиком. Думаю, польза такой метрики сомнительна.

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

Некоторые ограничения метрик

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

Идея конечной ценности результатов измерений, ограничивающая применение некоторых метрик (или, по крайней мере, способов их расчёта) раскрывается в литературе по прикладной информационной экономике (Applied Information Economics). Подробную информацию об этом методе можно почерпнуть у его автора в книге «How to Measure Anything» [2].

Приведённые здесь соображения ещё раз подтверждают, что копировать метрики процессов из каких-либо книг довольно бессмысленно. Состав метрик и их применение зависят и от модели процесса, и от среды, накладывающей ограничения на их измерение. Поэтому выбор оптимальной системы метрик остаётся не только важной, но и интересной задачей. Разве достойно настоящего управленца избегать таких задач?

Литература

1. Социология: Энциклопедия / cост. А.А. Грицанов, В.Л. Абушенко, Г.М. Евелькин, Г.Н. Соколова, О.В. Терещенко. – Минск: Книжный Дом, 2003. — 1312 с.
2. Habbard D. How to Measure Anything. Finding the Value of «Intangibles» in Business – John Wiley and Sons, Inc., 2010. – 320 p.
3. Simons R., Davila A. How High is Your Return on Management? – Harvard Business Review, January-February 1998. – P. 69-80.
4. ITIL Continual Service Improvement – The Stationery Office Books, 2007. — 221 p.
5. Исайченко Д. Purpose, goals and objectives
6. Исайченко Д. Измеряем Problem management