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

Измеряем Incident Management. Часть 2

Продолжаем публикацию материалов по измерению процесса управления инцидентами. Чтобы предотвратить «футбол» (быстрое, бездумное перекидывание инцидентов в другие группы) плюс к метрике своевременности (которая бурно обсуждалась в заметке «Измеряем Incident management») нужна вторая метрика – результативности. О ней и поговорим в этой заметке.

Традиционно одна из метрик управления инцидентами была посвящена контролю возвратов на доработку и рассчитывалась по формуле «доля инцидентов, возвращённых на доработку, от общего количества инцидентов, решённых за период». В чём недостатки такой метрики? Их (как минимум) два:

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

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

Тогда по каждой из групп метрику результативности можно представить в виде:

где  – KPI группы по результативности обработки инцидентов;

N – общее количество инцидентов, решённых за период (с участием данной группы);

M – количество инцидентов, потребовавших повторной обработки силами данной группы.

Как обычно, метрика нормирована в диапазоне [0; 1]: 1 – отлично, 0 – наихудший результат.

ВАЖНО. Данная метрика применима только при соблюдении следующих условий:

  • процесс должен использовать переназначение инцидентов только для функциональной эскалации. В моей практике встречались и другие случаи. Вот некоторые примеры:
    • возврат на Service Desk при передаче решения пользователям;
    • возврат группе, отвечающей за прикладное ПО, после устранения инцидента в базовой инфраструктуре;
    • последовательное переназначение инцидента (или обращения пользователя), требующего выполнения работ силами нескольких групп;
  • при возврате инцидента на доработку (отказ пользователя) он должен изначально попадать на обработку той же группе, которая сообщила о решении (встречал случаи возврата на Service Desk, что лично мне кажется не очень логичным).

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

P.S. В следующей заметке я вернусь к тому, как из нескольких метрик (в нашем примере – метрики своевременности и результативности) можно сделать один KPI. И если Вы сразу готовы предложить среднее арифметическое, не спешите 😉

«VAP: Построение системы KPI для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

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

  • Павел

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

    Не совсем корректное допущение. Всё зависит от технологической цепочки. Например, вначале надо остановить сервер, а после каких-то с ним манипуляций запустить вновь.

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

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

    • “Не совсем корректное допущение. Всё зависит от технологической цепочки. Например, вначале надо остановить сервер, а после каких-то с ним манипуляций запустить вновь.”

      Павел, я же специально добавил слово “ВАЖНО” и описал условия применимости данной метрики. Это не отвечает на Ваш вопрос?

      • Pavel Solopov

        Я обратил внимание, на указанные вами ограничения, Дмитрий. Но, во- первых у вас это сформулировано несколько иначе. А, во-вторых, я вопроса не задаю, я утверждаю. 🙂
        Применение данной метрики возможно только в том случае, если мы категорически отрицаем возможность того, что технология решения инцидентов может потребовать участия в нём одной и той же группы, на разных этапах.
        Но чтобы утверждать такое, необходимо проработать технологические карты инцидентов большинства типов.
        А если мы обладаем технологическими картами, то более эффективно будет контролировать соблюдение этих карт. И метрика утрачивает смысл.
        Вот как-то так.
        🙂

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

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

          • Павел

            Я видимо не совсем корректно воспринимаю терминологию (плохо, когда что-то не знаешь, а потом ещё и забудешь).
            Если не сложно, уточните что вы понимаете под функциональной эскалацией?
            В частности на примере, который я приводил. При такой схеме:
            Группа 1 проводит поиск проблемы. Понимает, что для её решения надо остановить сервер. Сервре остановить может группа 2, после остановки сервера группа 1 проводит какие-то манипуляции, после чего группа 2 должна сервер запустить.
            Передача от группы к группе будет функциональная эскалация или нет?

            • “уточните что вы понимаете под функциональной эскалацией?”

              Как обычно. Привлечение более высокой технической компетенции, если нашей не хватает.

              “Группа 1 проводит поиск проблемы. Понимает, что для её решения надо остановить сервер. Сервре остановить может группа 2, после остановки сервера группа 1 проводит какие-то манипуляции, после чего группа 2 должна сервер запустить.”

              Павел, признайтесь Вы что на практике реализуете такую обработку переназначением инцидента? Если “да”, нескромный вопрос: “Зачем”? 🙂

              • Павел

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

                • “Я бы это реализовывал через задания, но Вы же сами говорите, что это тоже не правильно.”

                  Если это а) инцидент и б) вопрос одного сервера, то конечно простым телефонным звонком, без всяких заданий и переназначений инцидентов.

                  Про функциональную ответственность. Не хочу уходить в терминологический спор, но для меня здесь всё просто. Функциональная эскалация означает передачу ответственности за решение инцидента. Если я отвечаю за решение, но мне нужно, чтобы смежники помогли мне, отключив сервер, я не считаю это функциональной эскалацией. ITIL (по крайней мере в глоссарии, опубликованном на сайте itSMF) – тоже.

                  • Павел

                    Да ни каких споров. 🙂
                    Я просто для себя определяюсь, чтобы вашу мысль правильно понимать.

                  • Павел

                    Звоним в группу 2, просим выключить сервак. Они говорят: “сейчас, сейчас”, выключают через пару часов. В результате чего инцидент просрочен, группа 1 имеет минус в своём отчёте, а группа 2, как бы и не при делах.

                    Если мы часть активностей проводим в теневом формате, то нужна ли тогда метрика 1, которую мы обсуждали раньше?

                    • Переназначаем инцидент в другую группу, получаем паузу на время реакции. После перезагрузки сервера переназначаем инцидент обратно, получаем вторую паузу на время реакции. Делаем работу, переназначаем инцидент обратно, получаем третью паузу на время реакции. Включаем сервер, очевидно, отчитаться о завершении инцидента не можем, ибо к инциденту отношения имеем мало – только сервер перегружаем. Поэтому назначаем инцидент обратно, получаем четвёртую паузу на время реакции. Даже если каждое время реакции составляет 15 минут (а это в среднем неплохой показатель) имеем 1 час потерянного времени. В итоге инцидент просрочен, с кого спрашивать непонятно (все работали). Нужна ли тогда метрика, которую мы обсуждали раньше? 🙂

                      Я не против заданий – пусть будут (контроль работ, учёт трудозатрат и так далее). Но реальное взаимодействие в Вашем примере будет телефонно-очным. Иначе никакие технологические цепочки не помогут.

                  • Павел

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

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

                    • Павел, скажите, пжл, а Вам нравится Борис Гребенщиков? Извините, что в сторону, но я без подначки – мне правда интересно знать. Если ответите, объясню, почему спросил 🙂

                  • Pavel Solopov

                    Ну опять же ветка закончилась. Не моего формата у вас форум. 🙂
                    Не знаю что вам даже про БГ сказать. Он мне и не нравится и не не нравится. Я практически музыкой не интересуюсь. Если у вас есть бесплатные билеты на его концертЮ то схожу, а если предлагаете диск купить, то воздержусь. 🙂

                    • “Не знаю что вам даже про БГ сказать. Он мне и не нравится и не не нравится.”

                      Тогда я ошибся в своём предположении.

          • Павел

            При переназначении вводится отметка о том, связано ли это переназначение с недоработкой или нет.

            Как мне кажется, случай возврата из-за плохого качества и “футбол” не совсем одно и то же. Футболить могут не только две группы между собой, а по цепочке.
            Что же касается качества работы “смежников”, то я при обсуждении первой метрики уже предлагал (или хотел предложить) использовать практику оценки результата. Т.е. каждый, кому вы переназначили инцидент может поставить вам оценку. Такие оценки, как мне кажется, вполен могут заменить обе этих метрики.

            • “Такие оценки, как мне кажется, вполен могут заменить обе этих метрики.”

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

              • Павел

                Да… Думать, это практически непосильная ноша для ИТ-специалистов. 🙂
                Собственно можно сделать так:
                По умолчанию штрафной бал 0. А если вы считаете, что смежник вас подвёл, то можете прописать ему какие-то штрафные балы.
                Вы же сами говорили: “если Вы не можете сделать свою работу из-за смежников, которые не делают свою, у Вас хватит энергии один раз кликнуть мышкой”.

  • Сергей

    Дмитрий, Коллеги, добрый день.

    Наткнулся на Вашу статью – очень интересная. Заметил что вы используете KPI. Нужна Ваша помощь. Работаю над написанием диплома “ITSM, повышения уровня эффективности предоставления IT услуг”. Главное нужна в этой работе – НАУЧНАЯ НОВИЗНА! Посоветуйте идеи, например подобные KPI и как их рассчитать, и.т.д?

    Заранее, огромное спасибо!

    • Сергей, простите, что отвечу советом (сказывается советское прошлое): не гонитесь за количеством метрик, тем более в дипломе. Все метрики всё равно не придумаете, а нескольких примеров будет достаточно.
      Гораздо важнее для такого диплома, на мой взгляд, следующие вещи:
      1. Общая методика. Назначение, цели, задачи, процедуры, роли -> организация контроля и оценки -> планирование и измерение KPI -> завязка на систему стимулирования.
      2. Полнота системы метрик. Например, полный набор метрик для оценки какой-то должности, совмещающей несколько процессных ролей, или поставщика ИТ-услуг в целом.
      3. Рациональность и обоснованность метрик. Смотрите книжку по прикладной информационной экономике, её можно найти и скачать в интернете.
      4. Необходимость адаптации любых метрик под текущую задачу, процессные модели, возможности средств автоматизации. Бессмысленность копирования метрик.
      Наконец, повышение эффективности – гораздо более широкая тема, чем просто измерение. Здесь я бы очень посоветовал внимательно прочитать книжку SS. Акценты в повышении эффективности будут меняться в зависимости от того, с каким вы работаете клиентом и на каком рынке.

      • Pavel Solopov

        Это в Вас дмитрий говорит МФТИшное прошлое. Это может быть у вас в МФТИ для диплома важнее пункты с 1 по 4. А в большинстве ВУЗов важнее НАУЧНАЯ НОВИЗНА, т.е. придумать такую метрику, какой ни у кого ещё не было. А уж её обоснованность и рациональность, а тем более работоспособность дело десятое.
        🙂

        P.S. Насколько помню, раньше НАУЧНАЯ НОВИЗНА требовалась для кандидатских диссертаций, теперь уже и депломы новизной сверкать должны?
        Мы так скоро весь научный мир за пояс заткнём.


Добавить комментарий для Дмитрий ИсайченкоОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM