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

О вреде целевых значений для KPI

Каждые выходные мы с ребёнком ходим на лыжах. Обычных, беговых. В этом году – в ближайший парк в 10 минутах от дома, хотя в прошлые годы испробовали все парки Москвы и часть – Подмосковья.

Я заметил интересную вещь. Раньше мы как-то планировали время – сколько мы собираемся кататься, и от этого выбирали себе маршрут. В этом году я перестал смотреть на часы, и мы катаемся столько, сколько нам хочется, лишь в конце узнавая время. Забавно, что каждый раз получается по-разному: от часа до трёх, но каждый раз мы получаем максимум удовольствия.

Вывод: отсутствие целевого значения максимизирует полезный результат. Проверено практикой. На тестовой группе 🙂

Внимание, вопрос! Применимо ли это утверждение к нашей ITSM-теме?

Приведу пример. В одной из прошлых жизней у меня для первой линии было установлено правило: если звонок требует более 15 минут на решение, его следует передать на вторую линию, чтобы обеспечить доступность первой. В большинстве случаев инженеры поддержки (так мы называли сотрудников первой линии) этим правилом пользовались, особенно радуясь, что можно загрузить полезной работой простаивающих коллег. Но иногда могли с позвонившим пользователем проговорить и 20, и 30 минут.

Я никогда не считал это проблемой. Случаи бывают разные, и если инженер решил, что нужно использовать больше времени – это его решение, и он молодец. Мы получим удовлетворённого пользователя, которого не ставили в очередь, и для которого сделали всё, что нужно. При этом на первой линии видна очередь звонков, и инженер понимает может ли он себе сейчас позволить долгое общение с конкретным человеком.

Итого, установленное целевое значение KPI является лишь ориентиром. Жизнь – богаче, и не следует вгонять квалифицированный персонал в жёсткие рамки.

Или всё не так?

«VAP: Построение системы KPI для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

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

  • По-моему, целевые значения, как и мат. статистика, работают на больших выборках. Т.е. ставить их к одной конкретной “транзакции” (общению с пользователем по одному вопросу, одной прогулке на лыжах) – как правило бессмысленно. И кроме того, во многих случаях желательно иметь метрики-противовесы, чтобы препятствовать “имитации кипучей деятельности”. На наших примерах:

    1. Лыжи. Метрика 1: среднее время прогулки. Метрика 2: ну например средний пробег за одну прогулку или средняя скорость движения (обе метрики – чтобы не профанировать, пребывая на одном месте длительное время).
    2. Общение первой линии с пользователями. Метрика 1: доля запросов, решенных на первой линии. Метрика 2: доля звонков, отвеченных за заданное время (или, на худой конец, доля звонков с продолжительностью менее N минут, но это не очень хорошая метрика для целевых значений – слишком косвенная).

    И наконец главное – метрики только средство контроля. Если основное назначение лыжных прогулок – получать наслаждение, то если что-то и измерять, так это уровень удовольствия, а не продолжительность прогулки 🙂

    P.S. Можно ли измерить уровень удовольствия, не знаю. Но подозреваю что хотя бы косвенно оценить возможно.

    • “Если основное назначение лыжных прогулок — получать наслаждение, то если что-то и измерять, так это уровень удовольствия, а не продолжительность прогулки”

      Мне кажется что общепринятое мнение – чем дольше гуляли, тем больше молодцы. Ребёнок ведь по своей воле домой не пойдёт, разве что устанет сильно, чего обычно дождаться не получается 🙂

      Тем более что время намного легче измерить, чем удовольствие.

      Так что косвенно – но всё же измеряем результат.

  • Т.е. поясню. Утверждение “отсутствие целевого значения максимизирует полезный результат.” наверно не совсем верно. Видимо, просто меряем не то, что является результатом 🙂

  • мне кажется, общая идея близка той, что описана во вчерашней новости (http://www.realitsm.ru/2011/02/it-processy-v-krizis-kto-vinovat-i-chto-delat/ ): метрики, ограничивающие инициативу, – лишь одно из проявлений излишней нормативности процессов, упомянутой там. то есть принципиально предложенное правило работает и для ITSM, но не буквально, а в более общем виде: "при правильной мотивации исполнителей направление движения важнее измеримых целей"

    • Вот-вот, сформулированный более общий вид, на мой взгляд, совпадает с тем, о чём я писал. Мне кажется так оно и есть, хотя бы в части случаев.

      Но в нашем ITSM-мире: что мы можем сделать, кроме декларации целей процесса, чтобы ключевые исполнители понимали и помнили про направление движения, а не только про навешанные на них KPI?

  • Георгий

    Ну видимо дело в том, что система KPI, собственно придумана для того, чтобы управлять организациями и коллективами в тех случаях, когда нет возможности у менеджера непосредственно и постоянно оперативно работать со всеми участниками (т.е. в больших структурах или территориально-распространенных ну итп), именно в таких случаях нужны хоть какие-то методы управлять тем “что не видишь и на постоянно глубоком уровне не знаешь”
    В случае небольших команд, где менеджер может оперативно отслеживать работу всей команды и каждого в отдельности, такие, чрезмерно усложенные структуры показателей не нужны и даже отчасти вредны. Единственное что может быть в таком случае полезным, это использовать показатели для неких образно-условных целей к которым нужно стремиться но не возводить их в абсолют.

    мда. Чета хватит занудствовать 🙂 пока отдыхать 🙂
    все 😀

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

      • Георгий

        Ну не только на расстояниях я имел ввиду, но и в крупных структурах, где система показателей пока является одним из самых популярных и эффективных способов контроля.
        В “случаях, когда менеджер непосредственно видит исполнителей, находится с ними рядом какую-то часть своего рабочего времени” – не повод не применять систему показателей, но и не повод копировать сложные системы управления )

  • Ирина

    В некоторых случаях это очень полезно особенно для внутреннего анализа работы той же 1 линии, но не для озвучивания заказчику. Например приведенный показатель может использоваться, если это большая организация и в работе 1 линии используется ПО Call Center. После 15 мин оператор должен принять решение продолжить разговор или передать (посмотреть на очередь, оценить может ли он вообще решить этот вопрос..). А в это время у руководителя будет показано кто разоваривает дольше установленного показателя и можно прослушать это о работе или уже вольный треп 🙂
    Или в среднем 80% разговоров короче 15 мин. Вышел новый документ, регламентирующий доступ. Показатель упал до 60% и в основном это консультации по пониманию документа. Значит надо что-то делать: учить людей, писать информационные письма и тд
    Конечно я утрирую, но конкретную цифру можно использовать для дела 🙂

  • Вадим Куприн

    Я бы скорее сказал по другому. Наличие глобальной цели (в рамках процесса),а не целевого значения, даёт максимально полезный результат. Если задать и главное принять цель – решение обращений пользователей с высоким уровнем удовлетворённости этих самых пользователей. То не суть важно, какое будет среднее значение общения с пользователем 15, 16 или 20 минут. Оператор будет стремиться обеспечить выполнение цели и сам будет искать баланс между временем, качеством и “вкладыванием души” в выполненении поставленной ему задачи. Именно поэтому существуют командообразующие трененги и программы по воспитанию корпоративного духа. Сотрудник компании принявший цель компании начинает проявлять творческую инициативу, что обычно эффективнее чем простоё следование регламенту в рамках ключевых показателей.


Добавить комментарий для Роман ЖуравлёвОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM