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

Перевод заметки Стюарта Ренса (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 для планирования, понимания и обсуждения, но концентрируйте свои усилия на достижении реальных целей и не путайте их с показателями.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

АВГ
28