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

Измеряем Problem management

Опубликовано 1 декабря 2010
Рубрики: ITIL, Постоянное улучшение, Процессы, Управление проблемами
Комментарии

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

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

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

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

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

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

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

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

Также по теме:

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

  • Юрий Ерин

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

    • Дмитрий Исайченко

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

      • Юрий Ерин

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

        • Дмитрий Исайченко

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

          Цитата 1: “задачами менеджера являлись контроль исполнения процедур процесса”
          Цитата 2: “Деятельность по выявлению и регистрации проблем в процессе тоже была”

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

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

        • Дмитрий Исайченко

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

          • Юрий Ерин

            Я тоже так считаю.

  • Анатолий Павлюченко

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

    • Дмитрий Исайченко

      1. K не может быть больше единицы. Никогда. Читайте внимательно описание операнда N.
      2. “соотношение новых и не закрытых к количеству открытых” – ненормированная метрика. При этом суть та же, что у метрики, предложенной мной.

      • Анатолий Павлюченко

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

    • Дмитрий Исайченко

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

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

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

      • Анатолий Павлюченко

        В свете предыдущих уточнений – полностью согласен. Спасибо.

  • Кирилл Чистяков

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

    • Дмитрий Исайченко

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

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

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

      • Юрий Ерин

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

        • Дмитрий Исайченко

          Мне кажется это уже больше похоже на разбор полетов, чем на оценку общего состояния процесса. Для этого KPI не нужны.

          • Юрий Ерин

            Похоже. Но эти примеры я привел потому что оценка “жив процесс или нет” важна, но может производиться по-разному.
            Метрика полезная (позволяет быстро, на высоком уровне оценить “работает/не работает”), но не самая важная (не дает понимания о результатах работы).

            • Дмитрий Исайченко

              О рзультатах – конечно не дает, о чем у же писалось выше. А вот тебе провокационный вопрос – а что такое “самая важная” метрика PRB? Знаешь такую?

              • Юрий Ерин

                Зацепил :). Не сегодня.

      • Роман Журавлёв

        …и “жив” не обязательно значит “полезен”. здесь важное слово – _процесс_. Метрика помогает контролировать наличие и стабильность потока работ. Полезность же, описанная ниже, может достигаться и отдельными несистемными подвигами.
        То есть высокие значения этой метрики могут способствовать оценки зрелости процесса (1 или все-таки выше?). 🙂

  • Роман Журавлёв

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

    • Дмитрий Исайченко

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

  • Александр Жилинский

    Использовал данную метрику в проекте 8)

    Если честно, не могу сказать, что меня она устраивает на 100%, но лучшего варианта для стартующего процесса problem пока не вижу.

    • Дмитрий Исайченко

      “Если честно, не могу сказать, что меня она устраивает на 100%…”

      Ага. Со всеми метриками такая же засада.

      “…но лучшего варианта для стартующего процесса problem пока не вижу”

      А почему именно для стартующего?

      • Александр Жилинский

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

  • Алексей

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

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

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

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

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

    • Степан Хрулёв

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

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

  • Алексей

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

  • Даниил

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

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

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.