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

Процессная математика. Tension-метрики

Опубликовано 7 марта 2012
Рубрики: Измерение и оценка ИТ, Общие вопросы менеджмента, Управление инцидентами
Комментарии

Итак, задача. Есть две tension-метрики, из них необходимо сделать один общий KPI, который показывал бы, насколько удаётся исполнителю обеспечить баланс. Для примера возьмём предложенные метрики процесса управления инцидентами по своевременности (https://realitsm.ru/2011/12/measuring-incident-management) и результативности (https://realitsm.ru/2012/02/measuring-incident-management-2).

О каком балансе речь? Можно иметь неплохие показатели своевременности, если сразу перекидывать входящие обращения на смежников (а там жизнь покажет, можно в фоне поразбираться, вдруг и правда вопрос к нам). Однако в этом случае обращения будут возвращаться и требовать повторной обработки. Можно, напротив, разбираться «от и до», не передавать обращения (не отмечать выполнение), пока не будет 100%-ной уверенности в том, что найдено лучшее решение и оно результативно. Но такой стиль работы немного ближе к управлению проблемами, а это слишком медленный процесс, если речь идёт об устранении инцидентов. Нужен баланс – делать и быстро, и с первого раза.

Пусть K1 – метрика своевременности, K2 – метрика результативности. Нам необходимо определить K – итоговый KPI, так что K = f(K1, K2). Как определить функцию f? Первое обычно поступающее предложение – арифметическое среднее (может быть, взвешенное среднее, не важно). Но для tension-метрик – это не самый лучший вариант. Действительно, если предположить, что поведение исполнителя полностью смещено в пользу одной из метрик (например, K1 = 100%, K2 = 0%), то среднее арифметическое даст общий результат в 50%, в то время как о балансе и речи нет (одна из двух метрик просто игнорируется!).

Поэтому для tension-метрик больше подходит вариант геометрического среднего:

В этом случае игнорирование одной из метрик приведёт к результату 0%. Равное значение обеих метрик (баланс) даст итоговый результат, имеющий то же значение. То есть в случае баланса итог определяется тем, на каком уровне он достигнут – 10% или 90%.

Предложенный KPI вполне может быть основным показателем успешности деятельности по обработке инцидентов линейных менеджеров – старших групп поддержки.

P.S. Обобщение на случай произвольного количества метрик выполняется элементарно:

Но на практике случай трёх и более tension-метрик мне пока не встречался.

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Построение системы KPI для ИТ
Как обеспечить управление процессами, проектами, услугами, персоналом

Также по теме:

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

  • Олег Скрынник

    Дима, перестань уже рассказывать секреты, так скоро очередь за консалтингом исчезнет 🙂

    Если по теме – класс, конечно же, как обычно. Торкнуло тебя с метриками, ещё немного – и книжку можно будет писать.

  • Pavel Solopov

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

    • Дмитрий Исайченко

      Есть две разных информационных потребности: оценка и анализ. Они не альтернативны, поскольку направлены на решение разных задач. Уже как-то обсуждали, что KPI предназначен не для детального анализа, а для оценки (поэтому и “I” – индикатор). По результатам оценки выявляются те области, которые требуют детального анализа. Результаты оценки могут быть положены в основу системы стимулирования (чтобы каждый месяц не принимать субъективных решений о том, какова итоговая оценка, если один светофор красный, а другой – зелёный).
      И потом, ладно бы речь шла всего о двух метриках. Но даже если у вас всего 2 процесса, в каждом из которых 2 ключевые роли, то просто за счёт количества исполнителей легко можем получить порядка 40 значений метрик (2 х 2 х 10). Именно поэтому и делают агрегированные метрики.

      • Pavel Solopov

        Во многом с вами согласен, Дмитрий. Вот только я считаю, что такой подход к оценке не конкретно задаёт цели.
        Ведь в этом же смысл оценки: определить цель, установить показатели и их значения, которые характеризуют достижение цели, и через систему стимулирования подтолкнуть к достижению нужных значений, не так ли?

        Однако, в предлагаемом Вами случае получается, что мы задаём не одну целевую точку, а две. Мы говорим выдай нам нужное среднее (хоть и арифметическое) и не важно, как ты его выдашь за счёт высокой своевременности или за счёт высокой результативности. Мне кажется, не совсем верно таким образом ставить цели.

        • Дмитрий Исайченко

          Э-э, Павел, аполитично рассуждаете! Если Вы оцениваете результаты работы не по одной, а по нескольким метрикам, Вам, так или иначе, придётся отвечать на вопрос: «А что будет, если значение одной метрики будет хорошим, а второй – не очень»? Даже если Вы нарисуете вожделенный вражеский квадрат, на нём придётся выделять какие-то зоны, которые означают «отлично», «хорошо» и так далее. Так что квадрат – это, простите за каламбур, не содержание, а лишь форма ответа 🙂
          А дальше остаётся только выбор адекватной математики, которая реализует Ваши правила объединения двух метрик. Например, если Вы считаете, что снижение значения одной из метрик неизбежно должно снижать общую оценку (даже при увеличении второй выше нормы), Вы легко это можете реализовать формулой:
          K = (min(K1, K1 целевое) х min(K2, K2 целевое))^1/2
          (жаль, картинки в комментариях не поддерживаются).
          То есть первичен ответ на вопрос о том, как именно Вы планируете совмещать две метрики в оценке. Но если операнды – нормированные метрики в диапазоне [0; 1], где 1 – наилучшее состояние, а целевое значение близко к нему (0,90-0,95), то достаточно обычного геометрического среднего, поскольку запас роста метрики выше целевого значения гораздо меньше возможного падения ниже целевого значения.

          • Pavel Solopov

            Так что квадрат – это, простите за каламбур, не содержание, а лишь форма ответа

            Я иного и не утверждаю. Форма более информативного представления баланса двух метрик. Более информативное, чем среднее. Зоны выделять конечно же придёться, и ещё придёться думать, и принемать решение тоже придёться. Если мы хотим автоматизировать начисление премии. то конечно надо брать среднее: “двадцать пять, двадцать пять. будет премия опять…”.

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

          • Pavel Solopov

            целевое значение близко к нему (0,90-0,95), то достаточно обычного геометрического среднего

            Да, дейстительно, при таких условиях вероятность ошибки уменьшается. Но что-то мне подсказывает, что 0,9-0,95 очень уж высокие цифры для реальной жизни. Но моделировать сейчас времени нет. 🙂

            Есть ещё один нюанс, это “скорость изменения” метрик. Т.е. если увеличение одной метрики на 2% вызывается уменьшение другой на 1%, то выгодно увеличивать первую за счёт второй.
            Но это в случае если метрики взаимозависимые, конечно же.

  • Vladimir Kapustin

    Спасибо!
    Как раз пытался увязать в один KPI для service desk количество повторных обращений и среднее время входящего вызова. Попробую таким образом.

    • Дмитрий Исайченко

      “количество повторных обращений”

      Что имеется ввиду?

      • Vladimir Kapustin

        Есть техподдержка оператора связи.
        Физ.лица обращаются по телефону.
        В идеале звонок приходит один – по результатам инцидент закрывается сразу или оформляется, и дальше уже связываемся с абонентом мы.
        Если за сутки звонок с одного номера проходит более одного раза, то тот, кто принял его не последним – получает одно “повторное обращение”. Понятно, что отсекаем слишком короткие звонки.
        Проблему таких вызовов можно решить увеличив время разговора с каждым до неприличных значений. До сего момента вообще время входящих вызовов не вносил в KPI, т.к. не хотелось давить.

        • Pavel Solopov

          Т.е. если вы не связались с абонентом вовремя виноват оператор?

          • Vladimir Kapustin

            Ага.
            У нас специфика – они же работают за диспетчеров, т.е. распределяют людей и контролируют исполнение.

        • Pavel Solopov

          Геометрическое среднее в вашем случае не самый удачный вариант. Чтобы избежать присущих этой метрике недсотатков желательно нормировать её составляющие в каком-то фиксированом интервале значений. И привести к виду, когда для обоих значений минимальное значение – плохой результат, максимальное – хороший.

          Может вам проще оценивать соотношение количества обслуженных клиентов к количеству повторных обращений? Возможно с какими-то весовыми коэффициентами.

          • Vladimir Kapustin

            Количество обслуженных клиентов за смену примерно у всех равное. Этого нет в KPI, но это мониторится, отрисовывается… Этого хватает.
            Геометрическое среднее подкупает своей сравнительной простотой.
            Был лет 6 назад опыт составления сложных KPI – сотрудники просто перестали на них реагировать и относились к ним как к лотерее.

            • Pavel Solopov

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

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.