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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

Комментариев: 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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT