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

Ваши метрики — не ваша цель

Перевод заметки Стюарта Ренса (Stuart Rance) Your metrics are not your goals

Мне так понравилась запись в блоге Хайдера Рафика (Haider Rafique) «SLA – для болванов. Почему ITSM-компании должны быть более человечны» (SLAs are for suckers: Why ITSM orgs should be allowed to be more human), что я процитировал ее в своем твиттере: «Соглашения о качестве услуг приводят к негативным последствиям и препятствуют росту показателей, которые сложно измерить».

Это отличный пример Закона Гудхарта (Goodhart’s law ) в действии. Гудхарт был прекрасным экономистом, и выведенную им закономерность можно кратко сформулировать так:

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

Это связано с тем, что люди знают, что именно оценивается и выстраивают свое поведение соответствующим образом. Так что результаты получаются не такими, как планировалось изначально. И этот закон также применим к сфере управления ИТ-услугами, как и к экономике.

Я поразился тому, какие бурные дискуссии вызвал мой твит. Стало очевидно, что некоторым людям показалось, будто я проповедую анархию. Как я посмел предложить отказ от SLA! Это же бред!

И их, конечно, можно понять. ИТ-услуги практически всегда описываются в соглашении о качестве услуг (SLA), потому что SLA может и должен быть полезным средством взаимодействия между поставщиками услуг и их клиентами. После подписания SLA клиент получает четкое понимание того, какие услуги будут ему оказаны, а поставщик имеет возможность привлечь правильные ресурсы для выполнения своих обязательств.

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

У меня самого был похожий опыт, хоть и в совсем другой ситуации. Мне нужно было отвести одного из своих детей к дантисту. Я изучил ближайшие поликлиники, выбрал ту, где можно было записаться на ближайшее время, и о которой были хорошие отзывы. Наш семейный врач отправил туда запрос на запись к специалисту. Две недели спустя, не получив никакого ответа, я позвонил в ту поликлинику, и мне сказали, что еще не получали нашу заявку. Тогда наш семейный врач отправил еще одно письмо, и через две недели ситуация повторилась. Третью заявку я отвез им лично и поговорил с администратором. Во время этой беседы я имел возможность наблюдать огромную коробку с нераспечатанными письмами, и мне объяснили, что это те самые заявки, которые «еще не получены».

Эта поликлиника отчитывалась по показателю «количество дней с момента получения заявки до назначения времени приема». Только заявки не считались полученными до того момента, пока письмо не распечатано и не проштамповано. И поликлиника достигала высоких показателей, просто складируя письма и не распечатывая их, до тех пор, пока не освобождались специалисты, готовые принять пациентов.

Конечно, такой случай можно рассматривать как исключительный, но я видел похожие ситуации в области ИТ-показателей. Один контракт на аутсорсинг услуг включал вот такие данные:

  • 98% проблем с приоритетом 2 (P2) должны быть решены в течение 8 часов
  • 95% проблем  с приоритетом 3 (P3) должны быть решены в течение 24 часов

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

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

Мне никогда не придет в голову критиковать измерения как таковые. Измерения очень важны. Они показывают нам тенденции, раскрывают способы улучшения и предоставляют базу для взаимодействия с клиентами. Но нельзя забывать о том, что достижение KPI не является логическим завершением нашей работы, наша работа завершена тогда, когда мы выполнили то, чего ожидал от нас наш клиент.

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

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

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


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

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

  • Рубрики

  •  
  • Авторы

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

    • 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. Это не одно и то же.
    • 5 основных тенденций развития искусственного интеллекта и машинного обучения на 2022 год
      Вот несколько основных тенденций, к которым вашему бизнесу стоит начать готовиться. Искусственный интеллект и машинное обучение становятся доминирующей частью технологической
    • 6 тенденций в ИТ, за которыми нужно следить
      Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями - как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
    • Восход Desktop-as-a-Service: что это такое и зачем вам это нужно?
      Широкое распространение облачных вычислений добавило в наш словарь множество сокращений, наиболее распространенными из которых являются SaaS, PaaS и IaaS. Действительно, наступила эра облачных решений, которые доставляют программное обеспечение, платформу и инфраструктуру потребителям и предприятиям по запросу и с оплатой по мере использования.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT