Приоритет определяется на основе срочности и степени воздействия. Для каждого приоритета определяется количество специалистов и объем ресурсов, которые могут быть направлены на разрешение инцидента. Порядок обработки инцидентов одинакового приоритета может быть определен в соответствии с усилиями, необходимыми для разрешения инцидента. Например, легко разрешаемый инцидент может быть обработан перед инцидентом, требующим больших усилий.
При Управлении Инцидентами существуют способы снижения степени воздействия и срочности, такие, как переключение системы на резервную конфигурацию, перенаправление очереди печати и др.
Рис. 4.2. Определение степени воздействия, срочности и приоритета
Степень воздействия и срочность также могут сами меняться во времени, например, при росте количества пользователей, подвергшихся воздействию инцидента или в критические моменты времени.
Степень воздействия и срочность могут быть объединены в матрицу, как показано в табл. 4.1.
Таблица 4.1. Пример системы кодирования приоритетов
Эскалация
Если инцидент не может быть разрешен первой линией поддержки за согласованное время, необходимо привлечение дополнительных знаний или полномочий. Это называется эскалацией, которая происходит в соответствии с рассмотренными выше приоритетами и, соответственно, временем разрешения инцидента.
Различают функциональную и иерархическую эскалацию:
Функциональная эскалация (горизонтальная) означает привлечение большего количества специалистов или предоставление дополнительных прав доступа для разрешения инцидента; при этом, возможно, происходит выход за пределы одного структурного ИТ-подразделения.
Иерархическая эскалация (вертикальная) означает вертикальный переход (на более высокий уровень) в рамках организации, так как для разрешения инцидента недостаточно организационных полномочий (уровня власти) или ресурсов.
Задачей Руководителя Процесса Управления Инцидентами является заблаговременное резервирование возможностей для функциональной эскалации в рамках линейных подразделений организации так, чтобы разрешение инцидентов не требовало регулярной иерархической эскалации. В любом случае, линейные подразделения должны предоставить для этого процесса достаточное количество ресурсов.
Первая, вторая и n-линия поддержки
Выше была изложена маршрутизация инцидента, или функциональная эскалация. Маршрутизация определяется требуемым уровнем знаний, полномочий и срочностью. Первой линией поддержки (называемой также поддержкой 1-го уровня) обычно является Служба Service Desk, второй линией подразделений, осуществляющие Управление ИТ-инфраструктурой, третья отделы разработки и архитектуры программного обеспечения, и четвертая поставщики. Чем меньше организация, тем меньше в ней уровней эскалации. В больших организациях Руководитель Процесса Управления Инцидентами может назначить Координаторов инцидентов в соответствующих подразделениях для поддержки своей деятельности. Например, координаторы могут играть роль интерфейса между процессной деятельностью и линейными организационными подразделениями. Каждый из них координирует деятельность собственных
групп поддержки. Процедура эскалации графически представлена на рис. 4.3.
Рис. 4.3. Эскалация инцидента (источник: OGC)
4.2. Цель
4.2.1. Преимущества использования процесса
Для бизнеса в целом:
- своевременное разрешение инцидентов, ведущее к уменьшению потерь для бизнеса;
- повышение производительности работы пользователей;
- независимый, ориентированный на потребности заказчика мониторинг инцидентов;
- доступность объективной информации о соответствии предоставляемых услуг согласованным договоренностям (SLA).
Для ИТ-организации:
- улучшенный мониторинг, позволяющий проводить точное сопоставление уровня производительности ИТ-систем с соглашениями (SLA);
- эффективное руководство и мониторинг выполнения соглашений (SLA) на основе достоверной информации;
- эффективное использование персонала;
- предотвращение потерь инцидентов и Запросов на Обслуживание или их неправильной регистрации;
- повышение точности информации в Конфигурационной Базе Данных (Configuration Management Database CMDB) за счет ее проверки при регистрации инцидентов в привязке к Конфигурационным Единицам (Configuration Item CI);
- повышение удовлетворенности пользователей и заказчиков.
Отказ от использования Процесса Управления Инцидентами может привести к следующим отрицательным последствиям:
инциденты могут быть потеряны или, наоборот, необоснованно восприняты как чрезвычайно серьезные из-за отсутствия ответственных за мониторинг и эскалацию, что может привести к снижению общего уровня обслуживания;
пользователи могут перенаправляться к одним и тем же специалистам «по кругу» без успешного разрешения инцидента;
специалисты могут постоянно отрываться от работы телефонными звонками пользователей, из-за чего им становится трудно эффективно выполнять свою работу;
могут возникать ситуации, когда несколько человек будут работать над одним и тем же инцидентом, непродуктивно теряя время, и примут противоречивые решения;