Забудьте о KPI ! (часть 1, или простые ошибки)

Забудьте о KPI !

Навсегда забудьте о KPI! Стройте и улучшайте процессы управления ИТ с четко поставленными целями. Тогда создавать KPI в творческих муках просто не будет необходимости. Показатели и так будут у вас под рукой. Парадокс? Давайте попробуем разобраться.

Ситуация в большинство ИТ-отделов с практикой создания и использования процессных метрик действительно удручает. Фразу "если не измеряешь, значит не управляешь" многие компании выучили наизусть, и ошибка номер раз – полное отсутствие измерения ИТ процесса – постепенно вымирает на просторах отечественного ИТ. Хоть что-нибудь, но померяем. Качественно ли измерим, то ли измерим, что нужно – второй вопрос. Средняя температура известна. И после шага один становится немного сложнее. Дальше нас подстерегают интересные, познавательные грабли.

До сих пор во многих известных и уважаемых компаниях наиболее используемым отчетом Service Desk все еще остается простой реестр инцидентов с главным показателем – количество инцидентов. Это хороший KPI процесса управления инцидентами? Прошу вас, после чтения этой статьи – взгляните на этот простой вопрос и ответьте на него еще раз.

Основные ошибки.
Попробуем типизировать наиболее распространенные ошибки создания и внедрения показателей:
1) Не измеряем вообще.
2) Набор показателей формируем на основе списка, взятого из литературы, системы, уже реализованного проекта или просто придуманного человеком, в глаза не видевшего измеряемого процесса.
3) Ключевых показателей формируем столько, сколько это возможно в принципе – чем больше, тем лучше.

Номер раз обсуждать не будем – ясно без микроскопа.

Ошибка номер два наиболее логично вытекает из нашей любимой библиотеки ITIL. Там со времен второй версии к KPI относились так, что иногда становилось жутко. Как тонко подметил когда-то один коллега: берем аналогию процесса с автомобилем, где ключевые показатели – спидометр, тахометр и пр. Тогда KPI, приведенные в ITIL v2 – это намек на прибор, измеряющий обороты двигателя в милях, скорость в фаренгейтах и температуру двигателя в градусах. Цельсия или угловых градусах – изволь читающий угадать сам. А еще разработчики ITIL любят давать по несколько штук таких приборов, дублирующих показания в разных шкалах.

О чем говорят эти метрики? Общее количество чего – зарегистрированных, закрытых, открытых за период, или всего в системе? Каким средне- или долгосрочным целям соответствуют метрики? Каковы пороги "удовлетворительно – нормально – хорошо – отлично" для этих метрик? А что делать, если неудовлетворительно, если инциденты сваливаются в backlog мы их закрываем медленнее, чем регистрируем? Количество инцидентов вдруг сократилось на 20%, а потом еще на 30%? Это как, хорошо или плохо? Если хорошо – мы проактивны! Если плохо – чем же мы будем заниматься?

Ну ладно, бог с ITIL'ом. Наша любимая библиотека никогда не акцентировалась особенно на шаге измерения. Спасибо и за цикл Деминга, положенный в основу процессной модели. Возьмем разработанные системы Helpdesk. Их разработчики (о боже!) тоже читали ITIL и умеют фантазировать на тему KPI. Возьмем оттуда, ведь эта система была выбрана нами, а значит там должно быть большинство необходимых отчетов для подсчета KPI. На семинарах часто наблюдаю одна и та же забавную картину, где рабочая группа приступает к проектированию KPI. Процесс спроектирован, теперь его нужно как-то измерять. Хорошо, если в наличии шаблоны реализованных проектов. А давайте посмотрим на существующие наборы KPI? Те, что понравятся – оставим, а остальные додумаем уже потом. Я не то, чтобы против "посмотреть", однако в большинстве случаев такое "посмотрим" приводит к бездумному копированию чужих измерителей эффективности и результативности процесса на свой собственный.

Копирование возможно только в одном случае – если копируемый процесс соответствует поставленным целям, содержит качественные, опробованные KPI и он копируется целиком!

Ошибка номер три, пожалуй, самая известная и распространенная при пользовании ИТ вообще – обусловленная кажущейся легкостью получения данных, годных для отчетности в информационных системах. В момент, когда мы перестаем различать просто данные и информацию (данные, годные для анализа с целью принятия решений), обычно стартует ошибка номер три. "Мы пока сами не знаем, какая именно информацию нам понадобится" – а поэтому давайте разработаем как можно больше отчетности, избыточной, дублирующей друг друга. Отчеты – это же так просто! "Пусть их будет как можно больше, а уж мы точно разберемся, какие использовать" – обычная для многих проектов формулировка. И заказчики процессов управления ИТ стараются не отставать: сколько у вас KPI для процесса? Всего двадцать?! Да вы что, в гроб меня загнать хотите. Конечно нужно больше! И пошла-поехала генерация любых показателей, выдаваемых за KPI.

Ценная информация быстро тонет в бесконечном, фрагментарно обрабатываемом потоке данных. Отсутствует любая, хотя бы самая простая технология проектирования KPI.

Далее, в следующих разделах:
Определим терминологию и типы показателей
Несколько простейших советов, как избежать простых ошибок
Каким образом формировать цели для внедряемого процесса?
Если процесс уже функционирует, нужна ли ему цель?
Наброски к будущей технологии проектирования KPI