Летом этого года в Санкт-Петербурге на конгрессе ИТ-директоров «Белые ночи» Дмитрий Иншаков, директор по ИТ PricewaterhouseCoopers, провел сессию, посвященную практике использования ИТ‑метрик. В ней приняли участие в том числе Николай Крачун из фирмы «Санта-Хаус», Сергей Энгель из «Дельта Телекома», Юрий Близгарев из Unilever, Роман Журавлев из компании IT Expert. В настоящей статье представлена часть этого обсуждения.

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

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

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

Модель и методологическая поддержка

Как подходить к получению метрик и какую методологию использовать? Никто из экспертов, присутствовавших на секции, не стал спорить, что невозможно использовать какую‑либо готовую методологию для построения собственных метрик. Согласились все и с тем, что одну часть известных методологических книг написали люди, у которых, прибегая к автомобильным аналогиям, руль справа, а другую — у которых слева. И при том, что определенное соответствие между теми и другими есть, ни о какой системности и целостности здесь говорить не приходится. Не существует и такой книги, в которой было бы написано, как это можно сделать. Например, участники согласились, что известная работа Питера Брукса «Метрики для управления ИТ-услугами» (вышла в серии «Библиотека IBS» в издательстве «Альпина Бизнес Букс», 2008 г.) такой книгой точно не является, хотя и рекламируется как «общее руководство по проектированию, созданию и использованию метрик и KPI».

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

Какие бывают метрики?

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

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

Метрики должны быть выстраданы

Сергей Энгель выступил на сессии в качестве оппонента-практика, далекого от теоретического увлечения метриками: «Все компании разнятся по масштабу и сфере деятельности. Любая стандартизация, и метрики здесь не исключение, имеет смысл только тогда, когда речь идет о каком‑то многократно повторяющемся процессе. Мы далеко не самая маленькая организация, в нашей ИТ‑службе работает сорок человек, но я постоянно сталкиваюсь с тем, что детально расписанные в книгах методики созданы для компаний масштаба General Motors. Если у меня функцию, расписанную в книге на двадцати листах, да еще с девятью подфунк­циями, выполняет всего один человек, а полтора человека отвечают за два тома методологии, то поневоле начинаешь рекомпозицию, соединяешь все это детальное описание в более крупные блоки, чтобы понять, как это происходит лично у тебя. То же самое и с метриками. Это должно быть выстрадано, а не насаждаться сверху методологиями». Тем не менее определенные родившиеся из практических нужд метрики Сергей Энгель все‑таки использует: «Там, где имеются любые количественные измерения, которые легко можно провести автоматически, метрики возникают сами собой. Например, у нас есть центр обслуживания абонентов, куда поступают звонки. Образуется очередь входящих вызовов, фиксируется число тех, что обработаны и сброшены, по этим данным строятся графики. С другой стороны, в ИТ‑службе у нас уже несколько лет есть Help Desk, но в нем никаких особых замеров не производится. Максимум, что реализовано, это контроль на стороне менеджера количества проблем, решенных на первом уровне и переданных на вторую линию поддержки.

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

В защиту метрик высказался Дмитрий Иншаков: «Очевидно, что метрики необходимы топ-менеджменту крупной компании для принятия обоснованных управленческих решений. Но ведь от правильно выбранных метрик есть польза, к примеру, и менеджеру Service Desk. В частности, в случае появления каких‑либо жалоб или проблем метрики пригодятся для того, чтобы аргументированно показать, как обстоят дела в действительности. Представьте, что службой поддержки принято 98% звонков (что в целом является хорошим показателем), но в оставшиеся два процента, к несчастью, попали звонки от генерального директора. В этом случае метрики помогут убедить его в том, что служба Service Desk работает совсем не так плохо, как может показаться на первый взгляд. Автоматически формируемые системой числовые значения, которым доверяет бизнес, позволят ИТ-менеджеру убедить высшее руководство в том, что на самом деле работа службы четко находится в рамках заключенных SLA».

Плавающие параметры

Для того, чтобы показать еще одну проблему при создании метрик, Роман Журавлев задал собравшимся вопрос о магазине с десятью кассами: сколько касс должно не работать, чтобы можно было точно понять, что услуга «касса» не предоставляется? Типичный слушатель курсов ITIL ответит: десять. Это нормальный айтишник, а бизнесмен скажет, что ответ зависит от текущей длины очередей и количества покупателей. Конечно, ответ не будет всегда «одна». Одна — это случай предновогодней торговли. Возможно, ответ действительно будет «десять», если мы рассматриваем дежурный магазин в центральном районе жаркой июльской ночью. Разумеется, это плавающий параметр, который зависит от времени. Но где вы видели такие договоренности об уровне обслуживания, в которых все это было бы описано, а потом еще занесено в регистрирующую инциденты программу, позволяющую нам измерить доступность исходя из полученных данных? Подобные интегральные показатели по сервисам — это действительно огромная проблема, решение которой можно представить теоретически, но в реальной жизни, к сожалению, требуется либо ручная обработка, либо определенная степень приближенности.

По мнению Романа Журавлева, с использованием результатов социологических опросов в качестве метрик проблем не существует: результаты опросов, как и любых измерений, — это данные, которые могут быть входом для оценки и могут рассматриваться как трактуемая метрика, но только после того, как они будут пронормированы. Это справедливо не только для соцопросов, это общий принцип. Безусловно, в качестве метрики можно применить показатель удовлетворенности пользователей, полученный в результате опроса. В него можно заложить вопросы, касающиеся пожеланий к службе поддержки, к появлению новых процедур. Можно снять любые связанные с пользователями параметры и определить для них уровень удовлетворенности. ИТ-руководители тоже вольны выбирать детализацию, их может интересовать как сервис в целом, так и отдельные процедуры. Можно использовать в качестве метрики интегральный показатель, а можно — очень детальный. Если для примера взять анкету в гостинице, то в ней очень много параметров, по которым можно оценить удовлетворенность пользователей. Вопрос лишь в цели измерения. Требований к опросу всего три: методы сбора данных должны быть опробованы и утверждены; анкеты должны быть отсортированы, т. е. отброшены подозрительные; необходимо провести консолидацию итоговых значений. Вот эти значения и могут быть метриками, а не сами заполненные пользователями анкеты.

Работа на метрики

В заключение сессии Сергей Энгель сказал еще об одном внушительном подводном камне, который усложняет и без того непростую работу с метриками: «Как только организация вводит метрики и применяет их для оценки заработной платы специалистов, ее сотрудники сразу начинают работать именно на метрики, а не на решение реальных задач. Встает проблема контроля показателей работы. Могу привести в пример отлично отстроенную систему, которую видел сам. Довольно быстро стало понятно, по какому принципу там происходила эскалация проблемы в европейскую штаб-квартиру, — для конкретного менеджера это был просто способ закрыть trouble ticket, проблему. У него ведь согласно метрикам определены временные рамки ответа.

Если проблема сложная, то менеджер технической службы поддержки тут же отвечает пользователю практически пустым электронным письмом. Да, в системе появляется галочка, что ответ пользователю отправлен. Но ведь совсем не это нужно заказчику, а вот специалисту нужна галочка, потому что иначе у него уменьшится заработок. Через месяц этот же сотрудник начинает прилагать все усилия к тому, чтобы данную проблему перевести в какую‑нибудь новую, т.е. закрыть существующий trouble ticket и открыть новый. В том примере, о котором я говорю, за два года работы такая система выстроилась очень четко. Получается, что если смотреть не за реальной работой персонала, а только на цифры метрик, не вникая в существо проблемы, то самая прекрасная метрика перестает работать. Для того, чтобы обойти эту проблему, в идеале руководитель должен беседовать с заказчиком по душам».