Csf

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

Кто те заинтересованные лица, кому вы будете предоставлять отчеты? В описываемом случае мы хотели измерять последствия процесса улучшения, который планировался. Отчеты использовались менеджером процесса Управления изменениями (change manager), операционным менеджером (IT operations manager), офисом управления проектами и менеджерами процесса Управления уровнем обслуживанием (service level managers).

Мы поговорили с заинтересованными лицами, чтобы понять, что для них важно, и определили четыре критичных фактора успешности (critical success factors, CSFs) для процесса Управления изменениями (change management):

1. Защита бизнеса от негативного влияния последствий изменений

2. Поддержание скорости изменений, необходимой бизнесу

3. Предоставление знаний и информации о новых и изменяемых услугах, требуемых ИТ сотрудникам и бизнес персоналу

4. Рациональное использование ИТ ресурсов

Ваши факторы успешности (CSFs) могут значительно отличаться от озвученных, но вы должны быть готовы покащать их список вашим заинтересованным лицам. Еще один неплохой вариант, способный помочь найти ваши факторы успешности (CSFs), - примеры из книги ITIL Service Transition (но их тоже не стоит бездумно копировать).

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

Следующий шаг - определить не более 3 ключевых показателей результативности (KPIs), которые могут помочь понять достигнуты ли все критические факторы успешности (CSFs). Ключевые показатели (KPIs) однозначно не доказывают, что фактор успешности (CSF) достигнут, но помогают продемонстрировать, как хорошо выполнеятся то, что направлено на достижение фактора успешности (CSF). Вполне допустимо иметь один и тот же ключевой показатель (KPIs) в нескольких факторах успешности (CSFs), но важно, чтобы показателей не было много.

Пока мы обсуждали ключевые показатели (KPIs) для процесса Управления изменениями (change management) осознали, что необходимо улучшить качество данных об изменениях. Ранее каждое изменение помечалось, как успешное, и сотавалось таким до тех пор, пока его не возвращали на доработку, но это не давало нам информации достаточной для внедрения факторов успешности (CSFs). Мы решили оценивать каждое изменение на основе признаков:

• Было ли изменение полностью реализовано без необходимости возврата на доработку?

• Было ли изменение реализовано в заявленные при планировании время и ресурсы?

• Вызвало ли изменение инциденты?

• Обеспечило ли изменение результаты, на которые рассчитывал заказчик?

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

И теперь мы смогли определить ключевые показатели (KPIs), поддерживающие наши факторы успешности (CSFs)

CSF1 - Защита бизнеса от негативного влияния последствий изменений

• Уменьшать количество и долю изменений, которые вызывают инциденты

• Уменьшать общее влияние на бизнес от инцидентов, вызванных изменениями

CSF2 - Поддержание скорости изменений, необходимой бизнесу

• увеличивать число и долю изменений, которые были реализованы за плановое время и с привлечением планового объема ресурсов

• увеличивать число и долю изменений, которые обеспечили ожидаемый заказчиком результат

• увеличение уровня удовлетворенности от процесса Управления изменениями (change management) у проектного офиса и конечных заказчиков

CSF3 - Предоставление знаний и информации о новых и изменяемых услугах, требуемых ИТ и бизнес персоналу

• увеличение доли изменений, по которым были предоставлены материалы в базе знаний для техподдержки (service desk)

• увеличение уровня удовлетворенности от процесса Управления изменениями (change management) у ИТ персонала и конечных заказчиков (я бы сюда поставил пользователей, но автору виднее)

CSF4 - Рациональное использование ИТ ресурсов

• увеличение числа и доли изменений, которые были реализованы за плановое время и с привлечением планового объема ресурсов

• уменьшение числа и доли срочных и аварийных изменений

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

А когда вы последний раз пересматривали ключевые показатели (KPIs), используемые в процессе управления изменениями (change management)?
Почему бы не пересмотреть показатели и отчеты по ним, чтобы сделать их более полезными для вас и ваших стейкхолдеров?

Многие подбирают ключевые показатели (KPIs) для своих процессов Управления ИТ услугами по книгам (таких как ITIL Service Operation) или копируя метрики, используемые в других компаниях. Это редко приводит к хорошим результатам, потому что дословно KPIs - это дословно Показатели Результативности Ключевых задач, которыми вы занимаетесь. Хуже только ITSM процессы с огромным количеством одинаково названных показателей, которые измеряются, по ним пишутся отчеты, но результаты этого никто не использует ни для изменения деятельности в рамках процессах, ни для улучшения бизнес результатов.

Ранее я уже писал заметку "Как определять метрики для процесса Управления изменениями" (перевод, оригинал) , в которой я описывал, как можно создать ключевые показатели (KPIs), которые поддерживают именно ваши цели. Читатели (оригинала) после прочтения просили привести примеры, как выделять ключевые показатели (KPIs) для остальных процессов управления ИТ-услугами. В результате я решил написать эту статью для показателей процесса Управления проблемами (problem management), потому что в большинстве компаний, где я работал, у этого процесса были очень куцые показатели.

Напоминаю, что не стоит бездумно копировать приводимые здесь результаты процесса (outcomes), его критичные факторы успешности (CSFs) и ключевые показатели (KPIs). Содержание статьи стоит использовать только для понимания подхода и методологии, которые мною используются. И задуматься о том, что важно именно для вас, выделить метрики, для измерения задачи, за которые вы отвечаете.

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

• уменьшение количества возникающих инцидентов

• уменьшение влияния на бизнес от инцидентов, которые не смогли предотвратить

Мы можем просто измерять количество инцидентов и их общее влияние на бизнес. Это точно будет полезно знать, но я не уверен, что они смогут показывать, как хорошо работает именно процесс Управления проблемами, т.к. слишком много факторов на него влияет. Я немного разбавлю их и предложу несколько критических факторов успешности (CSFs), которые могут поспособствовать получению результатов:

• определение проблем, которые являются причиной множественных инцидентов

• создавать среду, которая снижает влияние от инцидентов

• инициирование изменений, которые уменьшают количество инцидентов

Стоит сказать, почему я не упомянул поиск корневых причин проблем (root cause analysis, RCA). Я видел много людей в управлении проблемами, кто думал только о поиске корневых причинах, но это не давало им особого результата, потому что RCA - это не более чем одна из техник, используемых в Управлении проблемами. Худшие ключевые показатели, которые можно придумать, - это среднее время обнаружения корневой причины, доля проблем, у которых ключевая причина была выявлена не хуже 3 дней и т.п. Использование таких показателей провоцирует участников Управления проблемами на поведение, которое мне бы не хотелось получить. Это равносильно заявлению, что в сложной многофакторной ситуации нужно искать единственную корневую причину. Для меня более правильный способ - это проведение постоянного анализа, даже если в его результате удастся идентифицировать только одну значимую причину.

Одни из моих заказчиков имеет процесс приоритезации проблем, который определяется частотой и влиянием на бизнес проблемы, включая смягчение последствий производимое рабочим окружением. Они также используют показатель среднее время уменьшение влияние проблемы до 3-го приоритета. Это уменьшение может быть достигнуто за счет решения проблемы или внедрением правильного рабочего окружения. Этим показателем они измеряют как Управления проблемами уменьшает боль бизнеса. Я не буду советовать всем это ключевой показатель, потому что для его использования требуется применять довольно сложный подход к приоритезации проблем, который не все компании смогут реализовать, но если у вас получится измерять, тоопределенно можете задуматься о таком показателе.

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

CSF1 - определение проблем, которые являются причиной множественных инцидентов

• увеличение доли инцидентов ассоциированных с записями о проблемах или известными ошибками

• отчет о топ 5 проблем создается каждый месяц

CSF2 - создавать среду, которая снижает влияние от инцидентов

• увеличение доли инцидентов, для которых в базе знаний есть статьи с решениями

• увеличение доли инцидентов решенных пользователями с использованием инструментов самостоятельного решения

• уменьшение влияния инцидентов, ассоциированных с топ 5 проблем прошлого месяца

CSF3 - инициирование изменений, которые уменьшают количество инцидентов

• уменьшение количества инцидентов, ассоциированных с топ 5 проблем прошлого месяца

• уменьшение беклога незавершенных проблем

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

На сколько метрики, измеряемые в вашем процессе Управления проблемами, соответствуют потребностям ваших заказчиков?
Когда вы пересматривали в вашем процессе Управления проблемами ключевые показатели (KPIs) и связанные с ними факторы достижения успешности (CSFs) и цели?

PS Если тема интересна, можно познакомиться со статьями Стюарта Рейнса:

Как определять метрики для процесса Управления (перевод, оригинал)

Осторожно. Как использовать метрики процессов без вреда для здоровья процессов (перевод, оригинал)

Я уже писал о там, как можно опеределить метрики (metrics) и ключевые показатели (KPIs) для некоторых процессов управления ИТ услугами (IT service management). В статье Как определить метрики для процесса Управления изменениями (перевод, оригинал) я рассуждал о важности идентификации заинтересованных лиц и определения факторов достижения успеха (CSFs), и дальнейшего использования этого при поиске ключевых показателей (KPIs) для измерений и отчетности. В статье Как определить метрики для процесса Управления проблемами (перевод, оригинал) продолжил тему и показал, как ключевые показатели (KPIs), предлагаемые в лучших практиках (например, ITIL), могут не подходить под реальные ситуации.

В ITIL (книга ITIL Practitioner)предлагается любопытная методика определения метрик в виде последовательного декомпозита Факторов достижения успеха процесса (CSFs) - Ключевые показатели процесса (KPIs) - Метрики (Metrics). Если очень кратко, то

• CSFs - это качественное описание результатов успешной работы процесса

• KPIs - количественное описание результатов успешной работы процесса

• метрики - что именно измеряем для расчета KPIs

В ответ на эти статьи я получил несколько запросов продолжить цикл и особенно часто встречался запрос на описание метрики для процесса Управления инцидентами (Incident Management). Ниже, что я думаю о том, как можно определять метрики для Управления инцидентами (Incident Management).

Первый вопрос, на который нужно ответить: Что такое управление инцидентами? Какая у него цель?. Ответы могут не совпадать, но большинство компаний получат что-то похожее на:

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

• Мы решаем инциденты в порядке соответствующем их влиянию и заявленной срочности

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

• Заказчики и пользователи удовлетворены тем, как мы устраняем их инциденты

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

• Мы рационально используем наши ресурсы в процессе Управления инцидентами (Incident Management)

В идеале наши ключевые показатели должны помогать понимать достигнуты ли эти цели и показывают тренды, для определения, что требуется улучшить. Теперь давайте подумаем о том, что можно для этого измерять. Пожалуйста, не забывайте, что это все только пример, показывающий как можно думать об Управлении инцидентами (Incident Management).

Часть ключевых показателей (KPIs) могут идеально подойти одним компаниям и совершенно не подойти другим. Например, некоторые измеряют решение при первом контакте (First Call Resolution, FCR), т.е. какая доля обращений была решена в течение звонка на техподдержку (service desk) с обращением о наличии инцидента. Для многих компаний это отличный способ измерения того, что они быстро решают инциденты и рационально используют ресурсы, но если вы развиваете инструменты самообслуживания, то можете обнаружить, что показатель решения при первом контакте ухудшается, при том что качество услуг повысилось.

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

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

• Мы решаем инциденты так быстро, чтобы их последствия значительно не влияли на наших заказчиков

  • процент инцидентов 1-го приоритета решенных не хуже требования в Соглашении об уровне обслуживания (SLA)

  • процент инцидентов 2-го приоритета решенных не хуже требования в Соглашении об уровне обслуживания (SLA)

  • процент инцидентов 3-го приоритета решенных не хуже требования в Соглашении об уровне обслуживания (SLA)

• Мы решаем инциденты в порядке соответствующем их влиянию и заявленной срочности

  • количество инцидентов, приоритет которых был изменен после регистрации обращения

  • количество жалоб заказчиков или обращений для поднятия приоритета инцидента

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

  • процент инцидентов, в которых заказчик запрашивал информацию о состоянии решения инцидента

• Заказчики и пользователя удовлеитворены тем, как мы устраняем их инциденты

  • процент пользователей давших оценку 4 или 5 в опросе удовлетворенности решением инцидента

  • изменения удовлетворенности заказчиков работой процесса Управления инцидентами (Incident Management) по итогам ежегодных опросов

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

  • число проблем зафиксированных техподдержкой (service desk)

  • число проблем зафиксированных аналитиком инцидентов

• Мы рационально используем наши ресурсы в процессе Управления инцидентами (Incident Management)

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

  • процент инцидентов решенных на портале самообслуживания

  • средняя цена решения инцидентов (в разрезе приоритетов)

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

После прочтения ответьте для себя на пару вопросов:

• На чем основаны ваши текущие ключевые показатели (KPIs) процесса Управления инцидентами (Incident Management)?

• Они помогают вам понять как успешно вы обслуживаете ваших заказчиков, или большинство из них направлено на оценку ваших внутренних дел?

• Почему бы на пересмотреть их и не начать измерять и оценивать то, что действительно важно для вас?

На этом все надеюсь статья была интересна

У меня есть серия заметок о метриках (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).Вам может также потребоваться несколько дополнительных внутренних ключевых показателей для измерения на сколько рационально техподдержка использует свои ресурсы, но это вряд ли будет интересно заказчикам (внутренним заказчикам это будет очень даже интересно).

Заключение

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

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