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

«Эмоциональные метрики»

Стивен Вест в недавней статье «The Importance of Managed Emotional Metrics in ITSM» на портале ITSM.tools высказывает известный тезис о том, что помимо объективных показателей, согласованных в SLA, необходимо контролировать удовлетворённость потребителя (слышать голос заказчика (voice of the customer, VoC). Многие компании делают подобные замеры. Некоторые компании делают показатели удовлетворённости частью параметров SLA.
Но автор использует интересный (и жизненный) пример для демонстрации идеи и делится своей практикой получения этого самого VoC. Поэтому ниже его пример, и описание его практики.

Рассмотрим два сценария.

  1. Вы договорились с обслуживающей компанией о визите к вам техника. Дата назначена, время согласовано. Вы всё подготовили. К сожалению, за 48 часов до визита поставщик услуг информирует вас о том, что в связи с обстоятельствами, независящими (действительно независящими) от данной компании, они вынуждены отложить визит. И предлагают другие даты. Вы раздосадованы. Однако позанимаете, что в сложившихся обстоятельствах работы в вашей квартире действительно имеют более низкий приоритет.
  2. Вы договорились с обслуживающей компанией о визите к вам техника. Дата назначена, время согласовано. Вы договорились, что будете ждать дома визита техника в первой половине дня. Поставщик услуг сообщил, что проинформирует вас с помощью СМС за 30 минут до визита техника. И, поскольку ваш дом находится в 15 минутах от работы, вы смело отправились на работу, понимая, что, получив СМС, спокойно успеете добраться к приезду техника. В какой-то момент времени вы получаете входящий звонок (не СМС). Это звонит техник. Он у двери вашего дома. На часах 11:00. Он предупреждает, что может ждать не более 30 минут, так как у него дальше по плану следующие работы у других клиентов. Вы понимаете, что даже если успеете вернуться домой до отъезда техника, работы выполнить уже не удастся. Техник говорит, что может быть получится вернуться к вам вечером, после окончания прочих запланированных работ. До самого вечера от него нет никаких вестей. Вы даже отложили ужин на всякий случай. И лишь после окончания рабочего дня он позвонил, чтобы извиниться и сказать, что сегодня приехать не получится.

В каком из сценариев (если) нарушен SLA?

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

Во втором сценарии SLA скорее всего нарушен не был {прим. если, конечно, «предупреждение с помощью СМС за 30 минут» не являлось частью SLA}. Техник прибыл вовремя. Т.е. поставщик был готов оказать услугу. Техник даже предложил вернуться позже. Т.е пошёл навстречу клиенту. Великолепный сервис, не правда ли? Скорее всего, нет.

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

Автор предлагает контролировать не только объективные показатели качества предоставления услуги, но и «эмоциональные метрики». И если классикой ITSM является сбор обратной связи у пользователей по закрытию обращений (запросов на обслуживание или инцидентов), а у заказчиков на регулярной основе в виде опросников или интервью (некоторые компании также практикуют регулярные опросы пользователей), то Стивен рассказывает о том, что он создал документ с простой структурой, снабдив простым руководством по его использованию. Структура документа:

  • Имя
  • Дата
  • Комментарий
  • Подтверждающие высказывание свидетельства

Доступ к документу имею все заинтересованные лица заказчика.
Цель – услышать голос заказчика (VoC), узнать о его опыте потребления продукта или услуги, его ожидания относительно продукта/услуги. Такой метод позволяет, по мнению автора, проактивно получать обратную связь (что также является отличным каналом информации для постоянного совершенствования). Постоянная работа с содержимым данного документа и регулярная отчётность прямо там же, по каждой записи, позволяет заинтересованным сторонам понимать, что было сделано, что делается. И каждая запись остаётся в открытом статусе, пока соответствующее заинтересованное лицо не поймёт, что запрос удовлетворён.

Интересно, кто-нибудь использует именно такой подход?

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

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

  • Юлия

    Тема важная.

    В данном подходе (при использовании предлагаемого документа) не совсем понятно, к какому событию привязан документ, что должно послужить триггером к его появлению, непонятна частота появления.

    В своей работе по сбору обратной связи мы стараемся сочетать два подхода:

    1) Возможность обратной связи с оценкой и комментарием от пользователя по каждому его обращению

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

    Причем, п.1 мы внедрили позже, чем п.2. И взлетел он не сразу. Оно и понятно: гораздо проще раз в квартал написать на портале общими фразами «все хорошо» (или нет...), чем взять на себя труд оценить каждое свое обращение.

    Тем не менее, практика показывает, что важно использовать оба подхода. п1. для анализа по конкретным кейсам и, если необходимо, изменению используемых практик.

    п.2 бывает ценен тем, что в комментариях к общим оценкам качества сервиса мы слышим

    тот самый VoC, что дает нам потенциальную возможность совершенствовать качество своих услуг. Насколько этот потенциал может быть использован и используется — вопрос для отдельного диспута )


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
    • 5 основных тенденций развития искусственного интеллекта и машинного обучения на 2022 год
      Вот несколько основных тенденций, к которым вашему бизнесу стоит начать готовиться. Искусственный интеллект и машинное обучение становятся доминирующей частью технологической
    • 6 тенденций в ИТ, за которыми нужно следить
      Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями - как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
    • Восход Desktop-as-a-Service: что это такое и зачем вам это нужно?
      Широкое распространение облачных вычислений добавило в наш словарь множество сокращений, наиболее распространенными из которых являются SaaS, PaaS и IaaS. Действительно, наступила эра облачных решений, которые доставляют программное обеспечение, платформу и инфраструктуру потребителям и предприятиям по запросу и с оплатой по мере использования.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT