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

Своевременность реакции на назначение как KPI?

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

Инциденты могут решаться долго не потому, что они очень сложные, а потому, что они долго лежат в очереди. Мы даже как-то обсуждали это не так давно. Время реакции на назначение важно измерять, потому что это одна из потенциальных причин задержек в обработке. Но чтобы эта метрика была показательной, инцидент в работу надо брать именно тогда, когда действительно приступаешь к его обработке. В то же время, если своевременность обработки является KPI для руководителей групп, они могут привыкнуть сами и приучить подчиненных брать в работу новые инциденты заранее. Пришел новый инцидент, кто-то берет его в работу, неважно, когда он к нему приступит, там разберемся. Зато время реакции красивое. Это маскирует проблему, а значит мешает её решать. Более того, можно показать, что такое поведение может привести к повышению среднего времени решения инцидентов (но об этом не сейчас). Поэтому для стабильного процесса своевременность реакции на назначение в качестве KPI для руководителей групп лучше не использовать.

С учетом сказанного попробуем сформировать KPI для руководителей функциональных групп, задействованных в поддержке. Основная метрика, естественно, своевременность решения (тут также возможны варианты, смотри здесь). В качестве tension-партнера можно использовать следующие варианты:

  • своевременность выполнения плановых работ. Это на самом деле здравая мысль – руководитель должен обеспечить баланс между тушением пожаров и выполнение плановых работ. Так появляется идея деления на 2-ю и 3-ю линии в пределах одного структурного подразделения (выделение фронта и бэка), так появляется стимул для выявления и устранения проблем;
  • долю инцидентов, зарегистрированных самостоятельно или по данным систем мониторинга, не дожидаясь обращений пользователей (если Вы хотите организовать своевременную регистрацию и действительно полезный мониторинг). И так далее.

Ну а скомбинировать эти метрики в итоговый KPI достаточно просто. Более того, практика показывает, что даже корень здесь лишний – обычное произведение прекрасно решает задачу 🙂

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

  • Юрий Алдунин

    Дмитрий, но ведь большую часть своей жизни инцидент, как правило проводит в очереди (среднее время от регистрации до выполнения в разы больше среднего же времени непосредственной работы над ним). Т.е. если мы говорим: “берём в работу только тогода, когда реально начинаем работать”, то имеем ситуацию, в которой допустимое время реакции приближается к плановому времени решения. С другой стороны, если реагировать заранее, можно сразу возвращать назад ошибочно направленные в группу инциденты, инициировать работы в смежных группах/линиях (если это необходимо).
    Больше напрягает первый из озвученных моментов (время реакции стремится к плановому времени решения). Лично видел ситуации когда работник имеет некий норматив и он начинает им руководствоваться: если сказано что “упало, но в течении 15 минут поднялось по данным мониторинга” – работник мужественно ждёт 15 минут и только если “не поднялось” реагирует на инцидент, так же за руку ловил людей которые выполняли работы нормально, но для руководства демонстрировали “100%-ную загрузку” стабильно отмечая выполнение за несколько минут до крайнего срока.

    • Юрий, а как KPI на время приема в работу может решить озвученные Вами проблемы? Если учесть, что “Пришел новый инцидент, кто-то берет его в работу, неважно, когда он к нему приступит, там разберемся. Зато время реакции красивое”. Вы же не уберете ожидание в очереди, Вы его просто скроете, не так?

      • Юрий Алдунин

        Как минимум это стимул прочитать, осознать и, возможно, выполнить требуемые действия раньше. Опять же, чтобы понять что готов прямо сейчас взять инцидент в работу, необходимо прочитать его, а раз сотрудник уже открыл инцидент и понял, что именно он может/должен его решать, почему бы сразу не отметить его как “свой”: во-первых, экономим время других сотрудников на чтение этого же инцидента, во-вторых, избавляем его от повторного поиска “своего” инцидента в общей очереди группы.
        Да, граница между ожиданием и работой размывается, но зато время реакции улучшается не только “на бумаге” но и в жизни (пусть и не так сильно).
        Опять же у нас, например, чтобы инцидент попал на третью линию, он должен пройти и через первую, и через вторую. Если промежуточные линии не будут оперативно реагировать, добраться до третьей линии не оказавшись просроченным, у инцидента не так и много шансов.

        • Юрий, так я же не писал, что это не надо измерять. Напротив: “Его обязательно надо измерять и контролировать…”. Но “…для стабильного процесса своевременность реакции на назначение в качестве KPI для руководителей групп лучше не использовать“.

          • Юрий Алдунин

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

    • «С другой стороны, если реагировать заранее, можно сразу возвращать назад ошибочно направленные в группу инциденты, инициировать работы в смежных группах/линиях (если это необходимо).»

      Вот это действительно важно. Но KPI на время реакции это вряд ли решится, а ответ можно искать где-то в этой области: http://www.realitsm.ru/2011/12/measuring-incident-management/. Во всяком случае, при применении таких метрик, у группы есть стимул не держать чужие инциденты у себя.

  • Pavel Solopov

    Как вариант, можно в автоматизированной системе сделать ограничение: только один инцидент в статусе “В работе”. Сначала закрой (отложи, переадресуй и т.д. один, а затем берись за другой).

    • Юрий Алдунин

      А как же ситуация, когда нужно дождаться пока отработает скрипт, применится политика и т.п? Ведь в это время можно взять следующий инцидент (опять таки не получим чистого времени выполнения, но эффективность выше, а это важнее). Переводить в данном случае в ожидание тоже не правильно: зачастую, когда инцидент переводится в ожидаение – пользователю отправляется соответствующее уведомление. Вводить новый статус (что-то типа “Ожидание без уведомления”) – усложнять жизнь специалистам.
      Да и вопрос Дмитрия был о KPI для руководителя группы.

  • Pavel Solopov

    Не стоит всё воспринимать дословно. Я не рекомендую именно статус “Ожидание” и всё тут. Добавьте другой статус, как его назвать и делать ли оповещение вопрос для размышления. Назовите его “Технологическое выполнение”, например.
    Усложнит ли это жизнь специалистам это вопрос к автоматизированной системе. Если придётся сделать 5 приседаний, одно отжимание и три оборота вокруг оси, чтобы сменить статус, то несомненно усложнит. Если сделать как-то более органично, чтобы, например, при приёме нового инцидента в работу предлагалось выбрать статус для предыдущего, то не особо.

    Если ввести такое ограничение, это сделает показатель времени ожидания более объективным и позволит использовать в качестве KPI.

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

  • Анатолий

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

    Параметр, при котором учитывается интервал назначения инцидента на ответственного не учитываем. Один из важных значений для учета  – нарушение сроков решения инцидента. Учитываем всё, включая сложные и простые, ведь 1 сложный может равняться 100 простым и статистика по кол-ву решенных практически не учитывается, если только при прочих равных.

     


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM