ASol 27 июн 2019 в 08:51

KPI технической поддержки Миран

6 мин

17K

Блог компании Дата-центр «Миран»Service Desk*

" — А у вас случайно нет такого знакомого с красным лицом, тремя глазами и ожерельем из черепов? — спросил он.
— Который между костров танцует? А? Еще высокий такой? И кривыми саблями машет?
— Может быть и есть, — сказал он вежливо, — не могу понять о ком именно вы говорите. Знаете, очень общие черты. Кто угодно может оказаться."

Виктор Пелевин, «Чапаев и пустота»

Привет, Хабр! Меня зовут Александр Соловьев, я руковожу технической поддержкой в дата-центре Миран.

Некоторое время назад я принимал участие в интересном митапе, посвященном KPI технической поддержки. В целом это было полезное мероприятие с точки зрения обмена опытом. Но все же, остался осадок некоторой “незавершенности”. Причина прежде всего в том, что участники мероприятия делились своим опытом, а какого-то обобщения или даже итогов ни они ни я не подвели.

Мероприятие было организовано сообществом специалистов техподдержки “SUPNET” которое, судя по последней публикации на их официальной страничке, от сентября 2018, “ушло в нирвану”.

Поэтому я взял на себя смелость в этой статье поделится своим наработками и попробовать обобщить сказанное тогда на основе своего опыта.

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

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

Итак, KPI у нас делятся на три группы:

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

Показатели эффективности

Начну с эффективности.

Cредняя зарплата инженера техподдержки;
FRT — среднее время первого отклика на заявку;
ART — среднее время выполнения заявки;
MTTR — среднее время ремонта.

Средняя зарплата инженера

Поскольку заработная плата у нас сдельная, смысл этого индикатора — показать менеджменту, на каком свете, по выражению нашего генерала, находится ФОТ инженеров технической поддержки. После ввода в эксплуатацию “балансировки” ФОТ через нефинансовую мотивацию актуальности у индикатора поубавилось, но в целом он считается и поныне. Добавлю, что значение индикатора рассчитывается для каждой линии технической поддержки, что позволяет уже мне держать руку на пульсе и при необходимости корректировать тарифы сдельной оплаты труда на следующий месяц.

FRT / ART

Оба показателя “растут” из SLA (Service Level Agreement). Следуя SLA, при превышении FRT / ART у клиента появляется право на перерасчет размера оплаты услуг подвергшихся деградации. На мой взгляд, эти индексы по смыслу похожи на среднюю температуру по больнице). В практическом плане пользы от индексов не много, единственное что они позволяет менеджменту компании понять что заявленные в SLA показатели примерно выполняются. Гораздо полезнее процент нарушений времени реакции / выполнения заявки, эти индикаторы позволяют быстро и наглядно оценить динамику обработки заявок технической поддержкой.

MTTR

Широко известный в узких кругах индикатор (он же, IRT — incident Resolution Time), среднее время ремонта, в нашем случае польза от индикатора невелика поскольку предоставляемые нашей компанией услуги по характеру очень разнятся. Может в дальнейшем будем считать MTTR отдельно для каждого продукта. Однако, поскольку это действительно известный индикатор мы его считаем.

Показатели результативности

Перейдем к результативности.

EKi — индекс уровня знаний сотрудника;
CSi — индекс удовлетворенности клиента обслуживанием;
FRTR — процент нарушения времени реакции на обращение;
ARTR — процент нарушения времени выполнения заявок.

CSi

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

Значение индекса зависит от трех параметров:

Время реакции на обращение, t₁;
Время решения заявки, t₂;
Качество решения заявки, q.

Формула для расчета CSi следующая:

$CSi=\frac{3}{({t_1}^{t_1}+{t_2}^{t_2}+{q^q})}$

Диапазон возможных значений параметров приведен в таблице

Параметры	Значения
${t_1}$	1 — быстро; 2 — удовлетворительно; 3 — медленно;
${t_2}$	1 — быстро; 2 — удовлетворительно; 3 — медленно;
$display$	1 — хорошо; 2 — удовлетворительно; 3 — плохо;

Параметры

Значения

${t_1}$

1 — быстро;
2 — удовлетворительно;
3 — медленно;

${t_2}$

1 — быстро;
2 — удовлетворительно;
3 — медленно;

$display$

1 — хорошо;
2 — удовлетворительно;
3 — плохо;

Полученные значения интерпретируются согласно следующей таблицы

Значение CSi	Вывод
CSi = 1,0	Клиент полностью удовлетворен обслуживанием
0,25 ≤ CSi < 1,0	Обслуживание находится на приемлемом для клиента уровне
CSi < 0,25	Клиент не доволен обслуживанием

EKi

Индекс уровня знаний сотрудника показывает соответствие знаний сотрудников минимально допустимому уровню приемлемому для инженера технической поддержки. Позволяет ~~пресечь порожние разговоры о некомплектности инженеров~~ показать менеджменту компании насколько компетентны и готовы к работе инженеры технической поддержки. Индекс не очень заходит инженерам, но хорошо заходит менеджменту и нашим пиарщикам).

Расчета индекса производится на основании объективных данных полученных в результате регулярной проверки тренировки знаний инженеров, проводимой по методике имитационного моделирования, а именно решения типовых ситуаций называемых юзкейсами. Кому интересно, подробнее про управление знаниями в техподдержке рассказывал на KnowledgeConf 2019.
В нашей компании EKi рассчитывается как отношение успешно выполненных юзкейсов к общему количеству юзкейсов за период.

$EKi=\frac{U_w}{U_a}$

где,
U_w - количество успешно решенных инженером юзкейсов за отчетный период;
U_a - общее количество решенных инженером юзкейсов за отчетный период.

Полученные значения интерпретируются согласно следующей таблицы

Значение EKi	Вывод
EKi > 0,95	Знания инженера более чем адекватны занимаемой позиции
0,85 ≤ EKi ≤ 0,95	Знания инженера находятся на приемлемом уровне
EKi < 0,85	Знания инженера не достаточны

Уровни 0,85 и 0,95 получены нами ~~экспериментально~~ экспертно, в результате более чем двухлетней практики управления знаниями инженеров технической поддержки.

Процент нарушения времени реакции / времени выполнения

Индексы процент нарушения времени реакции / времени выполнения я упоминал выше. По сути показывают насколько часто техподдержка нарушает SLA в части времени реакции и времени выполнения заявок.

Производственные показатели

Ну напоследок, производственные показатели:

количество обработанных технической поддержкой заявок за отчетный период:
- из них звонков;
- из них сообщения от системы мониторинга;
- из них отклонено;
- из них клиентские;
количество заявок связанных с эксплуатацией продукта в отчетном периоде:
- из них инцидентов;
- из них обращений;
- суммарное время “отказа в обслуживании” для всех клиентов по продукту за отчетный период.

Есть правило определяющее соотношение KPI для оценки эффективности работы в целом. Согласно этого правила индикаторы должны распределятся в пропорции 10/80/10 = показатели эффективности / производственные показатели / показатели результативности.

По этой причине производственных показателей много и я остановлюсь только на самых важных с моей точки зрения.

Количество обращений в техническую поддержку

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

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

Количество заявок связанных с эксплуатацией продукта

С другой стороны имеет смысл интегрировать обращения касающиеся каждого из наших продуктов (услуг) в одноименные группы. Например, в нашем случае, целесообразно группировать обращения связанные с услугами аренды вычислительных мощностей и услугами связанными с размещением оборудования в дата-центре в разные группы. Хорошая практика когда внутри группы обращения делятся на общее количество обращений, количество “отказов в обслуживании” и общее время простоя по услугам входящих в продукт.

Заключение

~~Когда было уже поздно что существенно менять~~ Как обычно, после написания статьи гуглил KPI технической поддержки, нагуглил несколько интересных статей, в вот пара из них:

Осмыслил прочитанное и ничего в своей статье менять не стал, потому что так мне кажется честнее и естественней. При желании, читатель может проверить сам насколько наша техподдержка “в тренде”.

Пожалуй главное что вынес из прочитанного, в нашей техподдержке следует завести два дополнительных индекса:

1. FCR — количество заявок решенных в рамках первого обращения за поддержкой;
2. FTFR — процент заявок решенных в рамках первого обращения за поддержкой.

Теги:

Хабы: