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

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

Итак, задача. Есть две 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-метрик мне пока не встречался.

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

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

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

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

  • Pavel Solopov

    мне кажется, что такая метрика не имеет особого смысла, если только мы не поклонники нумерологии и не пытаемся найти одно сокровенное число от 0 до 1, которое нам раскроет абсолютную истину.

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

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

    • Есть две разных информационных потребности: оценка и анализ. Они не альтернативны, поскольку направлены на решение разных задач. Уже как-то обсуждали, что KPI предназначен не для детального анализа, а для оценки (поэтому и «I» — индикатор). По результатам оценки выявляются те области, которые требуют детального анализа. Результаты оценки могут быть положены в основу системы стимулирования (чтобы каждый месяц не принимать субъективных решений о том, какова итоговая оценка, если один светофор красный, а другой — зелёный).

      И потом, ладно бы речь шла всего о двух метриках. Но даже если у вас всего 2 процесса, в каждом из которых 2 ключевые роли, то просто за счёт количества исполнителей легко можем получить порядка 40 значений метрик (2 х 2 х 10). Именно поэтому и делают агрегированные метрики.

      • Pavel Solopov

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

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

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

        • Э-э, Павел, аполитично рассуждаете! Если Вы оцениваете результаты работы не по одной, а по нескольким метрикам, Вам, так или иначе, придётся отвечать на вопрос: «А что будет, если значение одной метрики будет хорошим, а второй – не очень»? Даже если Вы нарисуете вожделенный вражеский квадрат, на нём придётся выделять какие-то зоны, которые означают «отлично», «хорошо» и так далее. Так что квадрат – это, простите за каламбур, не содержание, а лишь форма ответа 🙂

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

          K = (min (K1, K1 целевое) х min (K2, K2 целевое))^½

          (жаль, картинки в комментариях не поддерживаются).

          То есть первичен ответ на вопрос о том, как именно Вы планируете совмещать две метрики в оценке. Но если операнды – нормированные метрики в диапазоне [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

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


Добавить комментарий для Vladimir KapustinОтменить ответ

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT