У меня есть серия заметок о метриках (metrics) и ключевых показателях результативности (Key Performance Indicators, KPIs), для оценки нескольких областей Управления ИТ-услугами (IT service management). И они были очень популярны, т.к. посвящены теме, в которой многие людей ищут подсказки. Вот эти заметки:
Как определить метрики для процесса Управления изменениями (перевод, оригинал)
Как определить метрики для процесса Управления проблемами (перевод, оригинал)
Как определить метрики для процесса Управления инцидентами (перевод, оригинал)
Сбалансированная система показателей для ключевых показателей IT (перевод, оригинал)
На одну из них я получил запрос: “А как насчет техподдержки?”. Ниже мои мысли о том как можно “посчитать” техподдержку.
Рекомендуемая картина мира при определении метрик и ключевых показателей
В предыдущих заметках объясняется, почему важно создавать свои собственные метрики вместо простого и бездумного копирования их списков из книг ITIL или моего блога. Нет двух идентичных компаний и примеры из книг или блогов способны только показать вам возможности, а не быть использованы без адаптации.
Также стоит помнить о пересмотре ключевых показателей, это позволит со временем менять показатели, которые хорошо работали, а потом потеряли релевантность. Не забывайте, что “K” в KPI означает ключевой, так что вам стоит сконцентрироваться на наиболее важных для вас моментах. Вам не стоит измерять и отчитываться обо всем, что вы сможете измерить.
Также нужно прояснять понимание целей и критичных факторов успешности (Critical Success Factors, CSFs), которые необходимо выполнить, чтобы обеспечить достижение целей. Каждый ключевой показатель должен поддерживать одну или более целей или критичных факторов. Отчеты и обсуждения с заказчиками стоит вести о целях и критичных факторах, их поддерживающих, а не о ключевых показателях. “I” в KPI означает индикатор. Показатели - это не доказательство достижения цели, а всего лишь индикатор, помогающий понимать тренды и проблемы.
Цели и критичные факторы для техподдержки
Та что можно сделать для техподдержки? О чем в стоит думать? Я предлагаю несколько идей, которые могут быть включены, как цели или критичные факторы их достижения для техподдержки.
Мы делаем для пользователей простым и удобных взаимодействие с нами, когда они обращаются для помощи, когда задают вопросы или когда мы предоставляем им информации о ходе работ
Мы хорошо общаемся с нашими пользователями, поддерживаем их достаточным объемом информации и соответствуем их ожиданиям
Мы решаем пользовательские инциденты быстро и эффективно
Мы выполняем запросы на обслуживание быстро и эффективно
Мы достигаем высокого уровня удовлетворенности заказчика
Это только некоторые примеры, которые можно использовать в качестве целей и критичных факторов, их обеспечивающих, для техподдержки. Еще раз потрю, что не копируйте бездумно их, лучше присесть с заказчиками и определить свои собственные, а это список может стать отправной точкой.
Я использовал термины “цели или критичные факторы” (“objectives or CSFs”) для обозначения высокоуровневых понятий. Мы провели бесконечное число обсуждений о разнице между двумя этими понятиями, но это не так уж и важно. Просто будьте уверены в том, что нашли то, о чем стоит заботиться. В идеале стоит остановиться на 3-6 целях или критичных факторах. Если будет больше, то отчеты будут слишком длинными и слишком размытыми.
Мы делаем для пользователей простым и удобных взаимодействие с нами, когда они обращаются для помощи, когда задают вопросы или когда мы предоставляем им информации о ходе работ
все взаимодействия пользователи могут инициировать по телефону или через портал самообслуживания (Да/Нет)
процент телефонных звонков принятых в течение 30 секунд
процент непринятых телефонных звонков
результаты ответа на вопрос: “Как проще всего связаться с IT, когда они нужны?” в ежегодном опросе удовлетворенности заказчиков
Мы хорошо общаемся с нашими пользователями, поддерживаем их достаточным объемом информации и соответствуем их ожиданиям
процент инцидентов, по которым пользователи запрашивали текущее состояние решения
процент инцидентов, возвращенных пользователем в работу после того, как техподдержка их закрыла
Мы решаем пользовательские инциденты быстро и эффективно
процент инцидентов, решенных не хуже утвержденного уровня обслуживания (SLA)
процент инцидентов, решенных пользователями самостоятельно используя портал самообслуживания
процент инцидентов, решенных в течение первого контакта с пользователем.
Мы выполняем запросы на обслуживание быстро и эффективно
процент запросов на обслуживание, выполненных не хуже утвержденного уровня обслуживания (SLA)
процент запросов на обслуживание, выполненных без ручных операций со стороны ИТ сотрудников
Мы достигаем высокого уровня удовлетворенности заказчика
процент пользователей поставивших оценки 4 или 5 в опросе удовлетворенности результатом решения инцидента
увеличение удовлетворенности заказчиков работой техподдержки в ежегодном опросе удовлетворенности
Эти примеры ключевых показателей основаны на целях и критичных факторах для техподдержки. Их не стоит путать с более детальными ключевыми показателями, которые могут использоваться для измерения процесса Управления инцидентами (incident management process).Вам может также потребоваться несколько дополнительных внутренних ключевых показателей для измерения на сколько рационально техподдержка использует свои ресурсы, но это вряд ли будет интересно заказчикам (внутренним заказчикам это будет очень даже интересно).
Заключение
Не удастся определить ключевые показатели для техподдержки пока не утверждено, что пробуете получить в результате. А для этого нужно встретиться с заказчиками и договориться зачем нужна техподдержка и на что от нее рассчитывать заказчику (определить “видение”). Это позволит определить цели и критичные факторы их достижения. А далее задать небольшое количество ключевых показателей (индикаторов), которые помогут показывать текущие результаты.
Когда вы отчитываетесь перед заказчиками, должно идти обсуждение целей и их критических факторов. Можно использовать ключевые показатели (индикаторы) для иллюстраций трендов и подтверждения гипотез, но при этом быть уверенным, что с заказчиками обсуждается достижение высокоуровневых требований и что наиболее важно, как они воспринимают ваши результаты (соответствие результатов ожиданиям).
