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

И снова (N+C)/(O+C)

fixedПро метрику продуктивности процесса управления проблемами, которая рассчитывается по этой формуле, я уже писал и неоднократно (и на портале, и в книге). Однако жизнь показала, что эту формулу можно еще немного улучшить, уточнив определение операнда C. Это позволит повысить защищенность метрики по отношению к активностям, которые не приносят ценности, а лишь имитируют кипучую деятельность.

Например, представьте, что менеджер проблем просто закрывает большинство поступивших проблем с кодом закрытия «Решение нецелесообразно». Работа кипит, пользы никакой, KPI близок к единице. Или регистрируются дубли, которые сразу и закрываются с соответствующим признаком. В книжке дается рекомендация не включать такие проблемы в расчет С. Но можно поступить немного жестче.

Надо поделить все коды закрытия проблем на три кучки:

а) проблема решена – процесс её обработки принес пользу, ресурсы потрачены не зря;

б) проблема закрыта без решения, трудозатраты напрасны – не только нет пользы, но есть вред в виде непродуктивной траты ресурсов;

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

В числитель должны попадать только проблемы, закрытые с кодом решения из группы «а» (поэтому C в числителе можно переименовать в R). В знаменатель должны попадать проблемы из групп «а» и «б». Тогда имитация кипучей деятельности (трудозатраты без результата) будут снижать значение метрики. Проблемы из группы «в» должны быть исключены и из числителя, и из знаменателя. Тогда разовые ошибки типа регистрации дублей вообще не будут влиять на значение KPI – ни в сторону необоснованного увеличения, ни в сторону случайного уменьшения.

Мелочь, но может пригодиться.

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

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

  • Юрий Ерин

    Есть еще четвертая кучка. Долго искали причину проблемы. Не нашли. Дальше тратить не имеет смысла. Ресурсы потрачены. Куда ее?

    Может быть и пятая. Искали причину, нашли. Устранить не можем. Ресурсы потрачены. Куда ее?

    • Есть еще четвертая кучка. Долго искали причину проблемы. Не нашли. Дальше тратить не имеет смысла. Ресурсы потрачены. Куда ее?

      Если не имеет смысла и проблема закрывается - Б. По всем признакам подходит.

      Может быть и пятая. Искали причину, нашли. Устранить не можем. Ресурсы потрачены. Куда ее?

      А почему закрываем? Эта проблема идёт на контроль известных ошибок, закрывать ее некорректно.

      • Альберт

        Может лучше делать взвешенную оценку в зависимости от приоритета проблемы? Есть проблемы, затраты на устранение которых не сопоставимы с потерями, а они будут тянуть общую оценку вниз если их закрывать со статусом б).

        • Может лучше делать взвешенную оценку в зависимости от приоритета проблемы?

          Об этом есть в книжке (страница 50). Но предложенное в данной заметке изменение формулы — не альтернатива, а дополнение.

          • Альберт

            Дмитрий, видел. Я к тому что в чистом виде, без взвешенной оценки, у формулы смысл теряется. Т.е. напор воды из крана, через который наполняется резервуар с проблемами неравномерный.

            • Я бы согласился, если бы знал надежные способы дифференцировать проблемы по уровню влияния. Но там, к сожалению, довольно много субъектива. Причем субъектива именно тех людей, кто оценивется этой метрикой. Поэтому я бы не был так категоричен в части "не имеет смысла".

      • Сергей

        Может быть и пятая. Искали причину, нашли. Устранить не можем. Ресурсы потрачены. Куда ее?

        Это тоже вариант Б. Найденная причина — это не решении проблемы. Если нет возможности устранить, то значит трудозатраты были напрасны

         

         

  • Сергей

    б) проблема закрыта без решения, трудозатраты напрасны – не только нет пользы, но есть вред в виде непродуктивной траты ресурсов;

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

    а нужна ли вообще декомпозиция на два варианта?

    в обоих же случаях в конечном итоге проблема не решена, а паразитные трудозатраты присутствуют и в том и в другом случае... только в пункте Б их несколько больше...

    Возможно, имело бы смысл делить на Б и В, если бы было желание ввести метрику (как бы то ни странно звучало) "неэффективности процесса", когда необходимо количественно оценивать "ненужные" работы по первичному анализу и закрытию дублей/ошибок/переназначений/и т.п.

     

    • а нужна ли вообще декомпозиция на два варианта?

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

  • Nargiza Suleymanova

    Дмитрий, спасибо! Утащила к себе в копилку 🙂


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

Ваш адрес email не будет опубликован.

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM