Главная | Обратная связь

Идентификационный номер инцидента

Абонент информируется о номере инцидента для его точной идентификации при последующих об­ращениях.

Статус

Статус инцидента указывает на его положение в процессе обработки инцидента. Примерами стату­сов могут быть:

· новый;

· принят;

· запланирован;

· назначен;

· активный;

· отложен;

· разрешен;

· закрыт.

Привязка (сопоставление)

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

Расследование и диагностика

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

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

Решение и восстановление

После успешного завершения анализа и разрешения инцидента сотрудник записывает решение в сис­тему. В некоторых случаях необходимо направить Запрос на Изменение (RFC) в Процесс Управления Изменениями. В наихудшем случае, если не найдено никакого решения, инцидент остается открытым.

Закрытие

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

Мониторинг хода решения и отслеживание

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

Контроль процесса

Основой контроля процесса являются отчеты для различных целевых групп. Руководитель Процес­са Управления Инцидентами является ответственным за эти отчеты, а также за составление списка рассылки и графика составления отчетов.

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

· Руководителю Процесса Управления Инцидентами отчет необходим для:

· идентификации недостающих звеньев процесса;

· идентификации нарушений исполнения соглашений об Уровне Услуг (SLA);

· отслеживания хода выполнения процесса;

· определения тенденций развития.

· Руководство Линейными ИТ-подразделениями – отчет для руководства группы поддержки; он также может быть полезен в Управлении ИТ-подразделениями. Отчет должен содержать следую­щую информацию:

· прогресс в решении инцидентов;

· время разрешения инцидентов в различных группах поддержки.

· Управления Уровнем Сервисов (Услуг) – отчет должен, прежде всего, содержать информацию о качестве предоставляемых услуг. Руководитель Процесса Управления Уровнем Услуг должен получать всю информацию, необходимую для составления Отчетов об Уровне Услуг перед заказчиками. Отчеты для заказчиков должны предоставлять информацию о том, выполняются ли соглаше­ния в отношении Уровня Сервисов (услуг) в рамках Процесса Управления Инцидентами.

· Руководителей других процессов ИТ Сервис-менеджмента – отчеты для руководителей других процессов должны быть, в первую очередь, информативными, то есть содержать всю необходимую им информацию.

Например, Процесс Управления Инцидентами на основе регистрационных запи­сей об инцидентах может предоставлять следующую информацию:

· число обнаруженных и зарегистрированных инцидентов;

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

· статус и число неразрешенных инцидентов;

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

· инциденты с разбивкой по категориям, приоритетам и группам поддержки и др.

4.5.1. Критические факторы успеха

Для успешного Управления Инцидентами необходимо следующее:

· Актуальная Конфигурационная База Данных (CMDB), помогающая оценить степень воздействия и срочность инцидентов. Эта информация также может быть получена от пользователя, но в этом случае она, возможно, будет менее полной и достаточно субъективной, что приведет к увеличе­нию времени разрешения инцидентов.

· База знаний^[69]. Например, актуальная база данных по проблемам/известным ошибкам, описываю­щая способ распознавания инцидентов, имеющиеся решения и обходные пути. Она также может включать аналогичные базы знаний от поставщиков.

· Соответствующую автоматизированную систему регистрации, отслеживания и мониторинга ин­цидентов.

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

4.5.2. Показатели эффективности^[70]

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

· общее количество инцидентов;

· среднее время разрешения инцидентов;

· среднее время разрешения инцидентов по приоритетам;

· среднее число инцидентов, разрешенных в рамках соглашений (SLA);

· процент инцидентов, разрешенных первой линией поддержки (без направления в другие группы);

· средняя стоимость поддержки на инцидент;

· число решенных инцидентов на одно рабочее место или на одного сотрудника службы Service Desk;

· инциденты, решенные без посещения пользователя (удаленно);

· число (или процент) инцидентов с первоначально некорректной классификацией;

· число (или процент) инцидентов, неправильно распределенных в группы поддержки.

Функции и роли

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