Управление Инцидентами

отрицательного воздействия (потенциальных) нарушений в предоставлении ИТ-услуг, таким образом, обеспечивая

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

Управление Инцидентами является важнейшей основой для работы других процессов ITIL, предоставляя ценную информацию об ошибках в работе ИТ-инфраструктуры.

охватывающий разные ИТ-отделы и осуществляющий эффективное управление и контроль обработки

потока инцидентов.

по предоставлению услуги, которое привело или может привести к нарушению

или снижению качества этой услуги.

В контексте библиотеки ITIL инцидентами считаются не только ошибки аппаратного или программного обеспечения, но также и Запросы па Обслуживание.

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

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

для бизнеса и для пользователя. На основе диалога с пользователем и в соответствии с положениями Соглашений об Уровнях Услуг (Service Level Agreements — SLAs) Служба Service Desk назначает приоритеты, определяющие порядок обработки инцидентов.

При эскалации инцидентов на вторую, третью или более линии поддержки, тот же приоритет должен быть соблюден, но иногда он может быть скорректирован по согласованию со Службой Service Desk.

критерии:

степень воздействия инцидента: степень отклонения от нормального уровня предоставления услуги,

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

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

например при росте количества пользователей, подвергшихся воздействию инцидента или в

критические моменты времени.

согласованное время, необходимо привлечение дополнительных знаний или полномочий. Это называется

эскалацией, которая происходит в соответствии с рассмотренными выше приоритетами и, соответственно, временем разрешения инцидента.

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

к уменьшению потерь для бизнеса;
повышение производительности работы пользователей;
независимый,

ориентированный на потребности заказчика мониторинг инцидентов;
доступность объективной информации о соответствии предоставляемых услуг согласованным договоренностям (SLA).

ИТ-систем с соглашениями (SLA);
эффективное руководство и мониторинг выполнения соглашений

(SLA) на основе достоверной информации;
эффективное использование персонала;
предотвращение потерь инцидентов и Запросов на Обслуживание или их неправильной регистрации;
повышение точности информации в Конфигурационной Базе Данных за счет ее проверки при регистрации инцидентов в привязке к Конфигурационным Единицам
повышение удовлетворенности пользователей и заказчиков.

отрицательным последствиям:
инциденты могут быть потеряны или необоснованно восприняты как

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

сообщение и создается запись об инциденте.
Классификация и начальная поддержка —

присваиваются тип, статус, степень воздействия, срочность, приоритет инцидента и т. п. Пользователю может быть предложено возможное решение, даже если оно только временное.
Если вызов касается Запроса на Обслуживание, то инициируется соответствующая процедура.
Привязка (или сопоставление — Matching) — проверяется, не является ли инцидент уже известным инцидентом или известной ошибкой, нет ли для него уже открытой проблемы, и нет ли для него известного решения или обходного пути.

инцидента с целью как можно быстрее восстановить нормальную работу.

Решение и

восстановление — если решение найдено, то работа может быть восстановлена.

Закрытие — с пользователем связываются, чтобы он подтвердил согласие с предложенным решением, после чего инцидент может быть закрыт.

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

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

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

Дополнительно необходимо тесное взаимодействие с Процессом Управления Уровнем Сервисов (Услуг) для определения требуемых приоритетов и времени разрешения инцидентов

время разрешения инцидентов по приоритетам;
среднее число инцидентов, разрешенных в

рамках соглашений (SLA);
процент инцидентов, разрешенных первой линией поддержки (без направления в другие группы);
средняя стоимость поддержки на инцидент;
число решенных инцидентов на одно рабочее место или на одного сотрудника службы Service Desk;
инциденты, решенные без посещения пользователя;
число (или процент) инцидентов с первоначально некорректной классификацией;
число (или процент) инцидентов, неправильно распределенных в группы поддержки

— если пользователи будут устранять возникающие ошибки сами или напрямую

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

воздействие на работу специалистов, которые из-за этого отрываются от своей

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

и, как следствие, предотвращение инцидентов. Управление Проблемами включает в себя

проактивные (упреждающие) и реактивные виды деятельности.

Задачей реактивных составляющих Процесса Управления Проблемами является выяснение корневой причины прошлых инцидентов и подготовка предложения по ее ликвидации.

Проактивное Управление Проблемами помогает предотвратить инциденты путем определения слабых мест в инфраструктуре и подготовки предложений по ее усовершенствованию.

значительного сокращения количества инцидентов и уменьшения рабочей нагрузки на ИТ-организацию.

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

заказчики сотрудничают с ИТ-организацией в новых сферах бизнеса.
Совершенствование знаний

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

состоянием инфраструктуры.
Наличие реалистичных целей и максимальное использование знаний и опыта

персонала, например, наличие соглашения о возможности привлечения специалистов по исследованию корневых причин проблем.
Эффективность взаимодействия Управления Проблемами и Управления Инцидентами. При распределении заданий и работ нужно учитывать конфликт интересов этих двух процессов: «тушение пожара» в рамках Управления Инцидентами и необходимость выяснения корневых причин в рамках Управления Проблемами.

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

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

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

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

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

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