Опубликован: 12.11.2012 | Уровень: для всех | Доступ: платный
Лекция 12:

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

< Лекция 11 || Лекция 12: 123 || Лекция 13 >

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

Таблица 12.1.
Влияние
Высокое Среднее Низкое
Срочность Высокое 1 2 3
Среднее 2 3 4
Низкое 3 4 5
Таблица 12.2.
Приоритет Характеристика Время разрешения
1 Критичный 1 час
2 Высокий 8 часов
3 Средний 24 часа
4 Низкий 48 часов
5 Планируемый Запланировать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 12.3.
Источник Входящая информация
AI 4 Пользовательские, эксплуатационные, поддерживающие, технические руководства и руководства для администраторов
AI 6 Авторизация изменений
AI 7 Перечень конфигураций
DS 1 Соглашение об уровне обслуживания и соглашение операционного уровня
DS 4 Предельные значения для инцидентов/аварийных ситуаций
DS 5 Определение инцидентов в сфере безопасности
DS 9 ИТ конфигурация/подробности по активам
DS 10 Известные проблемы, ошибки и временные решения
DS 13 Билеты инцидентов

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

Таблица 12.4.
Результаты В процессы
Запросы о поддержке/запросы на изменения AI 6
Отчеты об инцидентах DS 10
Отчеты об эффективности процессов ME 1
Отчеты об удовлетворенности пользователей DS 7 ME 1
< Лекция 11 || Лекция 12: 123 || Лекция 13 >
Грета Березовская
Грета Березовская
Александр Медов
Александр Медов

Здравствуйте, прошел курс МБА Управление ИТ-проектами и направил документы на получение диплома почтой. Подскажите, сроки получения оного в бумажной форме?

:

Сергей Бычков
Сергей Бычков
Россия, Ленинград, ВИКИ им. Можайского, 1985
Алексей Назаренко
Алексей Назаренко
Россия