Возможно, вы консультант или вновь назначенный ИТ-менеджер или просто очень любознательный сотрудник ИТ-департамента, который хочет разобраться, как работает управление ИТ в организации. Эти метрики помогут быстро составить впечатление от ИТ-департамента вашей организации и наметить следующие шаги.
Важные предостережения:
- Это не показатели для ежедневного контроля – значения большинства их них не меняются существенно даже на отрезке года.
- Метрики в основном не годятся в качестве KPI ИТ-подразделения или ИТ-директора – большинству из них нельзя задать целевое значение.
- Это не чеклист для обследования ИТ-департамента, а лишь база для дальнейшего анализа.
- Большинство метрик уместно использовать и для измерения коммерческого провайдера ИТ-услуг, но все же фокус этой статьи – внутренний ИТ-департамент организации, бизнес которой не связан с информационными технологиями.
Вот эти метрики:
- Доля ИТ-затрат в общих операционных затратах организации
- Уровень доступности
- Incident rate
- Своевременность обработки запросов
- Доля численности ИТ-персонала в развитии
- Размер бэклога (разработки)
- Доля времени разработчиков на эксплуатацию
- Удовлетворенность потребителей услуг
Анализ представленных показателей позволят быстро и на основе цифр составить портрет ИТ-департамента, подскажут путь дальнейшего анализа, посветят области, требующие внимания и приложения усилий. Разберем каждый из них.
Доля ИТ-затрат
Говорят, что технологии уже пронизывают каждую функцию организации и оказывают критическое влияние на все аспекты бизнеса. Но возможно конкретной организации – еще не до цифровой трансформации. Метрика наглядно показывает, насколько значимы ИТ для бизнеса и задает контекст для трактовки остальных показателей. Если возможно, хорошо бы взглянуть на метрику в первую очередь.
Почему важен
Как измерять
- Определить общие операционные затраты, включая оплату труда ИТ-персонала, амортизацию ОС (основные средства) и НМА (нематериальные активы), оплату труда ИТ-персонала, оплаты по договорам оказания услуг и прочие операционные затраты (расходные материалы и малоценные активы).
- Поделить на общие операционные затраты организации.
Как использовать
- Рассчитать долю затрат на персонал. По нашему опыту, при численности персонала 150-500 человек, ожидаемые значения – 25-50%. То есть зарплаты ИТ-специалистов могут составлять четверть всех ИТ-затрат предприятия. Когда речь о цифре порядка полумиллиарда, это создает совсем другой уровень интереса к анализу того, как построена работа этих специалистов и как ее сделать эффективной (процессные метрики, персональные KPI, система мотивации).
- Рассчитать долю затрат на амортизацию оборудования. Наибольший интерес представляет не сама доля затрат (по нашему опыту, она колеблется в широком диапазоне 8-32%), а объем неутилизированных мощностей. Значения выше 12% должны настораживать. Коридор “нормальных” значений – 8-12%. Все, что ниже, означает огромные успехи в оптимизации использования ресурсов (менее вероятно) или неточное выполнение аллокации ИТ-затрат (более вероятно).
Уровень доступности
Доступность – первое, что приходит в голову, когда говорят о качестве ИТ-услуг. Уровень доступности – важнейший показатель потому, что отражает, как много бизнес теряет (точнее: может потерять) в связи со сбоями ИТ. Особенно важно, что ИТ-организация умеет измерять, оценивать и отчитываться о доступности ИТ-услуг.
Почему важен
Как измерять
Процент доступности – общепринятый показатель для измерения надежности ИТ-инфраструктуры, но он не годится для измерения доступности ИТ-услуг, предоставляемых ИТ-подразделением организации.
Первая сложность связана с обсуждением показателя. Доступность определена как 99,9%. Вроде неплохо. Но 0,1% в год равен почти 9 часам (при режиме эксплуатации 24×7). А в месяц – это почти 45 минут. А в неделю – чуть более 10 минут. Так какие 99,9% имел в виду бизнес-заказчик? А ИТ-менеджмент?
Однако значительно более существенен следующий нюанс: показатель довольно неточно отражает негативное влияние на бизнес. Что если все без малого 9 часов за год случились разом? Или услуга становилась недоступна потребителям по две минуты, но 15 раз за один день? Как это будет выражено в процентах?.. Поэтому, например, ITIL вводит такие показатели, как MTRS (Mean time to restore service), MTBF (Mean time between failures).
Вернемся в начало координат и зададимся вопросом: зачем мы вообще вводим показатели доступности? Почему бизнес предъявляет требования к доступности услуг? Почему сервис-провайдер должен обеспечивать высокую доступность и отчитываться по ее фактическим значениям? Ответ прост: бизнес несет потери вследствие простоев ИТ-услуг. Значит, идеальным для бизнеса показателем доступности, вероятно, была бы метрика «Потери вследствие простоев ИТ-услуг»?
Произвести расчет такой метрики возможно в основном для ИТ-услуг, непосредственно связанных с получением прибыли (продажи, кредитный конвейер и так далее). Таким образом, мы должны определить другие показатели, не забывая о том, что в совокупности они должны нести информацию о бизнес-влиянии (фактическом или потенциальном).
От чего зависят потери бизнеса вследствие простоев?
- Чем меньше за отчетный период услуга была в uptime, тем больше потери. Используем показатель «Суммарное время простоев».
- Чем дольше разовый простой, тем больше потери. Нередко потери не являются постоянной во времени величиной и зависят от длительности прерывания экспоненциально. В первый отрезок времени ущерб складывается из несовершенных транзакций, потерь продуктивности персонала и затрат на восстановление, но с определенного момента длительный простой угрожает бизнесу штрафами, санкциями, уроном репутации и так далее. Об этом расскажет показатель «Максимальный разовый простой».
- Ряд бизнес-процессов, напротив, «чувствительны» не к единичным длительным простоям, а к частым прерываниям. Это особенно важный фактор для процессов, в рамках которых происходят длительные вычисления, которые в случае прерывания требуется перезапускать. Таким образом, должно быть обеспечено как можно меньшее количество прерываний за период. Не лишним будет показатель «Количество нарушений».
Альтернативной (или дополнительной) метрикой, отражающей тот же аспект, но с акцентом на периоде спокойной работы пользователей, может быть показатель «Минимальная (или средняя) продолжительность работы без нарушений».
Итого, в зависимости от ИТ-услуги возможно использовать один или несколько показателей:
- Суммарный показатель простоев
- Максимальный разовый простой
- Минимальная продолжительность работы без нарушений
- Кол-во нарушений за период
Как использовать
Нередко для оценки деятельности ИТ-департамента показатели доступности услуг агрегируют для расчета общего KPI. Но чтобы получить представление о том, как ИТ справляется с управлением доступностью, нужно смотреть на них в “развернутом” виде – для этого будет достаточно взгляда га нескольких (до 5-6) ключевых ИТ-услуг, которые обеспечивают функционирование бизнеса, за 3-4 месяца. Особое внимание нужно уделить трендам и единичным провалам – они зададут направления для следующих шагов.
Incident rate
Incident rate также характеризует надежность ИТ. В отличие от уровня доступности он значительно менее требователен к средствам измерения и методике оценки (если есть ITSM-система, в которой регистрируются инциденты).
Кроме того, метрика косвенно показывает, насколько реактивно ИТ-подразделение и сколько ресурсов тратит на «тушение пожаров» вместо плановой работы.
Почему важен
- показывает, насколько надежны применяемые ИТ-решения
- показывает, сколько ресурсов тратится на «тушение пожаров»
Как измерять
Incident rate = количество запросов категории «Инцидент», поступивших за один месяц, в расчете на одного активного сотрудника организации – пользователя ИТ.
Лучше брать выборку за год в разбивке по месяцам, чтобы исключить сезонность. Из пользователей лучше исключить уволенных сотрудников и различные технические учетные записи.
Значение показателя может сравниваться с отраслевой статистикой. Она показывает, что значения этой метрики колеблются в довольно узком диапазоне – 0.4 – 2.3. Причем данный диапазон слабо зависит от размера организации и в основном определяется отраслью (например, в банках значения выше, чем в энергетике). Отраслевая специфика – это следствие влияния сложности применяемых информационных технологий и частоты их изменений.
Как использовать
- анализ потока, чтобы, например, определить ориентиры по повышению доступности за счёт сокращения текущего (известного) количества инцидентов
- прогноз потока, чтобы оценить количество инцидентов при организации процесса управления инцидентами
Своевременность обработки запросов
Метрика связана с ключевым обязательством ИТ-департамента перед бизнесом. В организации может не быть каталога услуг и SLA, но целевое время решения запросов пользователей задано и отслеживается везде. Решение запросов пользователей связано с коммуникацией, поэтому своевременное и результативное решение пользовательских запросов в существенной степени формирует общее восприятие ИТ.
Почему важен
- ключевое обязательство ИТ-департамента перед бизнесом
- значимый фактор удовлетворенности работой ИТ
Как измерять
На первый взгляд, своевременность обработки запросов измерить несложно: количество своевременно обработанных запросов нужно поделить на общее количество запросов, обработанных за некоторый период времени.
Однако за простотой этой формулы скрывается существенный недостаток – такое определение метрики своевременности не учитывает, на сколько был нарушен срок обработки запроса. Обычно пользователю не все равно, был ли его запрос просрочен на 5 минут или на неделю.
Отразить в метрике, насколько нарушен срок, можно следующим образом: количество своевременно обработанных запросов поделить на коэффициент Wi (вместо общего количества запросов). При этом Wi:
- равен 1, если i-ое обращение решено в срок
- равен ti/Ti, где ti – фактическое время решения i-ого обращения, Ti – нормативное время решения, если обращение просрочено
Тогда чем сильнее просрочен i-тый запрос, тем больше его вес Wi, снижающий значение метрики (поскольку ti > Ti).
Как использовать
Оценить показатель для процесса в целом.
Оценить показатели TPI для групп поддержки – определить, какие группы поддержки являются узким местом процесса. Проанализировать возможные причины низкой своевременности решения.
Оценить «хвост» – количество нерешенных обращений в предыдущем периоде, перешедших в текущий.
Первый показатель, который мы предложили, – доля ИТ-затрат – касается роли ИТ в бизнесе организации. Последующие три – уровень доступности, Incident Rate, своевременность выполнения обращений – касаются эксплуатации. Следующие три показателя – про развитие.
Доля численности ИТ-персонала в развитии
Метрика доли ИТ-затрат показывает роль ИТ в бизнесе в целом. Метрика ‘Доля численности ИТ-персонала в развитии’ уточняет, насколько много ресурсов компания тратит на развитие информационных технологий. И соответственно, какое внимание ей следует уделять применению релевантных подходов и их развитию (agile, devops и так далее).
Почему важен
Показывает, насколько важна разработка для организации.
Как измерять
Если компания работает в режиме инсорсинга, расчет может быть проведен через численность персонала – как доля персонала в подразделениях развития в общей численности ИТ-персонала организации. Компании, делающих ставку на ИТ, и особенно в ИТ-зависимых областях (банки, ритейл) склонны возвращать разработчиков в инсорс, поэтому такой расчет для них может быть приемлем.
В ситуации активного использования аутсорса корректнее оценивать этот показатель через долю затрат на разработку от общих затрат ИТ-подразделения по ФОТ и услугам.
Как использовать
Если есть возможность, сравнить со значениями данного показателя с референсными компаниями (например, основными конкурентами или с компаниями-ориентирами). В компаниях с серьёзной внутренней разработкой данный показатель имеет значения 50-60% и выше.
Размер бэклога (разработки)
Если компания прикладывает значительные усилия на развитие, то следующая метрика, на которую имеет смысл посмотреть, – это величина бэклога, очереди запросов, которые требуют реализации силами разработчиков.
Почему важен
Как измерять
Наилучший способ оценить очередь – посчитать суммарный объем трудозатрат на реализацию запросов на изменения во входной очереди. Такой показатель расскажет, сколько дней (недель, месяцев) займет реализация уже принятых запросов, если прием новых запросов прекратить (при неизменных ресурсах).
Если существенная доля запросов на изменения не имеет оценки трудозатрат, можно выполнить приблизительную оценку как произведение количества запросов на изменение в бэклоге на средние трудозатраты по одному запросу (на основании данных прошлых периодов).
Чем выше показатель, тем меньше ресурсное обеспечение разработки соответствует спросу внутренних заказчиков организации. Значения больше трех месяцев могут означать нехватку ресурсов и/или скорости реализации, которая определяется продуктивностью разработчиков.
Чтобы сделать корректные выводы на основании величины бэклога, целесообразно сразу пойти немного дальше и выполнить анализ задач в бэклоге:
- По видам (развитие, тех. долг, …)
- По группам исполнителей
- По этапу обработки (входная очередь на оценку, выходная очередь на реализацию)
- По «возрасту» (например, задачи с возрастом более года могут уже утратить свою актуальность)
Если существенная доля запросов на изменения не имеет оценки трудозатрат, полезно провести анализ практики / скорости оценки запросов в бэклоге.
Доля времени разработчиков на эксплуатацию
Чем менее качественный код, тем больше разработчикам приходится отвлекаться на эксплуатацию и в частности поддержку. Мы уже ввели выше показатель Incident Rate, который помимо прочего показывает, насколько много ресурсов компания направляет на “тушение пожаров”. Этот показатель уточняет, как много разработчиков в составе “пожарных бригад”.
Почему важен
Маркер качества разработки и способности разработки решать новые запросы, не занимаясь текущими вопросами эксплуатации.
Как измерять
Для расчета метрики нужно выделить трудозатраты разработчиков за некоторый период времени на развитие (анализ и реализацию новых запросов на изменения) и поделить на общий бюджет рабочего времени разработчиков за тот же период времени.
Как использовать
Дальнейшие действия могут включать в себя:
- Анализ показателя в разрезе по группам исполнителей
- Анализ корреляции с размером бэклога в разрезе по группам исполнителей
- Изучение видов и трудоёмкость работ, на которые отвлекаются разработчики
Мы рассмотрели еще три показателя, которые касаются разработки. Наконец, перейдем к заключительному показателю, который покажет насколько результативны усилия ИТ-департамена с точки зрения потребителей.
Удовлетворенность потребителей услуг
Заключительный показатель в списке, который показывает итоговое восприятие работы ИТ-подразделения – насколько ИТ соответствуют тем ожиданиям, которые есть у потребителей ИТ-услуг организации.
Почему важен
Показывает ИТ глазами потребителей услуг.
Как измерять
- Средний балл по результатам опроса потребителей услуги
- Количество или доля пользователей, которые не продлили подписку после пробного периода
- Коэффициент оттока клиентов (процент потребителей, которые перестали потреблять услугу за отрезок времени)
- Индекс готовности рекомендовать (NPS – Net promoter score) – отражает лояльность потребителей и как много из них “работают” агентами услуги
Так или иначе, оценку удовлетворенности можно получить из целевого опроса или путем извлечение информации из текущей оперативной деятельности – в зависимости от отношений бизнеса и ИТ и доступных данных уместно использовать один или другой или оба способа.
Как использовать
- Я понимаю, как работать в информационных системах, в том числе после обновлений функциональности. Проводится обучение, инструкции и руководства содержат ответы на мои вопросы.
- Мне легко найти на портале нужную категорию заявки.
- В случае обращений в поддержку сотрудники ДИТ обычно делают все возможное, чтобы помочь.
- Как правило, мне понятно, за какое время будет решена моя заявка.
- Как правило, меня устраивает время решения заявок.
- …
Проанализировать связь между низкими оценками конкретных групп потребителей и:
- Уровнем качества предоставляемых их услуг, в первую очередь уровнем доступности
- Уровнем поддержки по соответствующим категориям обращений, в первую очередь своевременность решения обращений
- Функциональностью систем, в которых работает группа пользователей
Мы рассмотрели восемь основных показателей, которые помогут получить первое впечатление от ИТ-департамента. Напомним, что на их основе некорректно делать выводы об качестве работы ИТ или эффективности менеджмента – они лишь расставляют акценты и намечают дорогу для дальнейшего анализа. Это дорогу мы постарались наметить.
Все показатели можно сгруппировать следующим образом. Естественный, но не обязательный порядок анализа:
- Значимость ИТ для организации: доля ИТ-затрат в общих операционных затратах организации
-
Разработка: доля численности ИТ-персонала в развитии, величина бэклога, доля времени разработчиков на эксплуатацию
-
Эксплуатация и поддержка: уровень доступности, Incident Rate, своевременность обработки запросов
-
Результаты ИТ: удовлетворенность потребителей ИТ-услуг
Восемь – не какая-то волшебная цифра, каждую группу показателей можно дополнить для получения более детальной и точной картины (например, блок “Результаты ИТ” можно дополнить метрикой, связанной с успешностью проектов, а в “Эксплуатацию и поддержку” также включить метрики производительности и непрерывности). И напротив, если для расчета показателя данные недоступны, метрику соответствующей области можно заменить интервью или экспертной оценкой. Помните, что измерения и метрики – не единственный инструмент управленца, хотя, как правило, выводы, сделанные на основе цифр заслуживают большего доверия.
Мне кажется хорошо справился с метриками COBIT2019. Introduction and
Methodology, 4.6.2 Alignment Goals. Там же список всех метрик.
Metrics for IT Service Management, Peter Brooks. Есть переведенная версия,. Это для тех кто метит глубже.