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

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

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

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

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

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

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

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

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Построение системы KPI для ИТ

Как обеспечить управление процессами, проектами, услугами, персоналом