Портал №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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

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

    • FinOps с помощью Governance-as-Code
      Масштабы и сложность решений, основанных на облачных технологиях, продолжают расти. Слишком часто это расширение также означает, что затраты продолжают выходить из-под контроля. В
    • Применима ли концепция «сдвиг влево» (shift left) для инженеров по надёжности систем (SRE)?
      Концепция «сдвига влево» помогает упростить некоторые аспекты разработки программного обеспечения. Но предназначена эта концепция не только для разработчиков. Она
    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT