Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

Неправильные метрики: Каких ошибок следует избегать?

Неправильные метрики: Каких ошибок следует избегать?

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

Вы не понимаете, зачем нужны метрики. Часто метрики разрабатываются, просто чтобы были, а не потому, что есть конкретные причины для сбора и анализа данных и сравнения их с целевыми показателями. Спросите себя: «Для чего нам нужны метрики?» Соответствуют ли ваши метрики этим задачам? Неудивительно, если это не так.

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

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

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

Вы используете метрики для ИТ, а не для бизнеса. Показатели работы ИТ-отдела часто отличаются от целевых показателей бизнеса. Посмотрите на существующие метрики с точки зрения бизнеса. Что означает 1000 инцидентов за месяц? С точки зрения ITSM, это значит, что вы поработали на 10% больше (или меньше), чем в предыдущем месяце. Но так ли это важно для бизнеса? Если да, то их можно интерпретировать как «Вы 1000 раз помешали нормальной работе бизнеса».

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

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

У вас нет иерархии метрик. Не все метрики равны. Есть различия между метриками, ключевыми показателями эффективности (KPI), критическими факторами успеха (CSF) и стратегическими целями. Метрики должны быть дифференцированы по их иерархии, получателям и назначению. Разные люди по-разному применяют различные метрики, поэтому один и тот же отчет не подойдет для всех. Сообщите людям то, что они должны знать, когда им это нужно и в том виде, в котором им удобно. Если ваши метрики не помогают принятию решений, с ними определенно что-то не так.

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

У вас плохо разработана структура отчетов. Часто на сбор данных уходит больше времени, чем на выбор лучшего способа представления и использования полученных данных. Это как с sms, когда фраза «сообщение отправлено» не всегда означает, что сообщение получено и понято. Постарайтесь сделать отчеты более наглядными и интересными.

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

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

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

По материалам blogs.forrester.com

Дополнительные материалы

kpi

Комментарии (0)