Для его успешного внедрения необходимо, чтобы на предприятии уже были реализованы регистрация и упр

У Рея Бредбери есть прекрасный рассказ «И грянул гром» о том, как группа путешественников во времени отправилась в далекое прошлое поохотиться на динозавров. Чтобы не изменить настоящее вторжением в события прошлого, специально подбирался момент, когда зверь должен был погибнуть, — и за мгновение до этого охотники могли без нежелательных последствий пристрелить свою жертву. Но однажды случилось непредвиденное: один из охотников испугался динозавра, оступился и случайно придавил ногой бабочку. Казалось бы, какое значение имеет эта бабочка в сравнении с миллионами лет жизни и триллионами живых организмов? Но бабочка оказалась звеном в цепи последовательных событий, и когда путешественники во времени вернулись в настоящее, они обнаружили много неприятных изменений, и даже случилось страшное: президентом Соединенных Штатов стал другой кандидат.

«Эффект бабочки» определяет ситуацию, когда цепь событий обусловлена некоторой заданной последовательностью, которой мы не можем управлять. Для ИТ-подразделения крупной компании это может быть следствием управления по принципу «действуй по ситуации». В этом случае ИТ–подразделение неизбежно становится игрушкой внешних сил, с течением времени количество проблем быстро нарастает и ситуация выходит из-под контроля.

Помимо «эффекта бабочки» существует и другое явление — назовем его «эффектом муравья», — когда разум руководителя, горячее желание и твердая воля могут переломить сколь угодно неблагоприятную тенденцию, изменить внешние обстоятельства, и дела в таком подразделении пойдут на поправку.

Казалось бы, сказанное достаточно ясно, но опыт подсказывает, что очень часто, когда приступают к решению задачи управления подразделением по ключевым показателям, думают только о разработке «волшебных» KPI (Key Performance Indicators — ключевые показатели эффективности), которые откроют путь в «светлое будущее». Увы, сами по себе показатели не работают, основой или потенцией для совершенствования процессов в любом подразделении является разум, желание и воля, проявляемые в первую очередь руководителями.

Эмоции против логики

Общеизвестным правилом управления, которому посвящены первые главы большинства книг на эту тему, является предварительная разработка стратегии, целей и задач совершенствования процессов; его нужно довести до каждого участника. Возможно, вы замечали, что обычно это не работает так, как хотелось бы руководителям или как представляется внешним консультантам: порой цели и задачи не отвечают ожиданиям, их формулировки подчиненные часто воспринимают так же, как дети воспринимают стишок, который придется наизусть выучить к празднику.

Чтобы цели работали, важна в первую очередь не логическая их составляющая, а эмоциональное наполнение, затрагивающее людей. Например, можно использовать бенчмаркинг, когда ставится цель догнать и перегнать сильного конкурента (разновидностью этого метода под наименованием «общий враг» в совершенстве владеют многие политики).

Чтобы сравнить силу воздействия логической и эмоциональной составляющих на формирование целей, представьте поле битвы, на котором две противоборствующие армии стоят в боевой готовности друг напротив друга. Командующий первой армии выходит вперед, поворачивается к своему войску, достает свиток с текстом и начинает: «Целью данного сражения является нанесение безусловного поражения противнику, которое определяется как потеря его личного состава не менее чем на 75% в течение двух запланированных часов путем оперативного маневрирования авангарда и …» По другую сторону полководец на вороном коне, обращаясь ко всем вместе и к каждому в отдельности, взывает: «Воины! Враг пришел на нашу землю, чтобы лишить нас свободы и наших детей — будущего! Наши жены с надеждой смотрят на нас! Да, врагов много, много больше чем нас! Но посрамим ли мы нашу честь, или …»

Применение модели зрелости

В последнее время для оценки качества процессов управления часто применяют модель зрелости. С хорошо проработанным вариантом ее реализации, который удобно использовать для оценки различных процессов управления ИТ–подразделением, можно ознакомиться в стандарте CobiT (рис. 1).

Рис. 1. Модель зрелости для управления ИТ-процессами
Но необходимо правильно понимать практическое значение этой модели. Она не предназначена для оперативного управления, не показывает, что нужно предпринять для повышения качества управления, — она позволяет оценить, где на шкале управляемости сейчас находимся мы, и где находятся другие, если это известно.

Ставя цель повысить зрелость процессов управления, не стоит забывать, что продвижение по модели зрелости попутно повышает и себестоимость процессов. Кроме того, высокий уровень зрелости еще не гарантирует качества ИТ-услуг с точки зрения заказчика, перед которым, в случае проблем, не прикроешься этим своеобразным «фиговым листком».

Связь между целями, моделью зрелости и ключевыми показателями можно описать следующим образом: цели определяют исходную точку и направление движения, вехи по мере продвижения к качеству управления отмечаются по модели зрелости, а непрерывное применение ключевых показателей по всем необходимым областям оценки и контроля действующих процессов не позволяет сбиться с пути.

Как объять необъятное

Перед определением ключевых показателей необходимо установить «области» измеряемых и контролируемых процессов. Разумеется, они должны охватывать в той или иной мере все направления деятельности ИТ-подразделения, и вместе с набором ключевых показателей такая «карта» будет уникальной для конкретного подразделения.

В теории набор ключевых показателей отдельного подразделения — как ИТ, так и любого другого — должен поддерживать реализацию общей стратегии компании. На практике российские компании пока еще не часто разрабатывают стратегию развития, которую можно использовать не только для декларативных целей. И даже если стратегические цели сформулированы, они чаще несут временной смысл, актуальный для данного момента развития компании. Вот типичные цели: достичь 20 % охвата рынка, построить десять распределительных центров, выйти на региональный рынок, достичь уровня EBITDA 12% и т.п. Подобные цели затруднительно непосредственно использовать для разработки ключевых показателей постоянных процессов ИТ-подразделения, они скорее определяют состав портфеля ИТ-проектов с собственными характеристиками.

На практике можно использовать другой подход, не зависящий от формального определения стратегии предприятия. У руководства любой крупной или средней компании очевидно есть некоторое представление о том, какое ИТ-подразделение является «хорошим». Это представление необходимо зафиксировать, чтобы использовать в дальнейшем. При этом следует выделить два принципиально различных подхода. Для развивающихся компаний процессы ИТ-подразделений обязаны в первую очередь поддержать это развитие, но не быть при этом «слабым звеном». Для стабильных компаний на первое место выходит эффективность подразделения как соотношение стабильного объема ИТ-поддержки к затратам на процессы. Попытка одновременно стремиться и к поддержке экспансии компании, и к эффективности процессов приведет, скорее всего, к провалу поставленных задач. Таким образом, документально зафиксированная на предприятии «оценка» ИТ-поддержки — «удовлетворительная», «хорошая», «отличная» — послужит основой для разработки стратегии развития ИТ–подразделения. Опираясь на стратегию, можно в дальнейшем разработать SLA, определить принципы финансирования, достаточные для осуществления задач подразделения. При этом карта ключевых показателей должна отражать либо приближение к согласованному с бизнесом представлению об ИТ-поддержке, либо его воплощение.

В хорошо организованной структуре области деятельности и области управления по ключевым показателям должны однозначно коррелировать с организационными единицами подразделения. Это позволяет сократить до минимума проблемы разделения функциональной ответственности, облегчить оценку и управление по ключевым показателям.

Следует также разделить ИТ-функции (области деятельности) на два направления: развитие и сопровождение. К развитию относится реализация проектов, крупных изменений в ИТ-архитектуре, совершенствование внутренних бизнес-процессов и реализация других инновационных задач. К сопровождению — эксплуатация и поддержка действующих процессов и ИТ-систем предприятия.

Для направления развития области управления по ключевым показателям можно разделить по принципу масштаба, например, на проекты и изменения (задачи, задания). Такое деление целесообразно, поскольку степень формального управления проектами должна быть гораздо выше, чем, например, небольшими задачами, а управление инновациями для различных функциональных направлений деятельности предприятия может быть одинаковым.

Рассмотрим крупную розничную компанию. В функции ИТ-подразделения по сопровождению входят: поддержка и обучение пользователей (включая Service Desk или Help Desk); сопровождение торговых процессов (магазинов) сети; сопровождение офисов и распределительных центров; сопровождение корпоративного программного обеспечения (ERP, WMS, торговое, кассовое ПО и пр.); техническое обеспечение, ремонт и логистика ИТ-оборудования.

Часто к сопровождению офисов относят сопровождение корпоративного программного обеспечения. Это целесообразно для небольшой компании, но не для крупной, так как ключевые показатели для них по смыслу различны: при оценке сопровождения офисов используются показатели для инцидентов типа «время реакции» (решения), а для сопровождения программных сервисов — «уровень доступности и производительности».

Два типа ключевых показателей

О KPI сейчас говорят много, но, к сожалению, зачастую совершенно без знания существа предмета управления. Это приводит к курьезам. В одной компании для оценки деятельности системного администратора был введен показатель: «количество вирусов, выловленных и устраненных в течение одного месяца». Совершенно понятно, как в этом случае должен действовать системный администратор, чтобы заработать себе на жизнь.

В торговой сети «Перекресток» (Х5 Retail Group) была введена следующая система ключевых показателей, доказавших свою эффективность в ИТ-управлении.

Все показатели разделены на два типа: собственно ключевые (KPI) и ситуационные (SPI — Situation Performance Indicators). К KPI относятся показатели, которые характеризуют эффективность организации процессов и/или их качество, например, «уровень доступности службы Service Desk для звонков пользователей», «выполнение SLA по решению локальных ИТ-инцидентов в магазинах», «процент наличия необходимого резерва ИТ-оборудования», «процент заданий, завершенных в запланированный срок». К SPI относят показатели, которые характеризуют внешнюю среду и общую ситуацию, и значения которых нельзя однозначно интерпретировать в отношении качества управления ИТ-подразделением, например, «количество регистрируемых инцидентов», «количество открытых проектов», «доли завершенных задач по отделам в общем количестве завершенных задач». Использовать их для оценки качества управления ИТ-процессами и особенно для мотивации сотрудников категорически не рекомендуется — результат будет скорее всего обратным желаемому. Это связано с тем, что на SPI активные действия ИТ–персонала могут влиять лишь частично. Например, количество регистрируемых инцидентов может расти по мере роста компании, в результате сезонных или случайных факторов, а количество открытых проектов может быть обусловлено потребностью бизнеса в активизации проектной деятельности. Роль SPI в том, что они позволяют оценить изменение измеряемых тенденций в лучшую или худшую сторону и, исходя из этого, лучше планировать свои действия.

Показатели KPI чаще измеряются в процентах, что выражает их глубинный смысл, характеризующий степень достижения желаемых или требуемых величин. Показатели SPI чаще измеряются в абсолютных единицах. При этом оценка какого-либо процесса может состоять и из KPI, и из SPI. Например, показатель «процент выполнения запланированных задач (заданий) в установленный срок» отражает соблюдение требований к качеству управления для отдела программных разработок. Но одного этого показателя для оценки процесса явно недостаточно. Необходимо его дополнить, например, «количеством выполненных задач за измеряемый период». Производительность работы отдела разработки из пяти человек со 100-процентным выполнением двух заданий в месяц гораздо ниже, чем производительность того же отдела с 50-процентным выполнением четырнадцати заданий при одинаковом качестве и плановых затратах времени.

Лезвие бритвы

К выбору ключевых показателей, необходимых для управления процессами, следует подходить чрезвычайно тщательно. Здесь действуют правила: «не уверен — не включай» и «лучше меньше, да лучше». Иначе говоря, лучше начать с небольшого количества самых актуальных показателей и постепенно расширять их количество. Все ключевые показатели сразу необходимо отнести либо к KPI, либо к SPI.

Избежать ошибок при выборе ключевых показателей помогут следующие рекомендации. Во-первых, не надо забывать, что показатели должны быть измеримыми, причем не обязательно в непрерывной форме (например, от 0 до 100), иногда вполне достаточно бинарного выбора : «выполняется» — «не выполняется». Физический смысл показателей должен быть ясен и иметь однозначное толкование для всех. Показатели типа KPI должны быть полностью в сфере ответственности контролируемых процессов (это не относится к показателям типа SPI). И, наконец, показатели — это инструмент, а не цель управления. Они важны, только когда их используют на практике, иначе они неэффективны, поскольку на подготовку даже автоматизированно измеряемых показателей требуются ресурсы. Иначе говоря, анализируйте только то, чем можете управлять!

Неизмеряемые показатели (то есть те, что были определены для целей управления, но по тем или иным причинам их использование затруднительно) должны быть просто убраны, чтобы на панели управления не появлялся «балласт».

На рисунке 2 приведен «снимок» портала управления, построенного на технологиях Microsoft SharePoint и Microsoft Business Scorecard Manager, применяемых для управления ИТ в ТД «Перекресток». Актуальные значения в целях демонстрации изменены.

Рис. 2. Панель карты ключевых показателей
Количество показателей не должно быть слишком велико, иначе в них трудно разобраться, выявить тенденции и закономерности. На практике удобно использовать двухуровневую систему: показатели отражают самое важное, а подробности для анализа лучше искать в специализированных отчетах. Например, показатель «уровень доступности в процентах для выделенных каналов связи провайдера N» характеризует общее качество связи, а при необходимости можно заглянуть в подробный отчет по этому провайдеру по каждому из каналов для предъявления конкретных претензий.

Период измерений для показателей может составлять один день, неделю, месяц, квартал, полугодие, год. Наиболее часто используются интервалы длительностью в неделю и месяц. Выбор должен быть связан с периодом управления — частотой совещаний, на которых производится анализ и принимаются решения, но не меньше статистического минимума. Например, бессмысленно измерять уровень доступности ERP-системы за один день или уровень удовлетворенности руководства ИТ-подразделением за одну неделю. В первом случае он будет слишком скачкообразным, во втором случае пойдет вниз и совсем исчезнет …

О чем часто забывают

Управление по ключевым показателям станет реальным механизмом управления, только если будут использоваться адекватные схемы мотивации.

Управление по ключевым показателям можно однозначно привязать только к материальным аспектам. Ежемесячная почетная грамота для сервис-инженера, постоянно выполняющего план, скорее всего будет восприниматься не как поощрение, а как издевательство.

Схемы оценки линейного персонала и руководителей различны.

Работа большинства простых сотрудников должна оцениваться ежемесячно по личным KPI, которые могут косвенно соотноситься с ключевыми показателями по направлениям деятельности ИТ-подразделения в целом. Например, для направления сопровождения магазинов розничной компании важно выполнение SLA по времени решения типичных инцидентов. Напрямую привязать выполнение SLA к конкретному инженеру поддержки в некоторых случаях нельзя, так как он лично не может выполнить всю работу для решения инцидентов. Разумнее будет назначить инженеру личный KPI, основанный на объеме выполненной работы. Иногда руководители, чтобы облегчить себе жизнь, вводят «круговую поруку», когда вознаграждение для каждого возможно, только если вся функциональная группа сработала отлично. В этом случае часто начинает действовать «принцип коммуналки», то есть у сотрудников возникает вопрос: «Зачем работать хорошо, если общая ситуация от меня мало зависит?» Лишь в очень компактной группе, где все ее члены хорошо сработались друг с другом, можно использовать такой принцип оценки.

Мотивацию линейных руководителей (как и некоторых ключевых сотрудников) важно привязать к главным показателям по их направлениям деятельности. Если организационная структура подразделения спроектирована правильно, то на каждого руководителя будет отнесен свой показатель (или спектр показателей), не разделяемый с другими, и каждый будет понимать, что выполнение KPI зависит только от него, находится в рамках его полномочий и ответственности. Для руководителей целесообразно увеличить период оценки с одного месяца до одного квартала.

Еще раз отметим, что без действенной системы материальной мотивации для крупного ИТ-подразделения управление по ключевым показателем превратится просто в наблюдение.

В приведенном выше примере рассматривается крупная розничная компания. При других масштабах деятельности необходимо критически переосмыслить выбор областей измеряемых и контролируемых процессов. Многие тонкости, конечно, не упомянуты, но, чтобы принимать правильные решения в той или иной конкретной ситуации, вполне достаточно простого здравого смысла опытного руководителя.

Сергей Котов — директор по ИТ ЗАО ТД «Перекресток»; kotov_s@perekriostok.ru