Каждые выходные мы с ребёнком ходим на лыжах. Обычных, беговых. В этом году – в ближайший парк в 10 минутах от дома, хотя в прошлые годы испробовали все парки Москвы и часть – Подмосковья.
Я заметил интересную вещь. Раньше мы как-то планировали время – сколько мы собираемся кататься, и от этого выбирали себе маршрут. В этом году я перестал смотреть на часы, и мы катаемся столько, сколько нам хочется, лишь в конце узнавая время. Забавно, что каждый раз получается по-разному: от часа до трёх, но каждый раз мы получаем максимум удовольствия.
Вывод: отсутствие целевого значения максимизирует полезный результат. Проверено практикой. На тестовой группе 🙂
Внимание, вопрос! Применимо ли это утверждение к нашей ITSM-теме?
Приведу пример. В одной из прошлых жизней у меня для первой линии было установлено правило: если звонок требует более 15 минут на решение, его следует передать на вторую линию, чтобы обеспечить доступность первой. В большинстве случаев инженеры поддержки (так мы называли сотрудников первой линии) этим правилом пользовались, особенно радуясь, что можно загрузить полезной работой простаивающих коллег. Но иногда могли с позвонившим пользователем проговорить и 20, и 30 минут.
Я никогда не считал это проблемой. Случаи бывают разные, и если инженер решил, что нужно использовать больше времени – это его решение, и он молодец. Мы получим удовлетворённого пользователя, которого не ставили в очередь, и для которого сделали всё, что нужно. При этом на первой линии видна очередь звонков, и инженер понимает может ли он себе сейчас позволить долгое общение с конкретным человеком.
Итого, установленное целевое значение KPI является лишь ориентиром. Жизнь – богаче, и не следует вгонять квалифицированный персонал в жёсткие рамки.
Или всё не так?
По-моему, целевые значения, как и мат. статистика, работают на больших выборках. Т.е. ставить их к одной конкретной “транзакции” (общению с пользователем по одному вопросу, одной прогулке на лыжах) – как правило бессмысленно. И кроме того, во многих случаях желательно иметь метрики-противовесы, чтобы препятствовать “имитации кипучей деятельности”. На наших примерах:
1. Лыжи. Метрика 1: среднее время прогулки. Метрика 2: ну например средний пробег за одну прогулку или средняя скорость движения (обе метрики – чтобы не профанировать, пребывая на одном месте длительное время).
2. Общение первой линии с пользователями. Метрика 1: доля запросов, решенных на первой линии. Метрика 2: доля звонков, отвеченных за заданное время (или, на худой конец, доля звонков с продолжительностью менее N минут, но это не очень хорошая метрика для целевых значений – слишком косвенная).
И наконец главное – метрики только средство контроля. Если основное назначение лыжных прогулок – получать наслаждение, то если что-то и измерять, так это уровень удовольствия, а не продолжительность прогулки 🙂
P.S. Можно ли измерить уровень удовольствия, не знаю. Но подозреваю что хотя бы косвенно оценить возможно.