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

В таблицах 12.1 и 12.2 приведен пример матриц для определения приоритета инцидента и времени, в течение которого его необходимо разрешить.

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

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

Если сервис-деск не может разрешить инцидент или сроки первой ступени разрешения инцидентов истекли, инцидент должен быть немедленно передан дальше.

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

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

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

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

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

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

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

В некоторых случаях инцидент может быть повторно открыт даже после формального закрытия. Правильным будет заранее определить правила о том, как, когда и при каких условиях инцидент может быть повторно открыт. Это используется, в частности, когда в один и тот же день возникают одинаковые инциденты. Для нового инцидента, тем не менее, необходимо сформировать новую запись со ссылкой на предыдущий инцидент. Запись о предыдущем инциденте может быть использована для разрешения нового[5].

Для эффективного Управления инцидентами необходимо обеспечить следующее:

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

Рис. 12.3. Процесс "Управление службой технической поддержки и инцидентами"

Управление службой технической поддержки и инцидентами.

удовлетворяет следующим бизнес требованиям к ИТ

эффективное использование ИТ систем путем анализа и решения проблем пользователей, вопросов и инцидентов.

сосредоточено на

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

достигается с помощью

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

В таблице 12.3 представлена информация, необходимая для процесса и ее источники.

В таблице 12.4 приведены результаты процесса и то, куда они должны поступить.