Измеряем Problem management

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

Решение — метрика, вычисляемая по формуле ниже.

N — количество новых проблем, зарегистрированных за период и не закрытых на момент его окончания (это необходимо для нормировки);
C — количество проблем, закрытых за период;
О — количество проблем, открытых по итогам периода.

Метрика нормирована, изменяется в диапазоне [0;1]. Есть два варианта методики постановки целевого значения: а) зафиксировать его, исходя из соотношения длительности отчетного периода к среднему времени решения проблем и б) зафиксировать его на заданном уровне (например, 80-90%), выбрав отчетный период равным или немного большим среднего времени решения проблемы.

"Физический" смысл данной метрики — коэффициент обновления. Метрика равна 1, если по итогам отчетного периода все оставшиеся открытые проблемы — новые (их не было в предыдущем периоде). Значит старые были решены, а новые зарегистрированы, то есть процесс работает.

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

В литературе не встречал, поэтому решил опубликовать.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Юрий Ерин

    Как было отмечено в конце статьи, «...данная метрика стимулирует менеджера процесса наладить выявление и регистрацию проблем.»

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

    0
    0
    1. Дмитрий Исайченко Автор

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

      0
      0
      1. Юрий Ерин

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

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

        Поэтому, применение этой метрики к менеджеру все-таки зависит от того как спроектирован процесс.

        0
        0
        1. Дмитрий Исайченко Автор

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

          Цитата 1: «задачами менеджера являлись контроль исполнения процедур процесса»

          Цитата 2: «Деятельность по выявлению и регистрации проблем в процессе тоже была»

          Следовательно, контроль эеятельности по выявлению проблем на менеджере процесса лежит. И тут возникает 2 вопроса:

          1. Кто же тогда организатор?

          2. За что конкретно отвечает менеджер процесса — за осуществление контроля или за выполнение процедур участниками?

          0
          0
        2. Дмитрий Исайченко Автор

          Добавлю. Я как-то все больше привык считать менеджера ответственным не только за контроль исполнения (человек, отвечающий только за это, обычно называется «аудитор»), а и за организацию исполнения процесса. Отсюда считаю, что данная метрика может считаться персональной метрикой менеджера процесса. Наверно в конкретных случаях и организация это может быть не так.

          0
          0
  2. Анатолий Павлюченко

    Попытался подставить цифры «из жизни». При низком количестве закрытых проблем за период можно отбросить этот параметр как несущественный. Играет роль только соотношение новых и не закрытых к количеству открытых. Почти всегда будут периоды, когда метрика К будет больше единицы и иногда, когда меньше. У меня так получилось в большинсве случаем, когда я пытался вспомнить реальные показатели. Что это мне даст в таком случае? Как я смогу пользоваться этой метрикой?

    0
    0
    1. Дмитрий Исайченко Автор

      1. K не может быть больше единицы. Никогда. Читайте внимательно описание операнда N.

      2. «соотношение новых и не закрытых к количеству открытых» — ненормированная метрика. При этом суть та же, что у метрики, предложенной мной.

      0
      0
      1. Анатолий Павлюченко

        1. Точно! А я прочитал как «новых и не закрытых». Видимо, стоит уточнить определение для N, чтобы вышло: «количество только новых проблем» и «без учёта проблем, открытых в прошлых периодах».

        2. Тогда ясно.

        0
        0
    2. Дмитрий Исайченко Автор

      «Что это мне даст в таком случае? Как я смогу пользоваться этой метрикой?»

      Эта метрика дает возможность быстро оценить, насколько «активен» процесс, учитвывая при этом не только решение проблем, но и их регистрацию, что стимулирует не «замалчивать» проблемы. Это важно. Так же важно, что с ней можно связать целевое значение и сделать ее одним из индикаторов (KPI) процесса, поскольку она быстро дает ответ на вопрос (1 число + светофор).

      Разумеется, она не позволит оценить «полезность» процесса, т.к. ничего не говорит о том, что это за проблемы — насколько они влияют на предоставление услуг. Это решается другими средствами (см. пост ниже).

      0
      0
  3. Кирилл Чистяков

    Такая метрика, поставленная в цели менеджера процесса будет стимулировать искать «легкие» проблемы, которые легко устранить. Она никак не отражает собственно цель процесса: снижение количества инцидентов.

    На мой взгляд может использоваться только как дополнительная, чтобы оценить «поток» проблем.

    0
    0
    1. Дмитрий Исайченко Автор

      «Такая метрика, поставленная в цели менеджера процесса будет стимулировать искать «легкие» проблемы, которые легко устранить»

      Так и есть. Поэтому она не может быть единственной. Но мерять сложность проблем метриками по-моему вообще непродуктивно. Как практика, например, используется такой вариант: менеджер процесса, отчитываясь за отчетный период готовит сводку по значимым проблемам, решенным за период. Тогда видно не только «42», но и что за польза от процесса для компании.

      Тем не менее, представленная метрика дает понять «жив» процесс или нет.

      0
      0
      1. Юрий Ерин

        «Тем не менее, представленная метрика дает понять «жив» процесс или нет.»

        В общем, да. Скорее, для внешних по отношению к ИТ организации лиц, например, аудиторов.

        На практике оценка «жив процесс или нет» производится по результатам. Например, «Что сделал процесс (владелец, менеджер) для предотвращения повторения аварий, произошедших два раза за последний месяц?», «Почему не было ничего предпринято для того чтобы предотвратить вчерашний сбой, притом что мониторинг начал предупреждать о его возможном возникновении месяц назад?»

        0
        0
          1. Юрий Ерин

            Похоже. Но эти примеры я привел потому что оценка «жив процесс или нет» важна, но может производиться по-разному.

            Метрика полезная (позволяет быстро, на высоком уровне оценить «работает/не работает»), но не самая важная (не дает понимания о результатах работы).

            0
            0
      2. Роман Журавлёв

        ...и «жив» не обязательно значит «полезен». здесь важное слово — _процесс_. Метрика помогает контролировать наличие и стабильность потока работ. Полезность же, описанная ниже, может достигаться и отдельными несистемными подвигами.

        То есть высокие значения этой метрики могут способствовать оценки зрелости процесса (1 или все-таки выше?). 🙂

        0
        0
  4. Роман Журавлёв

    Собственно, такая метрика, наверное, уместна в любой деятельности, где задача — «активно выявлять и обрабатывать», а не «пассивно принимать и обрабатывать». Тут же вспоминается, что управление проблемами — лишь специфическая форма управления рисками. то есть метрика работает для управления рисками, и как частный случай — для PRB.

    верно?

    0
    0
    1. Дмитрий Исайченко Автор

      Про более общее применение — согласен, думал об этом. Но конкретно про управление рисками — сомневаюсь, т.к. сомневаюсь, что там уместно понятие «среднее время устранения риска». Соответственно, данная метрика будет или очень усредненной (например, за год) или будет стремиться к 0. И то, и другое убивает мотивационный эффект, поэтому пользы от метрики не будет.

      0
      0
      1. Александр Жилинский

        Потому что единственная цель процесса, которая преследуется на текущий момент — исключительно запуск процесса (в оговоренном формате, с оговоренной сложностью и с оговоренными объемами), а эта метрика именно «работоспособности».

        0
        0
  5. Алексей

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

    На простом примере, что я делаю не так:

    С предыдущего периода осталось не решенными 3 проблемы, которые были закрыты в текущем периоде.

    В текущем зарегистрировали 5 и 3 из них были решены. 

    По формуле   К = (2+6)/(5+6)= ну точно не единица.

    0
    0
    1. Степан Хрулёв

      Алексей, все дело в том, что параметр О означает количество проблем, оставшихся открытыми в конце периода, а не количество проблем, которые были зарегистрированы за данный период.

      К принимает значение 1, если О = N, т.е. если количество открытых проблем в конце периода совпадает с количеством проблем, зарегистрированных за период и не закрытых к его окончанию.

      0
      0
  6. Алексей

    Спасибо за коммент. Разобрался с формулой. А накидайте на почту может или в комментах ссылок по вариантам KPIs для проблема. Буду благодарен. У нас просто процесс как бы описан как бы есть, но реально можно сказать работает только на бумаге. Мотивации нет у людей что то делать по процессу. 

    0
    0
  7. Даниил

    Дмитрий, после прочтения обоих постов по этой формуле и комментов к ним, так и не смог понять логику.

    Уточните, пожалуйста, буквы (N O C) к каждой из проблем по этой визуализации:

    0
    0

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ОКТ
23