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

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

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

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

Далее в статье мы будем говорить об измерении процессов управления ИТ-услугами, однако излагаемый метод измерения не ограничен данным подмножеством процессов.

Суть метода

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

В одном из номеров журнала Harvard Business Review за 1998 год [4] приводилась любопытная метрика — рентабельность управления (Return on Management, ROM). Ее суть – оценка того, насколько хорошо удается руководителям фокусироваться на реализации стратегии компании. Авторы определенно указывают на то, что эта метрика не является математической формулой, дающей объективное числовое значение. И несмотря на это, авторы относят данную метрику к столь же важным экономическим показателем, как, скажем, Return on Assets (ROA) или Return on Capital Employed (ROCE). Ведь ROM позволяет судить об отдаче самого дефицитного ресурса компании – времени и сил ее руководителей.

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

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

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

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

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

Итак, суть метода измерения процессов состоит в двух пунктах.

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

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

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

Метрики результативности. Формулируются исходя из назначения, целей и задач процесса. Концепция назначения, целей и задач процессов (purpose, goals and objectives) используется авторами ITIL во всех книгах, и тем не менее должного системного объяснения эта концепция в книгах ITIL не нашла (www.realitsm.ru/2011/07/purpose-goals-and-objectives). Примеры метрик результативности для процесса управления инцидентами представлены в таблице.

 

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

 

Если цель процесса сформулирована с соблюдением принципов SMART (Specific, Measurable, Attainable, Relevant, Time-bound), то метрика для контроля достижения данной цели «извлекается» непосредственно из формулировки цели.

Метрики рациональности. Характеризуют количество ошибок, возникающих при исполнении процесса, использования тех или иных механизмов, предусмотренных для сокращения трудозатрат и т. д. Например, для процесса управления изменениями это может быть метрика «доля (в %) изменений, возвращенных на повторное оформление в результате проверки менеджером процесса». Для процесса управления инцидентами это может быть «доля (в %) обращений пользователей, закрытых после получения подтверждения по e-mail». Формулировка данных метрик выполняется исходя из описания процедур процесса.

Метрики соответствия. «Доля изменений, прошедших выборочную проверку у менеджера процесса при закрытии» (если соответствующий норматив определен в регламенте процесса), «доля фактически проведенных аудитов CMDB от общего количества аудитов, предусмотренных годовой программой аудита CMDB», причем формулировка метрик выполняется исходя из описания процедур процесса.

Метрики объема работ по исполнению процесса. «Количество изменений, обработанных за месяц (штуки)» или метрика потока обработки проблем :

(N+C)/(O+C),

где C – количество проблем, закрытых за период, O – количество проблем, открытых по итогам периода, N – количество проблем, зарегистрированных за период, но не закрытых к его окончанию (http://www.realitsm.ru/2010/12/measuring-problem-management). Данные метрики также формулируются на основании описания процедур процесса.

Опыт выполнения различных проектов по организации процессов управления ИТ позволяет сформулировать следующие рекомендации по разработке метрик.

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

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

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

Помимо метрик, характеризующих процесс в целом, обязательно должны присутствовать метрики, характеризующие работу ключевых ролей в процессе. Эти метрики используются при формировании системы мотивации, стимулирующей качественное исполнение процесса. Например, «доля инцидентов, принятых в работу своевременно (в соответствии с установленным нормативом)» – отличная метрика для оценки работы руководителя функциональной группы, обрабатывающей инциденты. Очевидно, метрики связываются с ролями процесса на основании таблицы RASCI, которая представляет собой расширенный вариант известной матрицы RACI (Responsible, Accountable, Consulted, Informed), описывающей участие при выполнении задач в виде определенных ролей: ответственный, подотчетный, консультирующий, информируемый.

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

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

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

Ограничения метрик

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

Например, попытаемся измерить пользу от исполнения процесса управления проблемами. Исходя из назначения процесса, его польза – в сокращении количества и степени тяжести инцидентов. Однако на практике измерить это оперативно (например, по итогам квартала), не так-то просто — для этого нам потребовалось бы обеспечить относительно точный учет связей между проблемами и вызываемыми ими инцидентами. Любой, кто пробовал решить эту задачу, знает, что учет таких связей хотя бы с точностью 90% требует жесткого контроля исполнителей. На практике же ресурс менеджеров, как правило, ограничен в большей степени, чем ресурс исполнителей, поэтому оценку пользы от процесса управления проблемами часто выполняют не только на основании метрик, но и на основании письменного отчета менеджера процесса за период, в котором он фиксирует наиболее значимые решенные проблемы. Это вполне рабочий механизм.

Идея конечной ценности результатов измерений, ограничивающая применение некоторых метрик (или, по крайней мере, способов их расчета), раскрывается в литературе по прикладной информационной экономике, иинформацию об этом методе можно почерпнуть в [ 3 ].

***

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

Литература

  1. Социология: Энциклопедия/Сост. А. А. Грицанов, В. Л. Абушенко, Г. М. Евелькин, Г. Н. Соколова, О. В. Терещенко. – Минск: Книжный Дом, 2003.
  2. Якокка Л. Карьера менеджера. – Минск: Попурри, 2005.
  3. Habbard D. How to Measure Anything. Finding the Value of «Intangibles» in Business – John Wiley and Sons, Inc., 2010.
  4. Simons R., Davila A. How High is Your Return on Management? – Harvard Business Review, January-February 1998.

Дмитрий Исайченко (d.isaychenko@cleverics.ru ) – директор по консалтингу компании Cleverics (Москва).