Звоните: +7 (495) 517-57-25

measure it

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

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

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

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

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

Суть метода

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

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

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

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

Это значит, что измерение процессов — просто один из этапов в регулярном контроле, оценке и совершенствовании процессов. Организация цикла контроля, оценки и совершенствования — является важнейшим аспектом внедрения или повышения зрелости процессов [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. Необходимо внимательно проверять метрики, чтобы исключить возможность лёгкого манипулирования значениями со стороны оцениваемых ролей. Например, в одном из проектов, в котором мы осуществляли контроль качества, внешний консультант предложил заказчику метрику «доля проблем, решённых в установленный срок» для оценки работы аналитиков проблем. При этом срок решения проблемы устанавливался самим аналитиком. Думаю, польза такой метрики сомнительна.

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

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

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

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

Идея конечной ценности результатов измерений, ограничивающая применение некоторых метрик (или, по крайней мере, способов их расчёта) раскрывается в литературе по прикладной информационной экономике (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 

Дмитрий Исайченко