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

Измеряем Problem management

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

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

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

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

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

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

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

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от участников разработки

Комментариев: 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) к каждой из проблем по этой визуализации:

    • Даниил

      Картинка не подгрузилась :\

      Вот она - https://screenshot.ru/upload/images/2015/08/19/2015-08-1911_53_54-DLYISCICENKO.vsdx-VisioPROFESSIONALNYI5767a.png

      • 1 и 2 — C, 3 — О, 4 — O и N.

        • Даниил

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


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

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

  • Рубрики

  •  
  • Авторы

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

    • FinOps с помощью Governance-as-Code
      Масштабы и сложность решений, основанных на облачных технологиях, продолжают расти. Слишком часто это расширение также означает, что затраты продолжают выходить из-под контроля. В
    • Применима ли концепция «сдвиг влево» (shift left) для инженеров по надёжности систем (SRE)?
      Концепция «сдвига влево» помогает упростить некоторые аспекты разработки программного обеспечения. Но предназначена эта концепция не только для разработчиков. Она
    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT