В сфере информационных технологий отношение к личным KPI сотрудников колеблется от абсолютизации их значения в оценке результатов деятельности до полного и категорического неприятия. Насколько оправдана абсолютизация KPI, зависит от конкретной системы показателей, а вот причины категорического неприятия заслуживают обсуждения. В статье представлен практический опыт построения системы KPI службы поддержки крупной организации.
Как правильно приготовить KPI
На заявление о неприемлемости системы KPI ни в каком виде хочется ответить – «вы просто не умеете её готовить». Прежде всего, следует разобраться с самим термином. Прижившийся по непонятной причине перевод KPI (Key Performance Indicator) как «ключевой показатель эффективности» представляется неточным и неотражающим реальное содержание – гораздо уместней «ключевой показатель производительности» или просто «ключевой показатель деятельности». Об эффективности можно судить на основе совокупности KPI, то есть по производным от исходных показателей. Исходные же KPI должны работать по аналогии с физическими датчиками, то есть показывать объективные данные, как термометр показывает температуру, а барометр давление. Невозможно судить о погоде только по показанию термометра, необходимо достаточно большое количество показателей, но без термометра тоже не получится. Эффективность оценивается на основе системы сбалансированных показателей (BSC), в которую должны входить KPI, измеряющие конкретные параметры деятельности.
Основное требование к KPI – адекватное отражение реальности. Попытка рассчитать KPI на основе уже имеющихся учетной системы и процессов на 99% обречена на неудачу. Процессы и система должны изначально строиться так, чтобы из них можно было вычислить KPI каждого конкретного сотрудника. Если операционная модель и учетная система строились без учета необходимости вычисления KPI, сделать это с помощью имеющегося функционала будет практически невозможно. Например, в устаревшей модели учета деятельности службы поддержки в обращении от пользователя устанавливается крайний срок выполнения и обращение эскалируется на различные рабочие группы. В случае, если обращение обрабатывается хотя бы двумя рабочими группами, невозможно адекватно рассчитать KPI, основанный на просрочке крайнего срока. Общий крайний срок является полной бессмыслицей при наличии хотя бы двух рабочих групп, последовательно обрабатывающих обращение, так как первая успевает за полчаса до окончания крайнего срока, а вторая группа получает на вход уже практически просроченное обращение, но еще в пределах крайнего срока. В таких условиях KPI по просрочке будет работать как магнитный компас в высоких широтах, отражая все что угодно, кроме реальности.
Практическое решение в данном случае заключается в обязательной фиксации крайних сроков не только в целом по обращению, но и по каждому заданию, выставляемому на рабочую группу (рис.1). В этом случае за крайний срок по заданию отвечает лично специалист, взявший это задание в работу. Причем соблюдение всех крайних сроков должно обеспечить соблюдение общего крайнего срока в обращении. При такой организации процесса реально построить два KPI по просрочке – один может рассчитываться на основании отношения просроченных заданий к общему числу выполненных, а второй исходя из общего времени просрочки.
Рисунок 1. Фиксация крайних сроков – два варианта. В случае синих рабочих групп у виновника просрочки соответствующий KPI не будет уменьшен, пострадает рабочая группа, по сути не причастная к просрочке. В случае зеленых рабочих групп пострадает виновник просрочки.
Стратегии поведения и их зависимость от KPI
Зачастую встречаются KPI, вычисляемые на основании количества выполненных обращений. Каким образом сотрудник может управлять этим параметром? Только через проактивную работу, устраняя причины возникновения инцидентов и снижая количество обращений. Но если чем больше выполненных обращений, тем больше KPI – какой смысл в проактивной работе? Кроме того, если обращения не однотипные, то, при использовании KPI от количества выполненных обращений, повышаются риски с выполнением трудоемких обращений и заданий, с ними связанных, – их будут брать в работу в последнюю очередь. Тем не менее, надо иметь показатель, учитывающий объемы работ, выполняемых сотрудниками. Для этого целесообразно использовать автоматизированное списание рабочего времени, что обеспечивается соответствующим построением процессов и функционалом учетной системы. По объему списанного рабочего времени можно понять и загруженность сотрудников, и сравнительные объемы работ, которые они выполняют.
Но при этом максимизировать данный KPI можно, если взять в работу одно задание утром и закрыть его же вечером. Избежать подобных коллизий позволяет использование взаимосвязей KPI. Показатели должны определенным образом зависеть друг от друга, складываясь в систему и формируя у сотрудника правильную стратегию поведения. Если просто сказать, что на улице +20 градусов, то это не будет исчерпывающей характеристикой температуры, так как люди воспринимают температуру по-разному. Для понимания того, как температура воздуха ощущается человеком, используется параметр «эффективная температура», который зависит от температуры воздуха, силы ветра и влажности. В случае с KPI необоснованная максимизация одного из параметров приведет к минимизации других, что будет означать неверную стратегию поведения сотрудника. Например, если сотрудник будет необоснованно долго держать задание в работе, то у него спишется нужное количество времени, но при этом возникнет просрочка, образуется очередь заданий, пользователи будут недовольны – и всё это отразится в соответствующих KPI, что снизит итоговый показатель.
Нормирование KPI
Серьезную роль в расчете KPI играют нормирующие показатели. Как определить, быстро ли берутся в работу задания? Время реакции в 100 секунд – это много или мало? Возможны два сценария нормирования. По одному сценарию значение KPI быстро увеличивается при приближении к норме или наилучшему значению параметра, достигая предельных значений (рис.2). Второй сценарий: значение KPI достигает максимума в норме и снижается при отступлении от нормы. В соответствии с первым сценарием хорошо нормируются показатели типа времени реакции, когда чем меньше (или чем больше), тем лучше. По второму сценарию хорошо нормируются показатели типа списания рабочего времени, когда лучшим показателем будет точное попадание в коэффициент участия в поддержке, а отклонения уже ненормальны.
Рисунок 2. Графики функций KPI. KPI, показанный зеленой линией, имеет максимум в случае, если Параметр равен 0 (пример — время реакции). KPI, показанный синей линией, имеет максимум в случае достижения нормы 0,75 (пример — процент закрытия обращения на линии).
Обратная связь
Важнейшую роль в построении системы личных KPI играет обратная связь от пользователей и от функциональных руководителей. Учетная система должна обеспечивать простые способы получения адекватной обратной связи и доведение этой связи до специалиста. Без обратной связи система KPI становится излишне механистической и весьма далекой от интересов конечных пользователей. Самой простой и достаточно эффективной обратной связью является выставление оценки пользователем после выполнения обращения и выборочная процедура постконтроля со стороны функционального руководителя по выполненным заданиям. В результате специалист получает и оценку пользователя, и оценку руководителя, которые учитываются в KPI.
Некоторую сложность могут вызвать расчеты KPI по заданиям, которые не взяты в работу специалистами. Может сложиться ситуация, когда выгодно держать просроченное задание и не брать его в работу длительное время. Для исключения подобных ситуаций необходимо вычислять KPI, основанный на количестве назначенных, но не взятых в работу заданий на всех рабочих группах, в которые входит конкретный сотрудник. Увеличение очереди таких заданий минимизирует соответствующий KPI, что сделает невыгодным создание очереди не взятых в работу заданий.
Адаптация KPI под особенности работы подразделений
Предположим, нам удалось построить систему KPI, которая адекватно отражает существующую реальность. Однако неизбежно возникает вопрос – каждый ли KPI одинаково важен для всех подразделений, занимающихся поддержкой? Очевидно, что нет. Для сотрудников первой линии поддержки одним из важнейших показателей всегда будет время реакции, а для сотрудников второй линии важнее будет длительность решения проблемы. Система KPI, механически распространенная на все подразделения, которые занимаются поддержкой, неизбежно будет отторгнута, так будет работать неадекватно реальности. Для успешного распространения системы KPI на различные подразделения обязательно должны учитываться особенности работы каждого из них, что проще всего сделать, вычисляя общий интегральный KPI при помощи системы весов. Вес каждого KPI и величина нормирующих показателей индивидуальны для каждого подразделения. Практика показывает, что наибольший вес имеют KPI, отражающие обратную связь от пользователя, а все остальные KPI могут иметь различные величины, отражающие специфику работы подразделения.
Интегральный KPI, рассчитанный с учетом специфики работы подразделений, является серьезным инструментом для оценки сотрудника. Его можно использовать как для аттестации, так и для прямого расчета мотивации сотрудников. В расчете мотивации эффективно работает двухступенчатая система расчета, при которой сначала вычисляется средний для подразделения KPI и общий фонд премирования подразделения, который может оказаться равным нулю при низком среднем KPI. Если фонд премирования подразделения сформирован, рассчитываются индивидуальные премии на основании интегрального KPI сотрудников.
Основываясь на практическом опыте, можно утверждать, что построение эффективной системы личных KPI сотрудников является весьма сложной задачей и не сводится к механическому вычислению каких-либо параметров. Основная цель – построить процессы таким образом, чтобы вклад каждого специалиста в решение конкретной задачи был точно понятен и доступен для автоматизированной обработки. Только в этом случае можно сделать шаг от мотивации сотрудников на основании личных впечатлений и предпочтений руководителя к объективной оценке деятельности сотрудника. Что, в свою очередь, позволит снизить внутреннюю конкуренцию за личные предпочтения руководителя и улучшит сотрудничество в подразделениях поддержки. А создание системы поддержки с высоким уровнем внутреннего доверия и сотрудничества является ключом к повышению качества ИТ-сервисов.
Александр Огнивцев — руководитель управления сервисной поддержки, СГ «Альфастрахование»