Продолжаем публикацию материалов по измерению процесса управления инцидентами. Чтобы предотвратить «футбол» (быстрое, бездумное перекидывание инцидентов в другие группы) плюс к метрике своевременности (которая бурно обсуждалась в заметке «Измеряем Incident management») нужна вторая метрика – результативности. О ней и поговорим в этой заметке.

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

• её трудно связать с группой специалистов. В самом деле, после возврата на доработку инцидент фактически мог быть решён другой группой – не той, которая отрапортовала о неверном решении и привела к возврату на доработку;
• эта метрика учитывает только передачу решения заявителю, но не учитывает внутренние передачи инцидентов между группами ИТ. Однако внутренние передачи инцидентов также могут быть нерезультативными, то есть увеличивать общее время обработки.

Для преодоления этих недостатков необходимо выполнять расчёт не по записям инцидентов, а по истории их обработки рабочими группами. Тогда по каждому решённому за период инциденту можно посчитать, сколько раз та или иная группа участвовала в его обработке. Если участвовала больше одного раза, значит инцидент передавался этой группе повторно. Значит, с первого раза была сделана не вся необходимая работа.

Тогда по каждой из групп метрику результативности можно представить в виде:

где  – KPI группы по результативности обработки инцидентов;

N – общее количество инцидентов, решённых за период (с участием данной группы);

M – количество инцидентов, потребовавших повторной обработки силами данной группы.

Как обычно, метрика нормирована в диапазоне [0; 1]: 1 – отлично, 0 – наихудший результат.

ВАЖНО. Данная метрика применима только при соблюдении следующих условий:

• процесс должен использовать переназначение инцидентов только для функциональной эскалации. В моей практике встречались и другие случаи. Вот некоторые примеры:
  • возврат на Service Desk при передаче решения пользователям;
  • возврат группе, отвечающей за прикладное ПО, после устранения инцидента в базовой инфраструктуре;
  • последовательное переназначение инцидента (или обращения пользователя), требующего выполнения работ силами нескольких групп;
• при возврате инцидента на доработку (отказ пользователя) он должен изначально попадать на обработку той же группе, которая сообщила о решении (встречал случаи возврата на Service Desk, что лично мне кажется не очень логичным).

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

P.S. В следующей заметке я вернусь к тому, как из нескольких метрик (в нашем примере – метрики своевременности и результативности) можно сделать один KPI. И если Вы сразу готовы предложить среднее арифметическое, не спешите 😉

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Построение системы KPI для ИТ

Как обеспечить управление процессами, проектами, услугами, персоналом