Когда пора сбивать высокую температуру? Умеем ли мы принимать правильные решения
Наиболее важные факторы, нужные для управления любой организацией,
как правило, неизвестны и количественно неопределимы.
Эдвардс Деминг [1]
Александр Шпер
Конечно же, речь в этой статье не пойдёт о том, когда необходимо принимать жаропонижающее. Мы попробуем разобраться со схожей, но более общей проблемой – умеем ли мы вообще принимать решения на основании измерений. То, что мы умеем принимать какие-то решения, ни у кого не вызывает сомнений. Но вопрос в том, насколько они адекватны и можно ли их назвать правильными (как порой и в случае с приёмом жаропонижающих средств при обнаружении повышенной температуры на градуснике).
Все мы, так или иначе погрузившиеся в дебри экономических взаимоотношений друг с другом, постигнувшие азы или уже даже совсем не азы менеджмента, давно привыкли к тому, что не можем управлять тем, что не получается измерить. Тот же ITIL, который ни в коей мере не претендует на роль первоисточника всех истин, хотя многие его таковым считают, в одной из своих книг напоминает нам: «Вы не можете управлять тем, что не можете контролировать. Вы не можете контролировать то, что не можете измерить. Вы не можете измерить то, что не можете определить» [2] . Это действительно звучит вполне разумно – измерять определённые показатели, сравнивать и анализировать их динамику и принимать по итогам анализа какое-либо решение. Мы все это постоянно делаем – как на работе, так и в личных делах. Но давайте взглянем на эту цепочку «измерение – анализ – принятие решений» чуть пристальнее.
Типовой сценарий
Разберём максимально простые и приближенные к каждодневной работе примеры. Возьмём ИТ-отдел, в котором давно и успешно формализовано некоторое количество процессов из процессной модели всё того же ITIL. И рассмотрим наиболее часто встречающийся процесс управления инцидентами. Почти наверняка в том или ином виде он есть у всех – все ведь каким-то образом регистрируют и устраняют сбои и неполадки.
В случае, если этот процесс действительно формализован, он почти наверняка обвешен целой системой показателей – и сколько инцидентов произошло за период, и сколько решено, и процент решённых за период, и процент решённых на первой линии, и какие-то более сложные показатели. Я уверен, что у большинства читателей этот процесс очень хорошо измеряется, и, скорей всего, немалым количеством метрик (или показателей, или KPI – называйте их как хотите, сейчас это непринципиально).
Ответа на этот вопрос нет и быть не может. Всё всегда индивидуально. Но есть некоторые рекомендации, которых стоит придерживаться.
Начать можно вообще с достаточно общего принципа – «бритвы Оккама» (если кто забыл, то вкратце это про то, что не надо плодить лишние сущности). В ITIL, кстати, тоже есть отличный принцип (один из девяти), очень схожий по своей сути: не усложняй ! [3] Но ещё больше мне нравятся крайне дельные и полезные советы ITIL:
«…чем меньше, тем лучше. Если одного KPI достаточно – то пусть и будет один… [4] ».
«…в идеале будет только один, два или максимум три показателя… [5] ».
Так что подумайте хорошо, прежде чем навешивать на один процесс 10 показателей. Неспроста умные книжки советуют минимизировать их количество.
И, скорей всего, для каждого (или для большинства) показателей у вас есть некое целевое значение. Сейчас даже неважно, откуда оно взялось (хотя, на самом деле, это очень важно), сейчас для нас главное его наличие.
И каждый отчётный период (например, месяц) вы измеряете свой процесс по заранее определённым показателям, сравниваете полученный результат с запланированным целевым значением и …? И вот тут начинается самое интересное. В большинстве случаев, с которыми мне приходилось сталкиваться на практике, дальше происходило следующее:
- если целевой показатель в данном отчётном периоде не достигнут, кого-нибудь обязательно «наказывали» (это может быть выговор, лишение части привычной зарплаты, ещё какие-то меры);
- если целевой показатель достигнут или даже незначительно превышен, то ничего не происходит (т. е. всё продолжается «как обычно»);
- если целевой показатель за отчётный период значительно превышен, то кого-нибудь «премируют» (речь не обязательно о финансовых выплатах, но и они встречаются).
Знакомая ситуация? Мне, к сожалению, да – я неоднократно видел подобное в совершенно разных организациях разного масштаба, оргструктуры, географического положения, сфер деятельности и возраста – и от этого становится достаточно грустно. Но давайте попробуем разобраться, что же здесь не так и как надо.
Показатели – какие, сколько и зачем?
Главный вопрос – это, конечно же, «зачем?».
На одной из ежегодных Всероссийских конференций itSMF второй день открывало выступление одного из приглашённых иностранцев. Представьте себе: утро, первое выступление, большой зал, человек 400, зевая, потягиваются в креслах, некоторые ещё только допивают приветственный кофе и неспешно вползают в аудиторию. И очень бодрый докладчик начинает свою презентацию с опроса. «Кто из вас сегодня приехал сюда на машине?» – спрашивает он. Примерно половина зала поднимает руки. «А кто приехал на метро?». Ещё примерно половина поднимает руки. «А кто пришёл пешком?». И оставшиеся человек 15-20 поднимают свои руки. «Отлично! Спасибо! Только что я собрал потрясающую статистику, которая мне совершенно не нужна и абсолютно бесполезна. Так и мы – айтишники – вечно понаставим везде градусников, всё измерим, отмониторим, а зачем нам это всё – никто не знает!».
Очень надеюсь, что даже в тех организациях, где на основании анализа показателей приходят к выводу лишь о необходимости премирования/депремирования сотрудников, изначально всё-таки преследовалась какая-то другая цель. Например, постоянное совершенствование, удовлетворение потребностей клиентов, выпуск продукции без брака или привлечение новых клиентов.
Именно отталкиваясь от цели, от понимания того, зачем вам надо что-то измерять, вы будете создавать свою систему показателей. В её рамках будет установлено, что вы будете измерять и как. Т. е. вы должны понимать, решения в какой области вы хотите принимать на основании измеренных показателей, и, отталкиваясь от этого понимания, проектировать свои показатели.
Какие? Как и всегда, однозначного ответа здесь нет и быть не может. Например, ITIL предлагает нам целых 4 вида категоризации метрик:
- Технологические, процессные и сервисные метрики.
- Метрики прогресса, соответствия, результативности и эффективности.
- Запаздывающие и опережающие метрики.
- Метрики «изнутри наружу» (inside-out) и «снаружи внутрь» (outside-in).
ITIL советует использовать все 4 типа метрик. А к этим типам метрик нам предлагается ещё 5 иерархических моделей, включая и хорошо всем известную сбалансированную систему показателей, и каскад целей COBIT, и некоторые другие [6] .
Возможно, ваша система показателей не будет похожа ни на что из указанного в разных библиотеках и других умных книжках, главное – чтобы у неё была цель и чтобы она помогала вам работать, а не создавала помехи и препятствия вам и вашим сотрудникам. Остаётся вопрос количества этих показателей. С одной стороны, не забываем о совете максимально минимизировать количество метрик. С другой стороны – помним про цель. И не забываем про здравый смысл.
Наблюдательный читатель уже, наверное, заметил, что я достаточно часто ссылаюсь на самую свежую на данный момент публикацию библиотеки ITIL – книгу ITIL Practitioner Guidance, вышедшую в начале 2016 года. Это неспроста – мало того, что вся книга посвящена так или иначе вопросам совершенствования, так ещё и целый большой раздел раскрывает тему метрик и измерений.
Нет, вы не найдёте в ней списка конкретных показателей для лучшей в мире системы измерений. Да и вообще почти никакой конкретики не найдёте. Потому что этого нет и быть не может. Серебряной пули вообще не существует (но об этом читайте в другой статье J).
Зато концентрация полезной информации на страницу текста в этой книге точно превосходит все предыдущие публикации. Здравый смысл поставлен, пожалуй, во главу всего, что очень хорошо. Акцент сделан, на мой взгляд, на самых важных вопросах – коммуникациях, управлении организационными изменениями и, о чём говорилось ранее, метриках и измерениях. Море полезной информации, изложенной в простой и понятной форме. Да и объём книги относительно небольшой (по сравнению с другими книгами ITIL) – всего 180 страниц, из которых содержательных около 140 (остальное – глоссарий, библиография и т. п.)
В общем, теперь я точно знаю, что отвечать, если меня спрашивают, а что именно из библиотеки ITIL я бы рекомендовал почитать.
И вот мы всё измерили…
Предположим, у вас есть отличная система показателей, вы регулярно собираете какие-то данные, ваша система автоматизации сводит всё это в красивые таблички-графики. Что же дальше делать со всей этой информацией?
Давайте снова вернёмся к нашему процессу управления инцидентами. Допустим, у вас есть показатель – процент инцидентов, решённых вовремя (где вовремя – заранее установленная договорённость, например, в SLA). Предположим, что вы установили целевое значение данного показателя – 90%. Например, на основании среднего значения данного показателя за прошлые периоды. Отчётный период – неделя. И вот у вас есть результаты измерений за 20 недель (рис. 1).
Рис. 1. График хода процесса
На этом графике 8 точек находятся выше отметки «90», а 12 – ниже. Значит, из 20 недель наш процесс 8 недель работал хорошо, а 12 – плохо, так? НЕТ, не так .
Почему? Давайте попробуем разобраться.
Статистическое управление процессами
Есть такая дисциплина – «Статистическое управление процессами» (Statistical Process Control – SPC). Её изучают в институтах, по ней опубликованы статьи и книги, а её возраст приближается к юбилею в 100 лет. Возникновением этой дисциплины мы обязаны Уолтеру Шухарту, американскому учёному в области теории управления качеством, который разработал методологию, положенную позднее в основу данной дисциплины, в 20-х годах прошлого века. Ключевым инструментом статистического управления процессами являются контрольные карты Шухарта, которые помогают принимать разумные решения относительно любых процессов.
Чтобы понять, каким образом этот инструмент работает, нужно вспомнить, что такое процесс. Какой бы источник вы ни смотрели, определение процесса всегда сведётся к чему-то похожему на структурированную совокупность видов деятельности, спроектированную с определённой целью для достижения определённого результата, преобразующую некие входы в некие выходы, использующую какие-то ресурсы – и всё это обязательно под неким управляющим воздействием. Что здесь особенно важно – у любого процесса должна быть цель, и он должен генерировать какой-то результат, который кому-то нужен (потребителю). И этот результат должен создаваться каждый раз, когда запускается деятельность в рамках этого процесса и должен быть по возможности одним и тем же – ведь именно этого результата ждёт от нас потребитель. Т. е. процесс должен стабильно воспроизводить одну и ту же последовательность действий для достижения одного и того же результата. И это очень важно. Но тогда возникает закономерный вопрос – в чём же заключается эта «стабильность»?
Так уж устроена природа, что все процессы обладают одним важным свойством: вариабельностью или изменчивостью. Как бы мы ни хотели в точности повторить деятельность, это никогда не получится сделать на 100%, потому что мир вокруг изменчив. И это означает, что при измерении любого показателя процесса мы всегда будем получать не одно и то же значение, а их разброс вокруг некоторой величины. И это нормально. Это верно вообще для любого процесса в любом аспекте жизнедеятельности, будь то производство холодильников, квалификационные заезды Формулы-1, уровень гемоглобина в вашей крови, приготовление ватрушек дома или процесс управления инцидентами.
Именно Шухарт понял, что для каждого процесса всегда можно выделить два типа причин вариабельности: общие и специальные.
- Общие причины вариабельности отражают устройство вашей системы, вашего процесса, т. е. это норма для вашего процесса.
- Специальные причины вариабельности показывают, что в вашу систему/процесс что-то вмешивается и не даёт ей/ему функционировать нормально, должным образом.
Принятие решений по управлению процессом зависит от того, какие причины – общие или специальные – обуславливают вариабельность процесса. Чтобы ответить на этот вопрос, нужно воспользоваться контрольными картами Шухарта. Для нашего примера с процессом управления инцидентами мы построим карту индивидуальных значений (рис. 2) [7] .
Рис. 2. Карта индивидуальных значений для показателя «Процент инцидентов, решённых вовремя».
Вариант 1. Стабильный процесс
Чёрная линия посередине графика – это центральная линия. В данном случае она соответствует среднему значению за период измерений и находится на отметке «89,7». Красные пунктирные линии – это верхний и нижний контрольные пределы, которые показывают границы стабильности процесса. Все точки процесса, находящиеся внутри этих границ, объясняются общими причинами вариабельности и отражают нормальную работу данного процесса. На данном графике мы видим именно такую картину; это означает, что процесс стабилен, управляем и не требует вообще никакого вмешательства (если нас устраивает то, как работает этот процесс). Так он спроектирован, так он и должен работать. Это его норма. Не надо никого ни поощрять, ни наказывать – этот процесс будет давать значения внутри указанной зоны с показанным на графике средним, пока в него не вмешиваются какие-то посторонние силы, и пока мы не меняем систему, в которой этот процесс функционирует.
Зона между верхним и нижним контрольными пределами может быть названа зоной системной вариабельности данного процесса – и это зона ответственности исключительно руководства, а не конкретных исполнителей, т. к. именно высшее руководство отвечает за то, как устроены система и процесс в целом. Более того, наш процесс спроектирован таким образом, что целевое значение в 90% находится чуть выше центральной линии (разница в 0,3%), а это значит, что мы будем в среднем получать нужный результат без каких-то дополнительных усилий (не считая усилий, потраченных на поддержание данной ситуации, т. е. стабильности системы). Колебания точек внутри зоны стабильности – это случайные отклонения, и точки ниже среднего ничем не хуже и не лучше точек выше среднего: все точки, лежащие в зоне системной вариабельности (между нижним и верхним контрольными пределами) абсолютно эквивалентны.
Если при такой же работе процесса, как отображено на графике, будет установлено целевое значение показателя, например, в 96%, то оно будет всегда недостижимым, пока руководство не изменит систему и не усовершенствует процесс необходимым образом. Если же будет установлено целевое значение в 84%, то оно не будет иметь никакого смысла, так как мы без каких-либо усилий всегда будем его значительно превышать.
Рис. 3. Карта индивидуальных значений для показателя «Процент инцидентов, решённых вовремя».
Вариант 2. Нестабильный процесс
А что если тот же самый процесс даёт нам другие результаты (рис. 3)? Здесь два значения показателя скатились сильно вниз (75% и 76%), но главное – они вышли за границу стабильности процесса (находятся ниже нижнего контрольного предела). Эти точки указывают на наличие специальной причины вариабельности – т. е. в систему вмешивалось что-то постороннее, не принадлежащее системе. И это означает, что наш процесс нестабилен, неуправляем, и поведение такого процесса в последующие моменты времени непредсказуемо. В таком случае также бесполезно кого-то штрафовать и требовать достижения целевого значения – наша система в принципе не является управляемой. Более того, устанавливать какие-либо целевые значения тоже бесполезно. Необходимо с каждым из таких случаев разбираться индивидуально и приводить систему (процесс) в стабильное, управляемое состояние. Специальная причина вариабельности требует локального вмешательства в процесс как можно скорее .
Теперь вернёмся к варианту 1, когда процесс стабилен. Что можно сделать в рамках постоянного совершенствования? Можно уменьшить разброс показателя, можно повысить среднее, можно попробовать сделать и то, и другое. Например, вариант с уменьшенным разбросом будет выглядеть так, как показано на рис. 4. В данном случае оказывается воздействие на общие причины вариабельности, т. е. производится целенаправленное изменение системы . И это зона ответственности руководства.
Рис. 4. Карта индивидуальных значений для показателя «Процент инцидентов, решённых вовремя».
Вариант 3. Уменьшение разброса показателя. Стабильный процесс
В чём сила, брат?
На самом деле, контрольные карты Шухарта – это мощный и важный инструмент анализа данных, изучению которого можно посвятить не один год (хотя научиться ими пользоваться можно и гораздо быстрее). Мы рассмотрели применение всего лишь одной из множества карт – и то не целиком. Самое важное, что этот инструмент позволяет принимать действительно взвешенные и обоснованные решения по итогам анализа показателей, а в более глобальном масштабе позволяет понять некоторые очень важные аспекты управления любой организацией.
Основные выгоды от использования статистического управления процессами и контрольных карт Шухарта:
- Контрольные карты Шухарта позволяют принимать обоснованное решение, на какие отклонения реагировать (специальные причины вариабельности), а какие – игнорировать (общие причины – случайные колебания системы).
- Использование контрольных карт Шухарта позволяет реагировать на отклонения (специальные причины вариабельности) немедленно, а не по итогам анализа 1 раз в месяц или тем более 1 раз в год.
- Статистическое управление процессами предлагает алгоритм совершенствования любых процессов: сначала необходимо добиться стабильности процесса, потом можно его улучшать (через повышение среднего, через уменьшение разброса значений или и тем, и другим методом одновременно).
- Контрольные карты Шухарта наглядно демонстрируют нам принцип, сформулированный доктором Демингом: 94% ошибок генерируется системой и лишь 6% – ошибки персонала [8] . Не имеет никакого смысла наказывать людей за ошибки в большинстве ситуаций. Менять надо систему, а это удел руководства. И если система выдаёт ошибки, то винить можно только её руководителя. Но и этого делать не нужно – нужно исправлять систему, чтобы она работала правильно.
Очень важно, чтобы этот момент отчётливо понимали все руководители. Давайте попробуем рассмотреть некоторые примеры, не связанные с измерениями и статистическим управлением процессами. Возьмём некий набор свойств персонала (на уровне исполнителей), которые приводят к ошибкам, и попробуем понять, кто и что может сделать, чтобы в дальнейшем подобные ошибки не повторялись.
Допустим, у нас есть медлительные , невнимательные и забывчивые сотрудники, которые не понимают и не хотят работать по стандартам/процессам, а ещё не способны правильно оценивать ситуацию . Да, они ещё и неопытные . А представьте, что это всё сошлось в одном человеке! Казалось бы, вот она причина всех бед! Нет уж, давайте разбираться.
Забывчивость и медлительность могут быть свойствами характера человека – это нужно проверять при приёме на работу, если работа требует хорошей памяти и быстрой реакции – т. е. это вопрос плохой организации подбора персонала.
Невнимательность может относиться к этой же категории, но может быть вызвана и однообразной неинтересной работой – человек физически не в состоянии поддерживать внимательность на высоком уровне непрерывно. В этом случае корень проблемы в плохой организации рутинного труда – нужны перерывы, отвлечения, перестановки людей на разные места и т. п.
Неопытный сотрудник , непонимание процессов и стандартов, неспособность правильно оценить ситуацию – это всё результат отсутствия нормального обучения и подготовки персонала.
Нежелание работать по стандартам и регламентам часто может быть вызвано тем, что стандарт не учитывает реальную ситуацию, и работа по стандарту может приводить к ухудшению ситуации. Здесь нужно идти в гембу [9] и разбираться в ситуации. Но возможна и более простая причина – человек может не понимать, что и зачем ему делать. А если он не понимает, зачем ему это (классическое what’s in it for me), то откуда у него может взяться желание это делать?
Во всех случаях перечисленный выше набор свойств исполнителя не относится к зоне ответственности конкретного сотрудника – это проблемы менеджмента организации, проблемы системы. А систему могут менять только руководители – именно поэтому они ответственны почти за всё в организации.
Ну, и напоследок, для фанатов футбола: если команда показывает плохие результаты, то обычно свой пост покидает тренер. «Тренеры», не забывайте об этом!
- Отчасти следствием того, что 94% ошибок генерируется системой и лишь 6% – это ошибки персонала, является и следующий вывод: ни в коем случае нельзя привязывать зарплату персонала к KPI. Это влечёт за собой работу только на показатель (и подделку такого показателя), вместо реальной работы на результат. Подробнее это объясняет «закон Гудхарта» (см. врезку). KPI, конечно, можно и нужно использовать для планирования и распределения ресурсов и для прослеживания тенденций, но для оценки работы сотрудников – очень и очень осторожно, а лучше никогда. KPI могут устанавливаться как цели, но эти цели не должны быть директивными и обязательными для выполнения, они должны быть только ориентирами, указывающими направление движения и служащими отправной точкой для последующих улучшений. От достижения или недостижения целевых значений показателей не должны зависеть зарплата, социальный статус и другие «пряники» сотрудников.
Чарльз Гудхарт, английский экономист, бывший работник Банка Англии и заслуженный профессор Лондонской школы экономики и политических наук, ещё в 1975 году сформулировал следующий принцип:
«Когда социальный или экономический показатель (KPI) становится целью для проведения социальной или экономической политики, он перестаёт быть достойным доверия показателем. Таким образом, процесс оценки эффективности менеджмента за счёт измерения таких показателей может дать ложную (неверную) оценку. Суть в том, что измерение системы обычно нарушает её».
Говоря более простым языком, если какой-то показатель становится обязательным и от него зависит благосостояние сотрудника, то такой показатель, скорее всего, будет достигнут, но зачастую в ущерб системе или за счёт искажения информации. Для исключения возможности появления подобных ситуаций достижение или недостижение KPI не должно ни поощряться, ни караться, так как поощрять или наказывать за случайные колебания системы бессмысленно.
Кстати, даже в ITIL Practitioner Guidance описан этот принцип, хотя там и не упоминается в явном виде «закон Гудхарта». В разделе 4.2 говорится примерно следующее:
«Даже «правильный» SMART-KPI может иметь нежелательные последствия. Необходимо проводить анализ, чтобы понять, каким образом KPI будет влиять на поведение людей. Если KPI «измеряет» людей, то они сделают всё возможное, чтобы в отчёте были «правильные» цифры».
Вместо эпилога
Помните модель DIKW [10] , то есть данные – информация – знания – мудрость? Когда вы всё измерили и собрали все показатели, то это всего лишь данные . Когда вы нарисовали красивые графики, соотнесли это с каким-то временным периодом – это уже информация . Если вы научились правильно обрабатывать эту информацию, она становится знанием . Как раз в этом вам может помочь статистическое управление процессами и один из его инструментов – контрольные карты Шухарта. Приведёт ли это вас к мудрости, будет зависеть уже только от вас и от реально принятых вами решений.
Будет ли этот путь лёгким? Сначала, возможно, не очень. Зато когда вы овладеете этим инструментом, ваша система точно выйдет на новый уровень развития. А простые решения, которые сейчас, вероятно, кажутся вам правильными, вообще могут оказаться неверными, особенно если принимаются впопыхах и на основании информации, которая не была правильным образом проанализирована.
Но помните, что даже если вы построили прекрасную систему показателей, научились их анализировать, используя контрольные карты Шухарта, ваше руководство научилось принимать на себя ответственность за все системные ошибки – всё это ещё не означает, что вы можете быть полностью уверены в своих измерениях. Потому что, как говорил Деминг, «наиболее важные факторы, нужные для управления любой организацией, как правило, неизвестны и количественно неопределимы».
В отличие от ситуации с показателями процесса, на вопрос, вынесенный в заголовок статьи, есть достаточно точный и чёткий ответ (хотя и там есть свои исключения и особые случаи – но это уж давайте оставим врачам).
[1] Деминг Э. Выход из кризиса: Новая парадигма управления людьми, системами и процессами/Пер. с англ. – М.: Альпина Бизнес Букс, 2007, стр. 44.
[2] You cannot manage what you cannot control. You cannot control what you cannot measure. You cannot measure what you cannot define. (ITIL® Continual Service Improvement)
[3] KEEP IT SIMPLE (ITIL Practitioner Guidance, раздел 2.9)
[4] «…it is important to have as few as possible. If one KPI is sufficient, then just define that one…» (ITIL Practitioner Guidance, раздел 4.2)
[5] «…ideally there will be just one, two or three KPIs…» (ITIL Practitioner Guidance, раздел 4.2)
[6] Подробнее см. ITIL Practitioner Guidance, 4.3 METRIC CASCADES AND HIERARCHIES.
[7] Вообще, в таком случае должна быть построена двойная карта – карта индивидуальных значений и карта скользящих размахов, но для упрощения мы пока опустим второй график.
[8] Изначально это соотношение было сформулировано как 85/15 Дж. М. Джураном. Э. Деминг считал, что правило Джурана имеет другой вид: 94/6. В последние годы жизни, по свидетельству его учеников, Деминг пришёл даже к ещё более контрастному соотношению: 98/2.
[9] Гемба, с японского, буквально, – «реальное место». В концепции бережливого производства (lean production) этот термин стал использоваться для обозначения места, где непосредственно производится работа, или ещё более точно – место, где создаётся ценность для потребителя.
[10] Data – Information – Knowledge – Wisdom
