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

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

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


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

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

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

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

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

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

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

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

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


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

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

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


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

    FRT / ART


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

    MTTR


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

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


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

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

    CSi


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

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

    1. Время реакции на обращение, t1;
    2. Время решения заявки, t2;
    3. Качество решения заявки, 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 — медленно;

    ${q}$

    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}$


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

    Полученные значения интерпретируются согласно следующей таблицы
    Значение 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 — процент заявок решенных в рамках первого обращения за поддержкой.
    Дата-центр «Миран»
    151,70
    Решения для аренды и размещения ИТ-инфраструктуры
    Поделиться публикацией

    Похожие публикации

    Комментарии 12

      0
      "… при необходимости корректировать тарифы сдельной оплаты труда на следующий месяц." — Бедные инженеры, всегда в напряжении у вас на работе находятся.

      "… Расчета индекса производится исключительно на основании субъективных оценок клиента которые мы получаем после выполнения каждой заявки"
      А если я как клиент не хочу давать вам обратную связь по поводу выполненной заявки, то вы как это измеряете?
        0
        Напрасно Вы так. Прозрачность и прогнозируемость финансовых отношений работодателя и работника дорого стоит. К тому же мы довольно сильно эволюционировали, если расположить нашу модель на шкале рыночных отношений, с одной стороны которой будет капитализм со звериным лицом (прям как по Марксу), а с другой скандинавская модель социализма, то мы гораздо ближе к скандинавам.
          0
          Это да… мы считаем что «молчуны» довольны… Если за месяц feedback не прилетел CSi = 0,25.

          Полагаю, что в большинстве случаев это справедливо.
            0
            Я вообще никому никакого фидбэка не даю. У нас раньше были опросы клиентов по поводу их удовлетворенности выполненными заявками и либо в 75% случаев нас посылали, не предоставляя фидбэк (но при этом дальше все сотрудничали без проблем), либо писали, что всё хорошо, и всё на 5 делается, а так же получали странные комментарии к выставленной «оценке» в виде «что за ерунду вы спрашиваете и почему я должен тратить на это время?». В итоге убрали эти фидбэки и одним уровнем ненужного контроля стало меньше. Затем убрали ки-пи-ай у людей — они получали свой оклад, при этом по SLA
            всё стало даже лучше и уровень косяков сократился на минимум, у людей появился интерес к работе и они стали проявлять инициативы при решении инцидентов, а не просто как работы «трудились на благо офиса».
              0
              Наш опыт отличается.
              И feedback разный и диапазон комментариев от “горите в аду” до “дайте премию инженерам ТП”.

              К сделке мы пришли от оклада. У оклада минусов гораздо больше imho.
                0
                Как интересно. Минусов больше от оклада для бизнеса, потому что все разгельдяйничали? Не поделитесь?
                  0
                  А чего бы и нет…
                  Вы вопрос пожалуйста поточнее сформулируйте.

                  Сознательно упрощая “конструкцию”, для начала скажу так, плюсов у оклада ровно один — простота администрирования. Все остальное минусы
          0
          Читали «Метрики для управления ИТ-услугами» от Альпина бизнес-бук?
            0
            Всё круто, но без описания структуры именно вашего отдела, типичных кейсов и т.д. это просто набор умных слов, цифр и формул, который может быть полностью нерелевантен для других.
              0
              Спасибо за подачу))

              Сделаю как при случае
                0
                Это ЦОДовский саппорт, если писать нюансы, будет слишком объемно для одной статьи.
                Вкратце предположу, 3 уровня. 1 — сис. адмниы, 2 — сис. инж. с доступом в маш зал, 3 — сетевики, энергетики и прочие узкие специалисты.
                Клиент пишет заявку: дайте больше мощ на стойку, будем ставить новое оборудование Х, эскалируют энерготам. Или завис IPMI — сис инж идет ребутать в маш зал.
                  0
                  Вы правы, ньюансы есть)) У нас не так. Если в двух словах, Вы техподдержку надели функциями отдела эксплуатации и службы главного инженера.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое