В подготовленном компанией Forrester докладе Develop Your Service Management And Automation Balanced Scorecard (“Развивайте сбалансированную систему показателей управления сервисными услугами и автоматизацией) я обнаружил несколько наиболее распространенных ошибок, совершаемых при создании и внедрении системы показателей (метрик) в ИТ-организациях, ответственных за инфраструктуру и операции (I&O). Неадекватность этих показателей — известная проблема, однако все еще существует большое количество I&O-организаций, не осознающих, что, возможно, у них используется неверная система показателей. Итак, давайте обсудим следующее.
1. Когда дело касается применения метрик, I&O-организация не всегда полностью понимает, что именно делается и почему. Мы часто создаем метрики, поскольку чувствуем, что просто “должны” это делать, а не потому, что имеем серьезные основания для сбора и анализа данных и сравнения реальной производительности с запланированной. Спросите себя: “Для каких целей мы хотим или требуем внедрения системы показателей?” Соответствуют ли этим целям применяемые сейчас у вас метрики? Если нет — вы не одиноки.
2. Метрики часто рассматриваются как результат сам по себе. Слишком много I&O-организаций воспринимают данные метрик как окончательный результат, а не как исходные данные для каких-то дальнейших действий, таких как обсуждение шагов по улучшению качества сервиса или повышению производительности. Системы показателей становятся корпоративной игрой, где имеет значение только выполнение или превышение заданных значений. Отчеты с метриками должны давать более полную картину и побуждать к повышению эффективности работы.
3. I&O-организации используют слишком громоздкие системы показателей. Инструменты ITSM (IT Service Management — управление ИТ-услугами) генерируют огромное число отчетов и данных, что невольно подталкивает сотрудников I&O-структур к чрезмерному расширению числа анализируемых показателей зачастую в ущерб качеству анализа. Если у нас есть возможность измерить что-либо, это еще не означает, что мы должны это делать, и даже если мы будем что-то измерять, нам не всегда надо публиковать отчет о результатах. Те метрики, которые мы выбираем для распространения, должны непосредственно содействовать пониманию того, достигли мы требуемых значений производительности и необходимых результатов или нет.
4. Мы часто измеряем параметры только потому, что их легко измерить, а не потому, что их значения важны для понимания общей ситуации. I&O-организации не должны тратить больше времени на сбор и публикацию метрик, чем на анализ их значений, однако это не оправдание для измерения только наиболее очевидных вещей. Наличие данных и отчетов о работе системы снова приобретает значение, а вся информация о производительности может быть выгружена из инструментов ITSM практически без каких-либо препятствий. Задайтесь вопросом, зачем вы публикуете все без исключения метрики в текущем отчете, и попробуйте оценить пользу этой публикации по сравнению с затратами на получение и внесение этих данных в отчет. Вы не только заметите наличие метрик, которые вы публикуете просто потому, что это возможно (“они уже были в отчете”), но и найдете показатели, весьма трудные для измерения и при этом либо приносящие очень мало пользы, либо не приносящие ее вообще (“их публикация представлялась ранее неплохой идеей”).
5. I&O-организации могут легко попасть в ловушку, фокусируясь на анализе ИТ-показателей, а не бизнес-метрик. Часто существует определенный разрыв между задачами и операциями ИТ и целями, требованиями и условиями, формулируемыми бизнесом. Теперь рассмотрите существующую у вас систему показателей с точки зрения бизнеса. Что действительно значит тот факт, что в месяц регистрируется 4000 инцидентов? С точки зрения управления сервисом это может означать, что ИТ-служба интенсивно работает, а может быть, что число инцидентов в этом месяце на 10% выше (или ниже), чем в предыдущий период. Но насколько интересно бизнесу знать точное число инцидентов? И если интересно, какой вывод делает бизнес из этого показателя: “Вы там в ИТ делаете массу ошибок” или “В этом месяце вы помогли бизнесу избежать проблем 4000 раз”?
6. Между метриками не существует сходства в структуре или контексте. Метрики могут тонуть в объемах вместо того, чтобы представлять ситуацию в комплексе, а между показателями различного типа может отсутствовать корреляция или взаимосвязь. Хорошим примером может служить воодушевление по поводу факта снижения такого показателя, как “затраты на отдельный инцидент”, в то время как более детальное изучение других метрик может показать, что этот показатель изменился не в результате повышения эффективности работы ИТ-службы, а в связи с увеличением числа инцидентов за данный период относительно средних значений.
7. Мы применяем одномерный подход к метрикам. Например, I&O-организации могут ограничиться ежемесячной оценкой производительности, а не изучать тенденции изменения показателей от месяца к месяцу, от квартала к кварталу или даже от года к году. Так что даже если кажется, что I&O-организация достигла своих целей, заданных на данный период, реально в работе компании могут быть скрытые проблемы, поскольку падение производительности становится заметным лишь при анализе данных за продолжительное время.
8. Иерархия метрик не проста. Многие не до конца понимают следующие обстоятельства:
8.1. Не все системы показателей равнозначны — существуют различия между метриками, KPI, CSF и стратегическими целями.
8.2. Необходимо различать метрики по нескольким факторам, таким как уровень иерархии, получатели и полнота их использования. Различные пользователи будут по-разному использовать различные метрики, поэтому стандартный отчет не сможет подойти для применения во всех случаях. Как и при составлении других отчетов, здесь необходимо предлагать людям только требующуюся им информацию в нужный для них момент времени и в формате, наиболее удобном для понимания. Если ваши метрики не помогают в принятии решений, то вы можете столкнуться с одной или с несколькими из перечисленных проблем.
9. Мы уделяем слишком много внимания результатам I&O-тестов. Возможность сравнить себя с другими I&O-организациями поможет вам продемонстрировать сверхвысокую эффективность своей работы или оправдать расходы по ее улучшению. Однако методика и результаты расчетов часто обманчивы: может оказаться, что происходит сравнение яблок с апельсинами. Известны два замечательных примера такой некорректности: “затраты на решение проблемы” (cost-per-incident) и “решенные проблемы в час на одного специалиста службы поддержки” (incidents handled per-service-desk-agent per-hour). При расчетах “затрат на решение проблемы” часто бывает непонятно, какие именно расходы были включены в расчет совокупных затрат, а какие нет. Объем, тип и модели появления проблем также влияют на результаты расчетов. Профиль проблем будет сказываться и на результатах расчета показателя “решенные проблемы в час на одного специалиста службы поддержки”.
10. Отчеты по системе показателей зачастую плохо составлены и выполнены. I&O-профессионалы проводят больше времени, собирая данные, чем продумывая наилучший способ их оформления и предоставления пользователям. Это похоже на систему коммуникаций ради коммуникаций, в которой отосланное сообщение может не всегда точно совпадать с сообщением, принятым и понятым адресатом. Кроме того, можно сделать метрики и отчеты более интересными, чем сейчас.
11. Мы упускаем из виду поведенческие аспекты метрик. На более высоком уровне мы готовимся к неудаче и награждаем себя, если она происходит, — мы задаем такие показатели, как уровень надежности 99,9%, вместо того, чтобы заявить: “Мы будем стремиться к 100%-ной надежности, и этот показатель никогда не опустится ниже 99,9%”. На индивидуальном уровне или уровне команды метрики могут спровоцировать неадекватное поведение сотрудника, заставив его действовать в личных целях в ущерб корпоративным интересам. Метрики также могут конфликтовать друг с другом и по-разному ориентировать I&O-специалистов. Хорошим примером может служить противоречие между двумя распространенными метриками работы службы техподдержки: средним временем обработки запроса (average call-handling time) и коэффициентом решения проблемы (или вопроса клиента) при первом обращении (first-contact resolution). Высокий результат с точки зрения одной метрики неблагоприятно отразится на оценках работы с точки зрения другой, поэтому для I&O-специалистов анализ командной или индивидуальной производительности с помощью только одной из них несет потенциальную опасность для управления операциями и оказанием ИТ-услуг.
12. I&O-организации могут почувствовать ограничения со стороны существующих метрик. Когда ваша организация постоянно достигает намеченных целей, наиболее распространенной реакцией является увеличение числа и масштаба целей. Но это необязательно правильный подход. Вместо этого руководителям I&O-служб следует рассмотреть оправданность использования системы показателей в принципе — действительно ли они помогают повышать добавочную стоимость. Иногда правильным выходом может быть полная отмена той или иной метрики и замена ее показателем, лучше отражающим текущие задачи бизнеса и любое наблюдаемое повышение или снижение производительности.
13. Неверное толкование метрик может приводить к неправильной оценке эффективности ИТ-службы. Хорошим примером может служить число запросов пользователей. Снижение их числа обычно подается как благоприятная тенденция, так? Однако это не всегда верно. Рассмотрим такой случай: служба техподдержки предлагает клиентам столь низкий уровень сервиса, что число запросов начинает сокращаться, поскольку все большее число пользователей приходит к мысли о бесполезности обращения в службу за помощью. Сотрудники либо пытаются решить проблему самостоятельно, либо ищут обходной путь, чтобы продолжить работу без решения проблемы. Наоборот, ИТ-служба с высоким уровнем обслуживания пользователей может отмечать рост обращений за помощью, поскольку все больше людей начинает обращаться в нее со своими проблемами. Таким образом, для точной оценки эффективности работы службы техподдержки руководители I&O-служб должны рассматривать показатели удовлетворенности пользователей параллельно с анализом числа обращений.
И наконец, подумайте вот над чем: как мудро заметил Айвор Мак-Фарлейн из IBM, “если мы используем неверную систему показателей, не затрудняем ли мы нашу работу над неверными вещами”?
