Некоторое время назад на подъезде моего дома появился тоненький листок, на котором типографским не очень качественным способом было гордо отпечатано: "МОЛНИЯ! Меры Собянина для москвичей" (именно так, без имени-отчества, ладно хоть не "Собянинские меры"). На бумаге формата А3 мелким текстом перечислено несколько десятков пунктов, почти в каждом из которых – цифры, даты, сроки… Сплошная конкретика. Выделено столько-то миллионов рублей, поручено тогда-то сделать то-то, к такому-то сроку будет сделано… ну и далее в том же духе. Несмотря на плохенькую печать эта агитация "выглядит красиво, и даже завораживает" (C) Шкиппер из пингвинов Мадагаскара.
Подавляющее большинство населения будет очень довольно, и многие из них строем в декабре сделают правильно подсказанный выбор. Те, кто поумнее, чертыхнутся очередной раз про нынешних воришек, да пойдут себе дальше. Особо одарённые выберут единственно правильный метод из предложенных – таких будет меньше всего, поэтому задача тех, кто придумывал и вешал агитацию, будет решена.
И ведь понятно, что заявленные KPI не будут достигнуты – история наглядно демонстрирует всю невозможность такого сценария. Также понятно, что после декабря никто и не вспомнит про эту "молнию", а давшему обещания ничего не будет за их неисполнение. Однако тактика работает.
При чём здесь ИТ, спросите вы? Правильный и своевременный вопрос, переходим от примера к сути.
На мой взгляд во многих ИТ-отделах наблюдается схожая картина. Отбросим варианты, когда KPI не определены вовсе; в тех случаях, когда они установлены, есть ли целевые значения? Кто, когда и как их определил? Кто и в каких случаях имеет право и возможность скорректировать установленные цели?
Видел, как целевые значения выбираются по политическим соображениям. Видел, как они назначаются по принципу "наш бизнес именно этого хочет, поэтому мы должны постараться". Оба упомянутых способа приводят к нереалистичным значениям KPI, что не позволяет ни выявить моменты для улучшения, ни определить (и определять) приоритеты в работе, ни наказывать/поощрять в конце месяца.
В своих первых проектах я старался придумать для каждого процесса множество KPI, точек измерения и контроля, расставленных по всему процессному workflow, а также по входам, выходам, ресурсам и управленческим воздействиям сверху (классическая картинка процесса). Таблица выходила большой и насыщенной, а обоснованно придумать целевые значения для большинства KPI никак не получалось. Через некоторое время я понял, что не в количестве дело. Лучше меньше, но работающих, с понятным механизмом измерения и установленными "здравыми" целевыми значениями.
Второй вопрос – про обратую связь, в том числе про "наказывать/поощрять". Даже если KPI определены, и целевые значения разумны и достижимы, то на что влияют результаты конкретного отчётного периода? Кем и как анализируются, какие делаются выводы? Самое важное – какие за этим следуют действия?
Здесь мне повезло больше. Буквально в первом "коммерческом" проекте по внедрению Service Desk и процессов поддержки, который я выполнял уже как консультант, а не "работая на стороне заказчика", нам удалось запустить цикл еженедельного контроля в виде оперативных совещаний, на которых каждый менеджер процесса представлял чётко измеренные KPI по своему процессу за неделю, показывал динамику, объяснял отклонения, и на этом же совещании с участием владельца процессов принимались решения – что с этим делать, нужно ли и какие меры принимать, в том числе организационные и административные. Обратная связь работала и помогала.
Итак, когда речь заходит о KPI, нужно не забывать найти чёткие ответы как минимум на следующие вопросы:
- "а сколько надо-то? почему именно столько? возможно ли это?"
- "а что будет, если не достигнем?"
PS.
Конечно же, вопросов про KPI гораздо больше, но о них – в следующий раз, когда новую "молнию" повесят. Если повесят.
каждый менеджер процесса представлял чётко измеренные KPI по своему процессу за неделю, показывал динамику, объяснял отклонения, и на этом же совещании с участием владельца процессов принимались решения — что с этим делать, нужно ли и какие меры принимать, в том числе организационные и административные.
Ничего личного, но это мне напомнило одну книжку, которую я читал в детстве. Суть в том, что в одной школе пионерский актив придумал графики поведения, в которые ежедневно проставлялись некие баллы, определяемые по принципу: за “хорошие” поступки баллы плюсовались, за “плохие” – минусовались. Типа, помог кто-то расставить книги в библиотеке – получи +10 баллов, плюнул с лестницы вниз – получи -10 баллов.
Кончилось, скажем так, в юмористическом стиле. Во-первых, этот момент быстро просекли герои книжки и специальным образом организовали сбор баллов, чтобы получить необходимую конфигурацию кривой. Во-вторых, некие проверяющие, увидев новшество, дорисовали несколько черточек, что в итоге дало график в форме слова “ЧУШЬ”.
К чему это я?
– Должны ставиться правильные, т.е. нужные цели, причем нужные для бизнеса. (т.е. первый вопрос все-таки должен быть “зачем это нужно?”) Например, на одном производственном предприятии любой сотрудник (и любой ИТишник в т.ч.) четко понимали, что вся работа была направлена на обеспечение бесперебойности отгрузки продукции. И KPI ИТ-процессов должны были быть заточены именно на это.
– Документирование и отчетность должна быть не просто так, а позволяющая бизнесу (а не только владельцам процессов, как в приведенном примере) контролировать, управлять, приоритизировать различные нужные им аспекты ИТ-услуг, т.е. управлять услугами и их качеством.
– Должна быть обратная связь, причем в обе стороны: и в отношении ИТ-процессов, и в отношении бизнеса. Например, если вдруг бизнес захочет повысить скорость обработки инцидентов, то это и на ИТ должно отразиться (например, придется бегать быстрее или больше людей посадить на обработку), и на бизнесе (изменится цена услуг за требуемый уровень качества).
– Ну и ответственность за достижение/недостижение показателей само собой. Для глубины понимания, так сказать….