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

KPI, проценты и психология

percent

Используя первую главу книги «ITSM. Руководство по измерению», можно сформировать оценку ИТ-подразделения или отдельных видов деятельности. В книжке эти оценки выражены в процентах и измеряются от 0 до 100. Однако опыт показывает, что проценты иногда вызывают неприятие руководителей. И причины этого не в математике, а скорее в психологии.

Вот пример. Допустим, оценка качества некоторой услуги опирается на три показателя:

tab1

В ответ на подобные таблицы мы несколько раз получали от ИТ-руководителей замечания вроде «Что значит 0%? Это значит, мы вообще могли выключить системы и не включать их?» или «Что значит 60%? У нас доступность на уровне 99%, а за 60% нас вообще всех увольнять пора?».

Удивительно, но факт: оценка, выраженная в процентах, может неосознанно восприниматься людьми не как самостоятельная величина, а как значение показателя в соответствующей области. Например, не «Оценка за доступность на уровне 0%», а «Доступность на уровне 0%».

При этом выясняется, что школьная шкала оценок в баллах (2-5) может работать гораздо лучше. То есть если оценка выражена не в процентах от 0 до 100, а в баллах от 2 до 5, она более четко воспринимается именно как оценка, и 2 балла за доступность критичного приложения на уровне всего 99% уже не кажутся несуразицей.

Столкнувшись с этим, мы решили преобразовать проценты в баллы:

tab2

А чтобы баллы «не мешались» при агрегировании оценок, все расчёты, как и ранее, можно выполнять в процентах (тогда их можно не только усреднять, но и перемножать), а баллы использовать только при выводе конечного результата в виде отчета (BSC или SLAM-chart):

tab3

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

Поэтому вопрос: коллеги-руководители, какой вариант вы предпочли бы в отношении оценки себя и своих подчинённых?

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

  • Alexandr Trapezin

    Второй вариант более нагляден при оценке.

  • Для оценки сотрудников я использовал и процентную шкалу, и балльную.

    При работе с процентной шкалой невольно переходишь к более грубым категориям, например 0 – 25% – 50% – 75% или подобным. Оценить какой-либо критерий с точностью 65% или 66% практически невозможно, отсюда и огрубление. Да и в дальшейнем анализе или агрегации такая точность бывает излишней.

    С другой стороны, у школьной шкалы от 1 до 5 есть свои нюансы, влияющие на практике на восприятие. Мне вспоминаются два:

    1. Реальная шкала не от 1 до 5, а от 2 до 5, так как разницу между единицей и двойкой мало кто способен объяснить.

    2. Тот, кто в школе учился на тройки-четвёрки, пятёрку может воспринимать как нечто, упавшее с неба. Само собой получилось. Случайность. Я не влияю. Тот, кто в школе был отличником и привык усердно трудиться, тройку может воспринимать как оскорбление. А шкала одна и та же, и критерии одни и те же. Люди только разные.

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

    • Оценить какой-либо критерий с точностью 65% или 66% практически невозможно, отсюда и огрубление. Да и в дальшейнем анализе или агрегации такая точность бывает излишней.

      Если в основе интегральной оценки лежит экспертное мнение, то согласен. Но если интегральная оценка основана на объективных измерениях, то основная проблема шкалы 2-3-4-5 – как раз слишком большое огрубление. Широкий диапазон результатов будет представлен оценками 3-4. Как следствие, будет трудно оценивать динамику достижений, сравнивать результаты разных подразделений / руководителей.

  • Сергей Семикин

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

    • А потребитель отчёта сам выберет, какой формат ему удобнее.

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM