Мы сами были такими. Придумывали новый процесс управления ИТ, придумывали для него метрики, определяли целевые значения, начинали измерять. Получалось не всегда то, что было бы полезным – то данные невозможно собрать, то есть сомнения в их объективности, то полученное значение KPI не очень помогает в принятии управленческих решений. Мы читали, думали, советовались, обсуждали, разбирались. Формировали более чёткую терминологию и свою собственную картину мира про измерение процессов и услуг.
Теперь мы понимаем в измерениях немного больше, и, открывая, скажем, очередное описание процесса какого-либо клиента (раздел "Ключевые показатели эффективности"), мы часто можем сходу сказать что стоит улучшить.
Вот три основные причины, почему "заложенные" в процесс KPI не очень хорошо работают.
1. Авторам KPI спроектированного процесса мешают авторы умных книг (вроде ITIL, COBIT и других)
Когда примерно 12 лет назад я проектировал первый в своей жизни процесс управления инцидентами, на моём столе лежали две прекрасные книги: одна синяя, другая красная. ITIL Service Support и ITIL Service Delivery. В этих книжках есть очень хорошие слова, например, такие:
To judge process performance, clearly defined objectives with measurable targets — often referred to as Key Performance Indicators (KPIs) — should be set.
Отличный совет, надо ему следовать. Помимо тех метрик, которые я придумал сам (и которые казались мне разумными), я добавил в процесс и другие, из той же книжки, из рекомендованного списка (они тоже казались разумными):
The following metrics are examples for the effectiveness and efficiency of the Incident Management process:
- total numbers of Incidents
- mean elapsed time to achieve Incident resolution or circumvention, broken down by impact code
- percentage of Incidents handled within agreed response time (Incident response-time targets may be specified in SLAs, for example, by impact code)
- average cost per Incident
- percentage of Incidents closed by the Service Desk without reference to other levels of support
- Incidents processed per Service Desk workstation
- number and percentage of Incidents resolved remotely, without the need for a visit.
Я как-то пропустил слово "examples", и мне было невдомёк, что это, в общем-то, и не KPI вовсе. Мне повезло – список в той книжке был коротким, всего 7 пунктов. А вот тем, кто посмотрит в ITIL 2011, актуальную версию библиотеки, в разделе "4.2.1 Critical success factors and key performance indicators" покажут уже 18 примеров. Ещё сложнее будет тем, кто знает про сайт kpilibrary.com, где собрано более 6500 примеров KPI.
Что же не так с примерами из книг и почему их нельзя просто списать в свой процесс?
Их нельзя списывать потому, что это лишь примеры. Они даны в книгах с целью иллюстрации, чтобы было понятно о чём речь. Это не те метрики, которые вам нужны. Это не те метрики, которые вам помогут. Вам нужны свои собственные, и придумывать их нужно исходя из целей вашего измерения: что и зачем вы хотите измерять? В наших проектах мы идём по следующей цепочке:
Назначение ⇒ ключевые практики ⇒ метрики ⇒ целевые и граничные значения ⇒ KPI
Цепочка "Internet Explorer ⇒ kpilibrary.com ⇒ KPI" короче, но смысла не имеет чуть более, чем полностью.
2. KPI заменяют здравый смысл
Многие из нас были раньше айтишниками. Многие остаются ими и теперь. Отсюда проблема: мы всё хотим измерить. Нам же сказали: нельзя управлять тем, что не измеряешь. Это звучит разумно, так давайте всё, чем мы хотим управлять, срочно будем измерять. Процессы у нас большие, процедур много, точек контроля должно быть минимум два-три десятка. Это для начала.
А ещё давайте требовать для KPI исключительно объективные данные. Например то, что собирается в системе Service Desk (заявки, их жизненный цикл, разбивка по приоритетам и так далее) будем считать достоверной информацией, а, например, опросам удовлетворённости пользователей доверять не будем – это же страшно субъективно! Мало ли в каком настроении с утра этот пользователь? Нам никак нельзя принимать решения на такой основе.
Жизнь показывает, что не стоит всё возводить в абсолют. Управлять в некоторых случаях можно и без измерения, а в основу системы оценки работы ИТ-подразделения ставить удовлетворённость пользователей не можно, а нужно.
3. KPI отдельных процессов не складываются в общую систему оценки и измерения деятельности
Редко когда несколько процессов проектируются одновременно, с учётом их взаимосвязей и места в общей картине управления ИТ. Как правило, внедрение идёт по методу "процесс за процессом".
Ещё реже встречаются примеры построения комплексной системы оценки и измерения, которая далее декомпозируется на такие, к примеру, компоненты, как процессы, проекты и услуги, в свою очередь разбивающиеся на KPI по каждой из областей.
Чаще наоборот – из кем-то когда-то спроектированных (и частично работающих) процессов нужно создать "светофор для шефа" – хорошо ли работает ИТ-отдел, или не очень. И чтоб можно было тыкнуть в диаграмку и увидеть что именно не так. А как увидеть, если основа – лоскутная, кусочная, фрагментарная?
Для того, чтобы иметь возможность на основе KPI делать оценку работы подразделений и отдельных сотрудников, необходимо задуматься о сбалансированной системе, позволяющей наглядно показать прогресс (или регресс) в достижении поставленных целей. И, разумеется, использующей здравый метод агрегирования отдельных показателей в интегральную оценку.
Мы часто обращаемся к теме измерения и оценки на нашем портале. Тема очень актуальна, достаточно многогранна, и исключительно практична.
В ближайший вторник мы увидимся на нашем семинаре "ITSM. Руководство по измерению" с теми, кто успел зарегистрироваться и получил от нас подтверждение. Приношу извинения тем, кто не успел – количество желающих превысило наши прогнозы, и мест в актовом зале совсем не осталось. Но мы постараемся сделать видеозаписи докладов, которые затем опубликуем.
Плюс у нас для вас есть новая книга, "ITSM. Руководство по измерению".
И совершенно новый авторский учебный курс, "Измерение и оценка ИТ: процессы, проекты, услуги".
Так что от темы KPI теперь не убежать.
