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

Вопрос из зала: веса KPI при расчете интегральной оценки

Читатель нашего портала Вадим Древин, изучив книгу "ITSM. Руководство по измерению", задаёт следующий вопрос:

Добрый день, коллеги. weight

В книге "ITSM Руководство по измерению" на странице 28 приведена формула (4) по расчету интегральной оценки. Есть такое ощущение, что она работает не корректно. Поясню:

Рассмотрим простейший пример. У меня есть два KPI, и оба находятся ровно посередине между целевым и пороговым значением, то есть в середине ЖЕЛТОЙ зоны и т.о. оба равны 50% (или 0.5).

Рассмотрим несколько примеров применения этой формулы: (а), (б) и (в).

а) Если веса у них одинаковы и равны 1, то интегральная оценка у них равна BS=0.5*0.5=0.25 (или 25%).

Если же веса разные, то очевидно что интегральная оценка будет больше 25% (что вполне логично), т.к. один из KPI (с максимальным коэффициентом) так и останется в произведении как 0.5, а второе увеличится, поскольку возводя число меньшее единицы в степень также меньше единицы получим число большее чем исходное, но по прежнему меньше единицы.

б) В этом примере пусть будут веса равны 2 и 1 соотв-но. Имеем операнды произведения: первое 0.5, второе 0.5^(1/(2-1+1))=0.5^0.5=0.71. Итого: BS=0.5*0.71=0.355 (или 35.5%).

в) Поскольку сказано, что "веса это целые положительные числа, представляющие относительную значимость друг от друга" (стр.25 и сноска на стр.28), то в примере (в) я приму веса равными 4 и 2 соотв-но. И ожидаю получить такой же результат, как и в примере (б). Считаем: первый операнд 0.5 [ 0.5^(1/(4-4+1))=0.5^1=0.5 ], второй операнд 0.5^(1/(4-2+1))=0.5^(1/3)=0.5^0.(3)=0.79. Итого: BS=0.5*0.79=0.395 (или 39.5%).

Результат в примере (б) и (в) не совпал, и т.о. можно сделать вывод, что в формуле есть ошибка.

Осмелюсь высказать предположение, что наименьший коэффициент должен быть равен 1 (единице) чтобы формула работала, но в этом случае остальные коэффициенты следует разрешить ставить дробными числами. Т.к. при относительной значимости, например, 3 к 2, коэффициенты при меньшем равным единице будут равны 1.5 и 1. Если применить текущую формулу к 1.5 и 1, то получится BS=31.5%; если же 3 и 2, то BS=35.5%. Прошу обратить внимание, что при коэффициентах 3 и 2 результат получился такой же, как и при коэффициентах 2 и 1, и более того он получится таким же при коэффициентах 1000 и 999. Что совсем не правильно.

Не могли бы вы пояснить, как все-таки правильно использовать формулу? Спасибо!

P.S. Также хотел бы указать на замеченную неточность в книге — сноска 36 на стр.99. Там сказано, что на графиках "японские свечи" отображаются среднее и предельные значения котировок за заданный интервал времени. Хотел бы заметить, что в японских свечах средних значений НЕТУ, есть только предельные (как указано в книге) и значения на начало интервала времени и на конец. Т.о. на японской свечи 4 значения, но среднего там нет :).

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

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

  • Лучше всего на такие вопросы отвечает автор книги, но Дмитрий Исайченко сейчас в коротком отпуске.

  • Я конечно не Дмитрий, но позволю себе ответить.

    Вадим, насколько я понял ваши рассуждения, вас смущает то, что для различных наборов весов, которые пропорциональны между собой (например, 1 и 2, 2 и 4, 7 и 14...) интегральный показатель дает разный результат. Это действительно так, тут вы правы.

    По поводу того, что формула не верна — я бы не стал торопиться 🙂

    Формула была бы не верна, если бы мы требовали от нее, чтобы для пропорцинальных наборов весов значение интегрального показателя было одинаково. Т.е. чтобы для весов 1 и 2 значение было бы такое же, как и для 2 и 4. Но такого требования нет.

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

    На самом деле можно придумать много способов обойти указанную вами проблему.

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

    Можно поступить по другому — зафиксировать не самый маленький вес, а вес какой-то конкретной метрики. Например, пусть метрика М1 всегда имеет вес 10, а остальные пусть будут подбираться относительно нее.

    Ну и наконец, можно просто взять за правило, что сумма весов должна быть равна некоторому фиксированному числу — например 100.

    Наиболее практично, мне кажется, — зафиксировать сумму весов, чтобы она всегда была одинаковой, и позволить весам не быть целочисленными. Сумму весов стоит подобрать эмпирически, учитывая, что чем она больше, тем ближе интегральный показатель к 1.

  • Результат в примере (б) и (в) не совпал, и т.о. можно сделать вывод, что в формуле есть ошибка.

    А на чём основано предположение о том, что результаты (б) и (в) при выбранных весах должны совпасть?

    Насколько я понял из вопроса (в частности, из отсылок на страницы 25 и 28), Вы неявно полагаете, что относительная важность равна, если равен результат деления весов (2/1 = 4/2). Однако в данном случае равенство разницы влияния достигается не делением, а вычитанием: например 2-1 = 4-3 = 3-2. Это не правильно и не неправильно — такой алгоритм, это его свойство.

    Если Вы хотите равенства, основанного на делении, просто используйте другой алгоритм — например, взвешенное геометрическое среднее. Это вообще хороший вариант (в некоторых отношениях он лучше формулы 4, о которой Вы задаете вопрос), но у него есть существенный минус — он весьма сложен для понимания. Именно поэтому мы и искали альтернативы. И однажды вышли на взвешенное произведение.

    Вообще же мне известно 5 алгоритмов агрегирования. В порядке повышения их жёсткости (степени влияния на интегральную оценку отдельных провалов) список выглядит так:

    1. традиционное (взвешенное) арифметическое среднее;

    2. арифметическое среднее с динамическими весами (http://www.realitsm.ru/2014/11/dynamic-weights/);

    3. минимум;

    4. (взвешенное) геометрическое среднее;

    5. (взвешенное) произведение.

    Выбирайте 🙂

    P.S. За японские свечки спасибо — хорошее замечание.

  • Вадим Древин

    Степан, Дмитрий, большое спасибо за ответы.

    Я теперь кажется уловил мысль о том, что интегральной оценкой можно манипулировать придавая весам определенный порядок. Хотим показать руководству интегральную оценку из двух KPI с показателями 0.5 и 0.5 равную 35.5% — выбираем веса 1 и 2, хотим увеличить это значение (39.5%) выбираем 2 и 4 (или еще выше), хотим уменьшить (29.7%) выбираем 0.333 и 0.666.

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

    На данный момент я вижу три подхода:

    1) Закрепление минимальной оценки. Закрепить минимальную оценку равным 1 (единице) и остальные рассчитывать в отношении к минимальной. Кол-во участвующих KPI не важно. Сумма весов в этом случае не будет фиксирована. [Этот способ я сам предложил, и Степан его вроде даже одобрил 🙂 ]

    2) Фиксация суммы весов. Сумма весов внезависимости от кол-ва KPI должна быть равна N, где N>=1. [Этот способ предложил Степан]

    3) Пропорциональная фиксация суммы весов. Сумма весов для двух KPI должна быть равна N. Сумма весов для M KPI должна быть равна N*M/2.

    Как вы считаете, какой подход наиболее математически выверен, с точки зрения того, чтобы его применять для множества интегральных оценок, базирующих на разном кол-ве интегрируемых KPI?

    Хотелось бы еще отметить, что на данный момент я склонен остановится на подходе (1), но меня несколько смущает порядок интегральной оценки. Руководство не очень будет понимать, почему интегрируя три KPI с одинаковыми весами находящихся в серидине желтой зоны (50%) интегральная оценка будет равна 12.5%. Поэтому я больше склонен к взвешенному геометричесому среднему, т.е. формулу (4) модифицируем возводя результат в степень 1/SUM (W (i)). В этом случае, мы практически усредняем значения KPI при близкий результатах, но в случае если идет провал по 1 KPI (красная зона) интегральная оценка будет равна 0 и это правильно (такого не достигнешь взвешенным средним арифмитическим).

    • Но, что тут крайне важно, и что как мне кажется стоило бы озвучить в книге, — это универсальность подхода

      Если Вы имеете ввиду выбор алгоритма агрегирования, то я бы воздержался здесь от универсальных советов / рецептов. Мое мнение — каждый из пяти перечисленных алгоритмов агрегирования имеет свои сценарии применения и, соответственно, право на существование. В каждой конкретной ситуации выбор алгоритма определяется:

      1. взаимосвязью отдельных KPI между собой;

      2. целевым влиянием отдельных KPI на интегральную оценку;

      3. общим количеством и структурой KPI.

      Более того, как и написано в книге (стр. 30), иногда даже в одной BSC различные метрики агрегируются разными алгоритмами — это совершенно нормально.


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

Ваш адрес 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