ч.3
На дашборде загорелся красный KPI: заказ вместо десяти часов обрабатывается двадцать. Первое желание вполне разумное - добавить рядом время в очереди, количество возвратов, число согласований и еще десяток показателей. Если один сообщает о проблеме, остальные вроде бы должны сразу показать причину.
Но диагностическая метрика устроена иначе. KPI привязан к постоянной цели и поэтому проверяется регулярно. Диагностическая метрика привязана к гипотезе. Она становится полезной только после конкретного вопроса: срок вырос из-за очереди, повторной работы, нового маршрута или потому, что изменился состав заказов?
Без вопроса та же метрика ничего не диагностирует. Она просто колеблется. Если постоянно следить за двадцатью показателями, какой-нибудь обязательно станет красным. На планерке придется объяснять уже его, потом соседний, а потом странный всплеск заказов из Воронежа по четвергам.
Дальше как обычно. У метрики появляется допустимое значение, ответственный и обещание вернуть цифру обратно. Люди начинают отдельно управлять временем в очереди и количеством возвратов. Показатель, который должен был проверить одну гипотезу, превращается в KPI без цели, а управление переключается с результата на объяснение шума.
Это не значит, что метрики надо придумывать после аварии. Из воздуха их не посчитаешь. Система должна сохранять факты: когда заказ пришел, где ждал, сколько раз вернулся и по какому маршруту прошел. Но хранить факты и постоянно следить за всеми производными - разные занятия.
При отклонении KPI мы формулируем гипотезу, быстро считаем нужный срез и сравниваем его с нормальным периодом. Не подтвердилось - идем дальше.
Подтвердилось - ищем решение. Диагностическая метрика живет столько же, сколько вопрос, ради которого ее посчитали.
Хорошая система измерений - не дашборд, на котором видно все. В ней постоянно видно главное, а остальное можно быстро восстановить, когда оно действительно понадобилось.
Иначе мы не диагностируем процесс, а круглосуточно измеряем ему температуру, вдруг он внезапно заболеет.
#проkpi
На дашборде загорелся красный KPI: заказ вместо десяти часов обрабатывается двадцать. Первое желание вполне разумное - добавить рядом время в очереди, количество возвратов, число согласований и еще десяток показателей. Если один сообщает о проблеме, остальные вроде бы должны сразу показать причину.
Но диагностическая метрика устроена иначе. KPI привязан к постоянной цели и поэтому проверяется регулярно. Диагностическая метрика привязана к гипотезе. Она становится полезной только после конкретного вопроса: срок вырос из-за очереди, повторной работы, нового маршрута или потому, что изменился состав заказов?
Без вопроса та же метрика ничего не диагностирует. Она просто колеблется. Если постоянно следить за двадцатью показателями, какой-нибудь обязательно станет красным. На планерке придется объяснять уже его, потом соседний, а потом странный всплеск заказов из Воронежа по четвергам.
Дальше как обычно. У метрики появляется допустимое значение, ответственный и обещание вернуть цифру обратно. Люди начинают отдельно управлять временем в очереди и количеством возвратов. Показатель, который должен был проверить одну гипотезу, превращается в KPI без цели, а управление переключается с результата на объяснение шума.
Это не значит, что метрики надо придумывать после аварии. Из воздуха их не посчитаешь. Система должна сохранять факты: когда заказ пришел, где ждал, сколько раз вернулся и по какому маршруту прошел. Но хранить факты и постоянно следить за всеми производными - разные занятия.
При отклонении KPI мы формулируем гипотезу, быстро считаем нужный срез и сравниваем его с нормальным периодом. Не подтвердилось - идем дальше.
Подтвердилось - ищем решение. Диагностическая метрика живет столько же, сколько вопрос, ради которого ее посчитали.
Хорошая система измерений - не дашборд, на котором видно все. В ней постоянно видно главное, а остальное можно быстро восстановить, когда оно действительно понадобилось.
Иначе мы не диагностируем процесс, а круглосуточно измеряем ему температуру, вдруг он внезапно заболеет.
#проkpi