Портал №1 по управлению цифровыми
и информационными технологиями

Контрольные показатели и метрики

Опубликовано 9 августа 2011
Рубрики: Измерение и оценка ИТ
Комментарии

И снова про метрики и иже с ними…:) Недавно, обсуждая создание системы метрик с заказчиком, получили очень интересный посыл от владельца процесса. Суть его высказываний сводилась к следующему: «Мне неинтересно, какие метрики вы разработаете и сколько их будет. Мне важно понимать одну простую вещь – хорошо работает процесс или плохо». Это заставило меня задуматься о том, а насколько правильную картину мира мы рисуем для менеджера и владельца процесса. Не секрет, что в каждом процессе по-хорошему бы должна быть процедура контроля, оценки и совершенствования. Что есть контроль? «Способ управления Риском, обеспечивающий достижение Бизнес-целей или соблюдение правил и процедур Процесса.» (ITIL® V3 Glossary Russian Translation v0.92, 30 Apr 2009). То есть фактически некая система наблюдений и проверки функционирования объекта управления на предмет соответствия каким-либо правилам. Для того, чтобы можно было наблюдать и проверять – нужны контрольные показатели. На мой взгляд, контрольные показатели просто обязаны иметь целевые значения, иначе это не контрольные показатели :). То есть правила, на соответствие которым мы производим проверку, должны быть «трансформированы» в понятный язык контрольных показателей. Например, «Оперативность устранения нарушений в предоставлении ИТ-услуг».И, естественно, понимать, что мы будем считать под «оперативно» и «не очень». Для того, чтобы с помощью контрольных показателей производить оценку, нужны метрики, с помощью которых мы непосредственно производим измерения. Например, в нашем случае вышеприведенный показатель могут формировать 2 метрики: «Общий % инцидентов, решенных в срок» и «Среднее время решения инцидентов». То есть если с контрольным показателем связано больше, чем одна метрика – то контрольный показатель это некая функция. В нашем случае нам придется свести к единому «знаменателю» проценты и время :). «Картина мира», правильно нарисованная с помощью контрольных показателей – практически неизменна (нам не надо в случае изменения процедур процесса, целей и задач менять контрольные показатели, в отличие от метрик). На мой взгляд, контрольных показателей не должно быть слишком много – и такую картинку очень хорошо демонстрировать владельцу процесса, для которого излишняя детализация не нужна (это к вопросу о том, хорошо или плохо работает процесс). А вот для менеджера такой картины будет недостаточно – ему как раз нужна система метрик, чтобы понять, в каких областях нужно прилагать дополнительные усилия. А как вы думаете?

Комментариев: 23

  • Пример бы хоть какой, чтобы понять о чём идёт речь…

  • Дим, там их целых 2, разве нет? 🙂 Нет примера функции, ну уж извините 🙂

  • Миш, а нельзя ли поступить проще, в отношении таких “владельцев”?

    Один раз обговорить принцип, по которому 90% закрытых вовремя заявок – это “хорошо”, а 98% – “отлично”. Нафиг функции.

    Тогда весь отчёт – это одна страницы из зачётки, за семестр)

    • Нет, ну то есть сердцем то я понимаю, что ты собственно, об этом же. Меня просто такие владельцы устают быстро.

    • А это, как говорится, зависит 🙂 В некоторых случаях может быть и можно. Но вот конкретный пример – заказчику нужно было оценивать работу старших функциональных групп, ибо с этим были проблемы. Измерение проводилось с помощью 3 метрик, да еще и учитывалось то, что старший группы мог “рулить” несколькими функциональными группами. В результате все это свели в контрольный показатель (пришлось использовать функцию), по которому и оценивались старшие групп. Контрольный показатель – один. Метрик – несколько.

      • Т.е. отличие от контрольного показателя от метрик – только в том, он объединяет в себе несколько метрик? А если бы работа какой-либо роли требовала одной метрики – тогда контрольный показатель был бы нужен?

        По-моему, здесь больше речь вообще не по сути, а по терминам. Если я правильно понимаю твою идею, “контрольный показатель” – это KPI. Тогда в моём понимании всё просто:

        1. Согласен, что KPI нужны.
        2. KPI – это вид метрик. Т.е. не каждая метрика – это KPI, но KPI – это метрика, которая является индикатором работы (на основании значений можно говорить в терминах “лучше/хуже”, есть способ определения целевого значения, измеряется, как правило, в безразмерных величинах – как раз для агрегации).

        Я правильно тебя понял?

  • Павел

    Уже когда-то писал об этом.
    Я считаю, что, как правило, при внедрении процессов необходимо руководителей процессов (или иных заинтересованных лиц) учить тому, как пользоваться системой метрик.
    Примерно так:
    вот метрика “оперативность решения”, если тут ниже 85, то надо заглянуть в детализацию по группам, найти группы у которых ниже 85, посмотреть детализацию по исполнителям и провести беседу с провинившимся…

    Поскольку не всегда, а точнее очень часто руководители процессов столь инициативны и любознательны, чтобы самому продумать модель своего поведения.
    Да и к тому же не факт, что он сможет разгадать задумки консультанта, который построил эту систему метрик.

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

    • Павел, развивая вашу мысль в позитивном направлении: найдя таких талантливых людей вы им дадите дополнительную мотивацию: возможность “прокачать” свои менеджерские навыки и самореализоваться творчески в смысле выстраивания собственной системы метрик и их анализа. Одно из преимуществ которые можно заявлять заказчикам при продаже проектов 😉

    • “Да и к тому же не факт, что он сможет разгадать задумки консультанта, который построил эту систему метрик.”

      Нет такой задачи. Консультанты же не массовики-затейники, чтобы загадки загадывать 🙂 Во всяком случае, хорошие консультанты.

      • Павел

        Так консультант и не думает, что он загадки загадывает, ему-то всё понятно и кажется более чем очевидным. Это даже не вопрос хороший/плохой консультант, это особенность человеческого общества вообще.

    • “Жду сейчас в ответ вы скажете, что надо выбирать менеджеров, что это должен быть человек-кремень и т.д.”
      Павел, не дождетесь 🙂

      По поводу того, что руководителей процессов нужно учить пользоваться системой метрик и “разгадать задумки консультанта, который построил эту систему метрик” – например, в текущем проекте такой задачи у меня нет :-), потому что руководитель процесса и сотоварищи сами строят эту систему метрик. И поэтому понимают, что они измеряют, как они измеряют, и для чего это нужно. А задача консультанта состоит в другом. И тут я полностью согласен с Димой.

  • Павел

    если у заказчика будет достаточно талантливых людей, желающих прокачаться, то продажи проекта не будет, заказчик своими силами справится. 🙂

    • Я думаю, это не так. Опыт показывает, что решение о проекте принимается на основании совсем других факторов.

      Прямо сейчас, например, один наш уважаемый заказчик инициирует ITSM-проект. В его штате трудится как минимум 3 ITIL эксперта (а может и больше, я навскидку не помню). А ещё больше не ITIL экспертов, но не менее грамотных менеджеров (я знаю по крайней мере четверых). Все эти люди (и именно они) в первую очередь заинтересованы в том, чтобы получилось инициировать проект.

  • Павел

    А задача консультанта состоит в другом.
    Из вашей заметки я этого не понял. В частности, в этом меня укрепила фраза:
    Мне неинтересно, какие метрики вы разработаете и сколько их будет.

    • Под словом “Вы” подразумевался не только я, как консультант, но и члены проектной группы. Послание владельца было адресовано всем нам 🙂

  • Леонид

    Михаил, а что вы понимаете под «хорошо или плохо работает процесс», что процедуры выполняются, как написано, или что достигается цель процесса?

    • Как правило, это соответствие целевым показателям результативности (соответствие назначению, достижение каких-то краткосрочных целей) и рациональности (эффективное использование ресурсов, безошибочное выполнение процедур и т.д.)

  • Миша, обилие комментариев “вокруг темы” подтверждает, что мысль не раскрыта. Предлагаю исправляться 🙂

    • Обилие комментариев подтверждает то, что у каждого есть своя точка зрения 🙂 А свои мысли здесь постепенно раскрывают в процессе обсуждения 🙂


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM