Домен "Эксплуатация и сопровождение": управление службой технической поддержки и инцидентами

Таблица 12.5 содержит таблицу ОУКИ для процесса, а таблица 12.6 – цели и показатели.

Цели контроля

• DS 8.1. Служба технической поддержки

  Создать службу технической поддержки, являющуюся зоной взаимодействия пользователей и ИТ, которая призвана регистрировать, распределять и анализировать все обращения, докладывать об инцидентах, требованиях оказания услуг и запросах на информацию. Должен быть налажен мониторинг и процедуры разрешения инцидентов, основанные на принятых уровнях обслуживания в соответствии с соглашением об уровне обслуживания, которые дают возможность классифицировать и расставить приоритеты в отношении всех инцидентов, запросов о поддержке или об информации. Замерять удовлетворенность конечных пользователей качеством работы службы технической поддержки и ИТ услуг.
• DS 8.2. Регистрация запросов

  Создать функцию и систему, позволяющие учитывать и отслеживать обращения, инциденты, запросы о поддержке или об информации. Регистрация должна быть тесно связана с процессами управления инцидентами, управления проблемами, управления изменениями, управления мощностями и управления доступностью. Инциденты должны классифицироваться в соответствии с корпоративными и сервисными приоритетами и направляться к соответствующей группе решения проблем. Пользователи должны быть в курсе текущего статуса своих запросов.
• DS 8.3. Разрешение инцидентов

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

  Разработать процедуры оперативного мониторинга по окончательному разрешению запросов пользователей. После разрешения инцидента следует убедиться в том, что служба поддержки зафиксировала механизм решения и подтвердила отсутствие претензий пользователя. Также необходимо вести учет и докладывать о неразрешенных инцидентах (известных ошибках и временных решениях), чтобы обеспечить надлежащей информацией процесс управления проблемами.
• DS 8.5. Отчетность и анализ тенденций

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

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

Как организовать сервис-деск? Сперва Вам надо:

• выделить телефонный номер или электронный адрес (а лучше и то и другое), по которым пользователи смогут сообщать о проблемах или обращаться за информацией. Адрес и телефонный номер должны быть максимально простыми, например, 5555 или sd@....ru.
• назначить ИТ-специалистов, которые будут решать пользовательские проблемы.

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

Возможный вариант приоритетов показан в таблице 12.7.

Все параметры, указанные в таблице 12.7, должны быть оговорены в Соглашении об уровне услуг (SLA).

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

Помимо того, что сервис-деск решает множество проблем, он является основным источником информации для многих процессов, например:

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

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

Ключевые термины

Сервис-деск (Service desk) – точка контакта пользователей ИТ-услуг со службой ИТ.

ИТ-инцидент (IT Incident) – любое событие, не являющееся штатным элементом ИТ-сервиса, которое причиняет или может причинить сбой или снижение качества.

Срочность (Urgency) – мера того, насколько быстро с момента своего появления инцидент, проблема или изменение приобретет существенное влияние на бизнес.

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