Портал №1 по управлению цифровыми
и информационными технологиями

Измерение процессов. Incident Management. Часть 3

Как известно, назначение процесса управления инцидентами – минимизировать негативное влияние на бизнес посредством скорейшего устранения инцидентов. Измерение результативности процесса управления инцидентами чаще всего выполняется двумя метриками: доля своевременно решенных инцидентов и среднее время устранения инцидентов (в разбивке по уровню влияния или приоритету – в зависимости от того, как определяется срок устранения инцидента). Но, строго говоря, ни одна из этих метрик не отвечает на вопрос, насколько удается устранять инциденты скорейшим образом (то есть не просто быстро, а максимально быстро). Можно ли каким-то образом ближе подобраться к ответу на этот вопрос? Попробуем.

ITIL описывает очень полезный и хорошо применимый на практике аналитический инструмент процесса управления доступностью – Expanded Incident Lifecycle. Он, в частности, позволяет проанализировать, какие стадии выявления и обработки инцидента могут быть оптимизированы с целью сокращения времени решения (а значит повышения доступности ИТ-услуг). Однако к моему сожалению, он недостаточно явно обозначает одну из важнейших стадий обработки инцидента – реагирование на поступивший инцидент (насколько я понимаю, на схеме это где-то между стадиями Detect и Diagnose). Однажды я уже поднимал эту тему, в своей заметке «Управление проблемами и время решения инцидентов», но там мы не затрагивали вопрос измерения времени реакции. Вместе с тем мои оценки (развернутой статистики у меня пока нет) показывают, что в среднем время, которое инцидент проводит в очередях, ожидая, пока им займутся специалисты, как минимум не меньше собственно времени решения (и весьма вероятно даже превышает его). Сокращение времени реакции – один из наиболее очевидных способов сокращения общего времени решения инцидентовРаз так, давайте научимся его измерять.

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

 

 

где N – количество назначений инцидентов в заданную функциональную группу;

Ti – время решения i-го инцидента (с момента начала работы над ним);

Qi – время ожидания инцидента в очереди (с момента назначения до начала обработки).

Считаю важным отметить три момента:

  1. данная метрика нормирована в диапазоне [0; 1] и имеет целевую динамику на возрастание;
  2. расчет данной метрики лучше выполнять не для инцидента целиком, а для отдельных назначений инцидента в разные группы (поскольку один инцидента может быть последовательно назначен в несколько групп, и даже несколько раз в одну и ту же группу);
  3. практичнее всего анализировать значение этой метрики именно в разрезе по функциональным группам, чтобы выявить те группы, где время реакции требует сокращения (с последующим поиском шагов, которые такое сокращение могут обеспечить).

Приведенная формула проста для понимания, но не отражает один момент. Дело в том, что инциденты бывают разные – с бОльшим и меньшим влиянием на бизнес. И может быть так, что реакция на более значимые инциденты вполне приемлема, но большой поток инцидентов с малым уровнем влияния занижает среднее время реакции. Чтобы учесть разное влияние инцидентов, можно выбрать один из двух путей:

  1. выполнять расчет данной метрики в разбивке по уровням влияния / приоритетам;
  2. привести формулу к взвешенному среднему, используя в качестве веса Wi уровень влияния или приоритет инцидента:

 

 

Считайте на здоровье. И делитесь результатами – мне очень интересно набрать статистику, подтверждающую или опровергающую мои оценки.

Комментариев: 11

  • Stepan Khrulev

    Stepan Khrulev

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

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

  • Андрей

    В силу своего природного занудства буду цепляться за мелочи.:)

    Ti – время решения i-го инцидента – в большинстве случаев у нас этот параметр означает общее время от регистрации инцидента до его решения, включая перекуры в очередях. Так происходит из-за SLA. Пользователя не волнует наша внутренняя кухня и его не интересует где и как инцидент бродит. Но для нас  самих это параметр действительно важен, поскольку стояние в очередях первый кандидат на оптимизацию (сокращение времени). Заставить человека быстрее соображать (находить решение инцидента) достаточно проблематично. Не имея серьёзных познаний в области вышей матеметики мы эту проблему решаем влоб:). Для инцидентов вводится набор статусов – зарегистрирован, назначен(это собственно и есть стояние в очереди), принят в работу, выполненен, закрыт и т.д. Так что, мы просто с помощью несложных SQL заносов выбираем из системы общее время нахождения инцидента в каждом статусе. Этот подход также применяется и при подтверждении закрытия инцидента пользователем – если не отреагировал в заданное время, то автоматически считается что он согласен с закрытием и меняем статус на "закрыт". Но это про стояние в очередях. Что касается времени реакции, то у нас этим параметром принято считать время между моментом регистрации и моментом, когда инцидент назначен на конкретного исполнителя. Это период врмени, когда инцидент находится в области "безответственности", когда за него лично никто не отвечает (он назанчен на группу и руководитель группы должен вырать жертву). 

     

    • Ti – время решения i-го инцидента — в большинстве случаев у нас этот параметр означает общее время от регистрации инцидента до его решения, включая перекуры в очередях. Так происходит из-за SLA.

      Разумеется. Но наверно в вашей системе автоматизации можно посчитать и другие времена, не ущемляя интересов пользователей? Более того, в формуле выше Ti – это время обработки инцидента определенной группой, а не полное время решения. То есть если вам назначиили инцидент, вы на него 20 минут не реагировали, а потом за 5 минут обработали, переназначив в другую группу, то метрика вашей группы будет равна 5 / (5 + 20) = 20%, независимо от общего времени решения. То есть из общего времени нахождения инцидента в области ответственности вашей группы 80% – потери.

      • Павел Солопов

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

        • Я уже писал, что так делать нельзя: http://www.realitsm.ru/2013/02/pickup_time_as_kpi/

          Это ведет не столько к большим трудозатратам, сколько к увеличению среднего времени обработки.

          • Павел Солопов

            Что так делать нельзя это и так понятно. 🙂
            Другое дело как это контролировать и какие выводы из этого делать.

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

            Если же какая-то "третья сила" анализировать будет, то вопрос как корректно воспринимать специфику разных подразделений… И т.д.

  • Андрей

    Вопрос не в ущемлении интересов пользователей, а в том, что с ними тяжело подписывать SLA, в которм есть параметры, не имеющие к пользователям прямого отношения. Пользователям для выполнения своих бизнес задач важно минимизирвоать время между сбоем и восстановлением услуги. Сколько инцидент был в очереди и сколько он реально обрабатывался – это не их забота. Это важно для менеджера процесса. По поводу 80% потерь. Данное утверждение спарведливо в случае, когда у вас есть отдельно выделенная служба, которая занимается ТОЛЬКО инцидентами. Так называемая "ававрийная служба". Но я такого у нас в ИТ почти не встречал. Обычно специалисты заняты в разных процессах и 80% в очереди не всегда означает что они бездельники. Есть еще одно замечание по поводу данной метрики. То, что её значение стремится к нулю, вовсе не означает что у вас всё хорошо. Это скорее всего будет означать, что у вас есть излишек ресурсов, позволяющий моментально брать инциденты в работу независимо от их количества и частоты возникновения (что не возможно спрогнозировать в силу случаного характера возникновения инцидентов.). И это плохо не только по причине излишних прямых затрат на "лишних" сотрудников. Есть еще один момент – если человек не занят делом, он начинает маяться "дурью" (дедовщина в армии на пример) и последствия могут оказаться весьма печальными. В свое время был даже вид угрозы – не занятый делом администратор UNIX:).

    Всё выше изложенное – моё чисто субъективное мнение:) (Опять-таки, дурь несусветная- мнение не может быть не субьективным):)

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

      Андрей, я с Вами согласен, но я и не предлагал включать эту метрику в SLA. Это внутрення метрика, которая может служить источником информации для совершенствования процесса. Как Вы совершенно верно заметили, "Это важно для менеджера процесса".

      По поводу 80% потерь. Данное утверждение спарведливо в случае, когда у вас есть отдельно выделенная служба, которая занимается ТОЛЬКО инцидентами.

      Потерь не с точки зрения безделья сотрудников, а с точки зрения оперативности обработки инцидентов – именно об этом данная метрика. Обратите внимание на рекомендацию 3 в тексте поста: "практичнее всего анализировать значение этой метрики именно в разрезе по функциональным группам, чтобы выявить те группы, где время реакции требует сокращения (с последующим поиском шагов, которые такое сокращение могут обеспечить)." Вот на этапе поиска шагов Вам, действительно, потребуется информация о загрузке ресурсов и о составе работ, в которые они вовлечены. Но эту информацию Вы, разумеется, будете брать не из значения приведенной метрики. Она – просто индикатор наличия резерва по сокращению времени устранения инцидентов за счет более оперативной реакции исполнителей.

  • Роман

    Подскажите, пожалуйста, что вы включаете во время реакции? Это время от назначения инцидента в группу до назначения конкретного исполнителя или до взятия инцидента в работу? 


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM