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

Вопрос из зала: чего мы ждём от Service Desk?

В редакцию нашего портала поступил вопрос от Ленара Рахматуллина, руководителя Service Desk, ICL Services:

service_desk_expectations Добрый день!

Предлагаю обсудить ожидания участников от службы Service Desk. В настоящее время у себя в подразделении занимаемся разработкой стратегии развития, совместно с сотрудниками описываем основные ценности и принципы, которым следует Service Desk, выполняя ежедневные задачи. Хотелось бы при этом, кроме своего опыта и понимания, опираться на экспертное мнение участников форума — представителей ИТ-организаций и служб.

Могу предложить следующие 3 ключевых, с моей точки зрения, ожидания:

1. Service Desk должен быть связующим звеном в ИТ-организации для координации работ между разными группами, независимо от из принадлежности к компании или стороннему поставщику;

2. Service Desk должен обеспечивать постоянное улучшение пользовательского опыта (End User Experience) за счет регулярного тренд-анализа, идентификации и решения проблем и применения других практик continuous improvement;

3. Оператор Service Desk, должен индивидуально подходить к каждому обращению, учитывать конкретную сложившуюся у пользователя ситуацию и ее влияние на бизнес-процессы, подстраиваться под поведенческие особенности конкретного пользователя.

Сознательно не говорю об SLA, поскольку на практике, это, как правило, договор. Договорные обязательства нарушать нельзя. Это сродни границе между государствами — за нарушение границ следует  неотвратимое наказание. Но SLA — далеко не все, что ждет от Service Desk и от ИТ бизнес.

Каковы ваши ожидания от службы Service Desk?

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

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

  • Nargiza Suleymanova

    1. Service Desk должен быть связующим звеном в ИТ-организации для координации работ между разными группами, независимо от из принадлежности к компании или стороннему поставщику;

    В первую очередь, Service Desk — это единая точка контакта ИТ-службы с пользователями, и желательно делать упор именно на задачи выстраивания коммуникаций. Насчет координации всех работ исключительно функцией Service Desk не все так однозначно, часто координация работ внешних поставщиков выполняется сотрудниками 2-й или 3-й линий.

    2. Service Desk должен обеспечивать постоянное улучшение пользовательского опыта (End User Experience) за счет регулярного тренд-анализа, идентификации и решения проблем и применения других практик continuous improvement;

    Поясните, у вас процесс управления проблемами возложен на Service Desk? 

    3. Оператор Service Desk, должен индивидуально подходить к каждому обращению, учитывать конкретную сложившуюся у пользователя ситуацию и ее влияние на бизнес-процессы, подстраиваться под поведенческие особенности конкретного пользователя.

    Про поведенческие особенности наверное соглашусь, но вообще, желательно в рамках Service Desk максимально все унифицировать.

    • Ленар Рахматуллин, рук. Сервис Деск, ICL Services

      Наргиза, спасибо за Ваш комментарий. Говоря о том, что Service Desk (SD) координирует работы разных групп, прежде всего имею в виду, что мы стараемся организовать процессы таким образом, что SD в терминах RACI является Accountable за решение конкретного инцидента или запроса. То есть крайним ответственным перед пользователем. Это позволяет избежать перебрасывания инцидентов между разными группами, размытия ответственности. Есть случаи когда действительно имеет смысл коодинацию возложить на 2-3 линию. Часто это происходит с инцидентами, которые требуют привлечения вендоров. С вендорами нужно общаться на профессиональном языке и хорошо знать технологии. Но даже в этом случае агент Service Desk убедится, что прогресс в решении инцидента есть, про него никто не забыл, всех поторопит и проинформирует пользователя (т.е. снова Accountable).

      Касательно Problem Management — не совсем. Этот процесс охватывает всю ИТ-службу и даже представителей бизнеса и управляется Problem Manager. Он, как правило, не входит ни в одну из функций или групп. SD со своей стороны — участник процесса и может регистрировать Problem Candidates, принимать участие в решении проблем. Уникальная возможность, которая есть у SD — это прямой контакт с пользователями, понимание именно пользовательского опыта и может концентрироваться на улучшении коммуникации, инструментария, обучении пользователей и тп.

      • Nargiza Suleymanova

        Но даже в этом случае агент Service Desk убедится, что прогресс в решении инцидента есть, про него никто не забыл, всех поторопит и проинформирует пользователя (т.е. снова Accountable).

        Собственно говоря, это ответственность за координацию действий по решению инцидента. И тут я абсолютно согласна. Но вот с тем, чтобы в KPI специалистов 1-линии включать ответственность за решение всех инцидентов — у меня большие сомнения. То, что в силах решить специалистам Сервис Деск, включать безусловно надо, а вот с тем, что решают 2/¾ линии — вопрос вам для размышления.

        Касательно Problem Management — не совсем. 

        Service Desk должен обеспечивать постоянное улучшение пользовательского опыта (End User Experience) за счет регулярного тренд-анализа, идентификации и решения проблем и применения других практик continuous improvement

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

  • В вопросе "ожидания участников от службы Service Desk" я бы предложил определить о каких участниках идёт речь. Можно принципиально выделить две группы — клиенты компании (они же клиенты Service Desk) и собственно провайдер, чьим "фронтом" и является Service Desk. Ожидания этих двух групп могут быть различными.

    Без подробностей об организации и о Service Desk сложно сказать что от него ожидают клиенты — надо знать этих клиентов. В общем случае клиент хочет никогда на Service Desk не обращаться, но это вряд ли задача SD. Если же клиент обратился, то ему наверняка захочется:

    1. быть обслуженным быстро, без ожиданий свободного специалиста, без IVR и прочей мути

    2. чтобы его проблему решили

    3. чтобы с ним общались не как с очередным из миллиона одинаковых, а как с клиентом, который платит деньги и ожидает за эти деньги получить качественные услуги

    Третий пункт моего списка очень созвучен с третьим пунктом списка Ленара. Такой пункт довольно сложно измерить, в отличие от первых двух, где KPI придумать и реализовать достаточно просто.

    Примечательно, что примеров "как не должен выглядеть Service Desk" вокруг очень много. Почти любой банк, почти любая страховая, почти любой ритейл... Мы все это видим каждый день. В то время как примеров исключительного сервиса в России почти нет (в Европе, кстати, такого тоже немного). Было бы здорово где-то собрать список компаний, которым удалось так построить поддержку клиентов, что их можно приводить в пример.

     

    • Леонид

      в качестве примера исключительного (моим аршином) SD могу привезти таки банк Авангард, которым в том числе поэтому пользуюсь более 10 лет, при том, что их SD, как правило, пользоваться (Олег — прав!) не приходится.

  • Леонид

    если отсутствие IVR, то на карте тлф. +7 (495) 234-98-98; поверхостно в качестве SD можно убедиться, сымитировав инцидент: например, высказав заинтересованность выпустить карту. Косвенный показатель качества SD (как части банка) — многолетнее его нахождение в топе народного рейтинга banki.ru.

    (это не реклама — сарафанное радио! 😉


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

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

  • Рубрики

  •  
  • Авторы

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

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • 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. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT