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

Безальтернативность Service Desk

Опубликовано 25 февраля 2013
Рубрики: ITIL, ITSM, Service Desk, Управление инцидентами
Комментарии

Много раз обсуждали эту тему с заказчиками – правда ли необходима единая точка контакта по вопросам поддержки пользователей (Service Desk)? А если нет, то при каких условиях от неё можно или даже нужно отказываться?

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

  • нехватка ресурсов для организации SD. Благо потребность в ресурсах в данном случае оценить очень просто (например, используя формулу Эрланга или упрощенные аналоги);
  • наличие отдельных узкоспециализированных групп, которые поддерживают своих пользователей, которые пользуются только соответствующими отдельными узкоспециализированными ИТ-решениями. Здесь тема идеологически безупречна, поскольку SPOC для каждой из групп пользователей может быть обеспечен своей группой, а не одной общей группой SD на всех (но для многих заказчиков эта мысль почему-то звучит неожиданно).

Один недавний проект укрепил меня в этих мыслях еще больше, потому что заказчик, приняв эту идею, решил развить её и технически. В частности потребовал автоматической маршрутизации на профильные группы обращений, поступивших по e-mail (по ключевым словам), а также через web-интерфейс (по базовой классификации по ИТ-услугам). Мои опасения, связанные с тем, что пользователи в своих обращениях, подаваемых через электронные каналы коммуникаций, будут весьма неинформативны, не оправдались. В настоящее время через телефон на дежурную группу первой линии поступает только 19% обращений, а из остальных 81%, поступающих через e-mail и web-интерфейс, абсолютное большинство обращений (около 90%) сразу назначаются на профильную группу.

Это, разумеется, не значит, что Service Desk – зло. Это значит, что, как и другие советы по организации управления услугами, этот требует анализа применимости и альтернатив в контексте конкретной организации и задачи. Из общих соображений мне кажется, что служба Service Desk, как единая и обязательная точка контакта по вопросам поддержки пользователей, больше применима для средних компаний. Для маленьких компаний это может требовать избыточного количества ресурсов. Для больших – может не очень стыковаться с разнообразием поддерживаемых групп пользователей и множеством специфичных ИТ-услуг.

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

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

  • Альберт

    “Для больших – может не очень стыковаться с разнообразием поддерживаемых групп пользователей и множеством специфичных ИТ-услуг.”

    Для больших предприятий роль стыковщика, одна из ролей Service Desk.

    • Дмитрий Исайченко

      Надо сопоставлять плюсы и минусы. Одна группа SD – дешевле, ей проще управлять (проще добиться 100%-ного соблюдения процедур). Несколько специализированных первых линий – выше FLR, а значит больше пользы для конечного пользователя. При этом, конечно, возможны и гибридные варианты – общий SD с несколькими специализированными группами внутри. Необходимо также учитывать связь между архитектурой ИС и оргструктурой SD. В общем, тут есть из чего повыбирать (особенно в крупняке) – все не так однозначно.

  • Юрий Ерин

    “…служба Service Desk, как единая и обязательная точка контакта по вопросам поддержки пользователей, больше применима для средних компаний.”

    Почему именно для средних? Разве для них не действует изложенный чуть ранее принцип “Это значит, что, как и другие советы по организации управления услугами, этот требует анализа применимости и альтернатив в контексте конкретной организации и задачи.”?

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

    • Дмитрий Исайченко

      “Почему именно для средних? Разве для них не действует изложенный чуть ранее принцип…?”

      Действует, конечно. Именно результат применения этого принципа в ряде проектов и является основанием для обобщения: “служба Service Desk, как единая и обязательная точка контакта по вопросам поддержки пользователей, больше применима для средних компаний”. Разумеется, это не строгое утверждение. В каждом конкретном случае ответ будет свой.

  • Pavel Solopov

    Один недавний проект укрепил меня в этих мыслях еще больше

    Так точка контактов, судя по всему, была всё же единая. e-mail же общий, телефон общий, всё регистрируется в одной системе? Просто вместо девочки(мальчика) вы посадили робота в виде парсера сообщений электронной почты.
    Который распределяет заявки по группам второй линии.

    • Дмитрий Исайченко

      Нет, там разрешались прямые телефонные контакты на вторую линию. Никого на L1 не загоняли.

      • Pavel Solopov

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

        • Дмитрий Исайченко

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

          • Pavel Solopov

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

            Т.е. вывод: единая точка контактов при использовании телефона может быть эффективна только в крупных компаниях. 🙂

            • Дмитрий Исайченко

              …и конечно добавляем посылки для данного вывода:

              1. если важнее акцент не на контроль, а на скорость решения;
              2. если доступность специалистов второй линии обеспечена нужными оргмерами.

              А L1 введена не как обязательная SPOC, а как, например, вариант обратиться при отсутствии человека с L2 (возможно автороутингом звонков).
              При иных вводных и вывод будет другой.

  • Pavel Solopov

    Контроль, в принципе, можно обеспечить и при распределённой системе. Банально, брать логи с АТС и сравнивать с количеством зарегистрированных обращений.

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

    • Дмитрий Исайченко

      “Контроль, в принципе, можно обеспечить и при распределённой системе. Банально, брать логи с АТС и сравнивать с количеством зарегистрированных обращений.”

      Конечно. Только для первой линии этот способ как-то работает, а для второй гораздо хуже, поскольку специалисты L2 вовлечены уже не только в поддержку, и даже в рамках поддержки вовлечены в решение более сложных, итеративных задач. То есть сравнить-то можно, но дальше будет как в известном анекдоте: “Я печатаю 500 символов в минуту. Только такая фигня получается!” 🙂

      • Pavel Solopov

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

  • Анастасия Кировская

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

    Первая – возможно, я слишком клиентоориентированна, но мне кажется это не удобным для пользователя. Т.к. им необходимо помнить кучу телефонов: какому специалисту и в каком случае звонить. Встречала письма в SD от запутавшихся пользователей и уточнявших, кто им сможет помочь по конкретному вопросу. В нашем случае, получилось около десяти дополнительных телефонов специализированных групп. Если использовать единый SD, оператор может при звонке для специализированной группы быстро зарегистрировать обращение и тут же перевести звонок. И инженеру будет меньше хлопот с регистрацией.

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

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

    • Дмитрий Исайченко

      “мне кажется это не удобным для пользователя. Т.к. им необходимо помнить кучу телефонов: какому специалисту и в каком случае звонить”

      IVR – не вариант?

      • Анастасия Кировская

        Да, этот вариант ” в уме”, и первый в очереди на реализацию, но как быть с контролем регистрации обращений?

        • Дмитрий Исайченко

          А нельзя снимать статистику с АТС, сколько абонентов перешло на заданную группу выбором пункта меню IVR, а не просто набором номера? Если можно, включаете IVR, информируете пользователей, через некоторое время меняете прямые телефоны профильных групп и начинаете контролировать соответствие между обращениями и входящими переключениями на IVR.

          • Анастасия Кировская

            Как оказалось, возможно. И смена номера телефона – ну это же классика)) Вполне рабочий вариант

  • Анатолий

    Конечно, можно пытаться обойтись без 1 линии, но есть ряд рутинной работы, которую делать необходимо – регистрация обращений, проверка справочных данных, оповещение о сбоях (прошел сбой, пошли запросы, зачем отвлекать экспертов 2 и др. линий? Дали шаблон на 1 линию, они информируют при звонке или письмах пользователей). Таких операций, которые нецелесообразно сбрасывать на экспертов других линий, много, всё зависит от конкретных постановок задач. 

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

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

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

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

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

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