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

Почему они возвращаются? Интересная метрика для службы поддержки

Опубликовано 2 февраля 2011
Рубрики: ITSM, Service Desk, SLA, SLM, BRM, Аналитика: точка зрения, Измерение и оценка ИТ, Эксплуатация ИТ
Комментарии

Один из авторов портала ERP4IT, alphasong, предлагает интересную метрику для оценки работы службы поддержки. Цель метрики – выявить и свести к минимуму случаи неполного выполнения заявок. 

Действительно, часто оказывается, что стремление службы поддержки закрывать обращения как можно скорее стимулирует специалистов поддержки объявлять завершенными работы, которые выполнены не полностью, или работы, выполнение которых оказалось по каким-то причинам прервано или отложено. Автор приводит такие примеры:

  • Пользователь запросил установку MS Excel. Excel был установлен, заявка закрыта. Пользователь обращается вновь, теперь уже с запросом на установку Excel PowerPack.
  • Пользователь обратился с каким-либо запросом. После чего заболел. Чтобы заявка не висела, мы ее закрыли с каким-нибудь специальным кодом. Вопреки нашим ожиданиям он выздоровел и вернулся. И вынужден обращаться к нам повторно. 

Можно привести еще много примеров, объединенных общей идеей: формально служба поддержки решает разные задачи, и каждую – в срок. В то же время с точки зрения пользователя одна задача решается с нескольких попыток.

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

Разумеется, есть отдельные пользователи, жаждущие общения, а также новые сотрудники. И те, и другие, скорее всего, обратятся к нм больше чем однажды, и больше, чем среднестатистический пользователь. Тем не менее для тех самых среднестатистических метрика должна быть полезной. 

Оригинальный текст и возможность ответить автору (alphadog alphasong) – на сайте erp4it.  

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Построение системы KPI для ИТ
Как обеспечить управление процессами, проектами, услугами, персоналом

Также по теме:

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

  • Анатолий Павлюченко

    так “alphadog” или “alphasong”? 🙂

  • Павел Солопов

    Идея интересная, но как-то подсознательно чувствую, что метрика будет очень обманчивая…
    Она всё же нам не покажет проблему, что действительно по одному и тому же вопросу ходят по нескольку раз. даст лишь информацию для размышления. для подтверждения которой необходимо будет проделать в ручную кропотливый анализ.
    цель в чём? Поставить каким-то образом на вид нерадивому сотруднику, чтобы он за один раз всё делал, а не ходил по сто раз. А с такими раскладами мы пока метрику получим, пока все подозрительные варианты разроем, кто там был виноват. Пройдёт минимум месяц. И в итоге мы будем ставить на вид за “достижения” позапрошлого месяца… Неэффективно это.

    • Роман Журавлёв

      Павел, а есть такие аналитические метрики, для которых ваш комментарий не применим в той же мере?
      Я думаю, если по итогам месяца мы видим, где у нас есть возможности для улучшения, а по итогам следующих месяцев можем оценить эффективность предпринятых действий по улучшению, то это просто прекрасно.
      И дело не обязательно в нерадивом сотруднике, правда? Выводы из полученных данных могут быть существенно разнообразнее…

      • Павел Солопов

        Это тоже большой вопрос, нужны ли такие аналитические метрики?
        Для анализа аналитических метрик нам надо содержать штат аналитиков, которые стоят денег и порой не малых. Согласен ли пользователь платить за этих аналитиков или лучше пару раз в SD перезвонит. 🙂

        Давайте реально взглянём на вещи, для не_гигантских компаний, нужны простые и конкретные метрики, на которые ясно как реагировать. Типа светофора: красный – жми на тормоз, зелёный-газуй. Поскольку сил, времени и квалификации на анализ чаще всего нет.

        • Роман Журавлёв

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

          Вот у меня как у менеджера процесса есть важная аналитическая метрика – загрузка класса на открытых курсах (среднее число слушателей на курсе в сравнении с числом мест в классе). На уровне “газ-тормоз” она не работает. Зато очень даже работает в перспективе квартал – полугодие – год, помогая мне оптимизировать портфель курсов, расписание, нагрузку на тренеров и в итоге – повышать рентабельность.
          Метрика есть, и анализ есть, и польза есть. Штата аналитиков нет – и не требуется. Компания не гигантская.

          • Павел Солопов

            Если на чистоту, что вам даёт эта метрика? Вы знаете, что у вас стало меньше или больше слушателей, а почему? Реклама, конкуретны, неактуальные темы, плохая работа преподавателей, вирус гриппа, финансовый кризис или что-то ещё? Чтобы найти корреляцию надо попотеть. Можно конечно ограничиться апроксимацией и экстраполяцией, это тоже полезно, но это не всё. Да и в случае метрики, которую мы обсуждали изначально не очень-то и нужно.
            К тому же объём данных для анализа у менеджера управления инцидентами даже в средненькой организации будет, я думаю, на порядок больше вашего.
            Ну и самое главное, менеджеров с такими способностями и талантами, как у вас Роман, ещё поискать надо. 🙂

  • Роман Журавлёв

    alphasong.
    мысленно перед ним извинились.
    исправили.

  • old fuddy-duddy

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

  • Роман Журавлёв

    Какая разница, _как_ делать? Вопрос (здесь) – в том, _что_ делать.
    Периодически устраивая опросы мы или спросим о том, как часто людям приходится обращаться повторно в связи с тем, то их не вполне устраивают первые результаты, либо НЕ спросим. Идея – в том, чтобы спросить. А опросами или подсчетом заявок – это детали.

    Что до жалобной книги, то я регулярно спрашиваю людей на курсах, когда они последний раз писали что-либо в жалобную книгу. Обычно из десятка слушателей помнят примерное время один-два. Люди ценят возможность жаловаться, но не используют ее, если качество услуг не падает ниже отметки “удовлетворительно”. Я бы предпочел знать их мнение раньше и начинал волноваться, когда оно падает ниже “отлично”. А на этом этапе жалоб никто не пишет.

    • old fuddy-duddy

      Я бы все-таки начал с вопроса «зачем делать?»
      «Я бы предпочел знать их мнение раньше и начинал волноваться, когда оно падает ниже «отлично».»
      То, что хотите Вы, можно сделать гораздо проще и надежнее, добавив пользователю в форму подтверждения решения возможность проставить оценку решению.
      А на результат обсуждаемой метрики, по моему мнению, все же влияет слишком много посторонних факторов, замучаетесь интерпретировать, а если попробуете привязать её к мотивации, Вас вообще съедят.

  • Анатолий Павлюченко

    Немного неверно сформулирована цель в русском переводе: “Цель метрики — выявить и свести к минимуму случаи неполного выполнения заявок.” В оригинале речь идёт о “failure demand” (погуглите, найдёте много интересного!) и не только в разрезе выполнения заявок, но и любых других обращений (“or Incidents (or perhaps other processes)”).
    Предложенную метрику я понимаю так. Формальный (среднестатистический) показатель того, насколько полно выполнились _ожидания_ обратившегося с первого раза! Ни чуточки не “обманчиво”. Очень даже красивая метрика. Она отображает множество аспектов взаимодействия клиента и службы поддержки:
    – насколько хорошо соответствуют формы заявок действительным нуждам клиентов;
    – насколько полно устраняются инциденты;
    – достаточно ли информации получают клиенты при общении со службой поддержки;
    – достаточен ли уровень удовлетворённости клиентов.
    Хотел ещё написать про “работающий процесс решения проблем”, но, думаю, это уже лишнее.

    • Павел Солопов

      Спору нет, показывает, точнее может показать. Вы вот перечислили четыре пункта, наверное можно ещё добавить.
      В итоге мы видим, что в среднем каждый пользователь обратился к нам 3 раза за месяц, мы понимаем, что это плохо, но в каком направлении у нас проблемы? Метрика не покажет, скорее всего, для этого надо разгрести всё руками – это серьёзный объём работ.

      Пожалуй её можно применить при еденичном анализе, чтобы выявить проблему или проблемы. Найти их и задушить, а вот в оперативном режиме толку мало.

      Ну или ещё вариант, если у вас есть еденичные случаи нарушения метрики. Но бороться с еденичными случаями есть ли смысл?

      • Анатолий Павлюченко

        Эта метрика, понятно, не предназначена для “единичного анализа”. Как и для всякой статистической метрики вы должны установить целевое значение и допуски и следить на регулярной основе (автоматизируется для готовых систем достаточно легко). Выход за рамки должен сигнализировать, что существуют определённые тенденции и вам надо что-то делать. “Что” именно делать – зависит от других показателей и/или проведённого “единичного анализа” и того, как устроен оперативный мониторинг процессов и процесс управления уровнем обслуживания.
        А с единичными случаями надо не бороться, а реагировать! 🙂 после оценки рисков и подсчёта доступных ресурсов.

  • Роман Журавлёв

    Для тех, кому лень гуглить failure demand:
    value demand – спрос на полезные проявления услуг.
    failure demand – спрос на корректировку нереализации value demand. То есть спрос на исправление ошибок.
    Чем он выше, тем ниже рациональность деятельности по предоставлению ценности.

    Термин введен Джоном Седдоном (John Seddon) в книге “Freedom from Command and Control: A Better Way to Make the Work Work”. Обычно рассматривается в контексте lean services. (failure demand – индикатор потерь – тех, с которыми борется lean)

    • Анатолий Павлюченко

      Мне больше нравится вариант – “недополученное удовольствие” 🙂

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.