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