Категория
Прежде всего, инцидентам присваивается категория и подкатегория, например, исходя из предполагаемого источника инцидента или соответствующей группы поддержки:
- Центральная процессинговая система – подсистема доступа, центральный сервер, приложение.
- Сеть – маршрутизаторы, сегменты, концентратор (hub), IP-адреса.
- Рабочая станция – монитор, сетевая карта, дисковод, клавиатура.
- Использование и функциональность – услуга (сервис), возможности системы, доступность, резервное копирование (back-up), документация.
- Организация и процедуры – заказ, запрос, поддержка, оповещение (коммуникации).
- Запрос на Обслуживание – запрос пользователя в Службу Service Desk на поддержку, предоставление информации, документации или оказание консультации. Это может быть выделено в отдельную процедуру или обработано таким же образом, как реальный инцидент.
Приоритет
После этого назначается приоритет, чтобы быть уверенными, что группа поддержки уделит инциденту необходимое внимание. Приоритет - это номер, определяющийся срочностью (насколько быстро это должно быть исправлено) и степенью воздействия (какой ущерб будет нанесен, если не исправить быстро).
Приоритет = Срочность х Степень воздействия.
Услуги (сервисы)
Для определения услуг, подвергшихся воздействию инцидента, может быть использован перечень существующих договоренностей (соглашений) об Уровне Услуг – SLA. Этот перечень позволит также установить время эскалации для каждой из услуг, определенных в SLA.
Группа поддержки
Если Служба Service Desk не может разрешить инцидент незамедлительно, то определяется группа поддержки, которая будет заниматься разрешением инцидента. Основой для распределения (маршрутизации) инцидентов часто является информация о категориях. При определении категорий может потребоваться рассмотрение структуры групп поддержки. Правильное распределение инцидентов имеет существенное значение для эффективности Процесса Управления Инцидентами. Поэтому одним из ключевых показателей эффективности[68](KPI) Процесса Управления Инцидентами может быть число неправильно распределенных обращений.
Сроки решения
С учетом приоритета и соглашения SLA пользователь информируется о максимальном расчетном времени разрешения инцидента. Эти сроки также фиксируются в системе.
Идентификационный номер инцидента
Абонент информируется о номере инцидента для его точной идентификации при последующих обращениях.
Статус
Статус инцидента указывает на его положение в процессе обработки инцидента. Примерами статусов могут быть:
- новый;
- принят;
- запланирован;
- назначен;
- активный;
- отложен;
- разрешен;
- закрыт.
После классификации проводится проверка, не возникал ли аналогичный инцидент ранее и нет ли готового решения или обходного пути. Если инцидент имеет те же признаки, что и открытая проблема или известная ошибка, то может быть установлена связь с ними.
Служба Service Desk или группа поддержки направляет инциденты, не имеющие готового решения или выходящие за пределы компетенции работающего с ним сотрудника, группе поддержки следующего уровня с большим опытом и знаниями. Эта группа исследует и разрешает инцидент или направляет его группе поддержки очередного уровня.
В процессе разрешения инцидента различные специалисты могут обновлять регистрационную запись о нем, изменяя текущий статус, информацию о выполненных действиях, пересматривая классификацию и обновляя время и код работавшего сотрудника.
После успешного завершения анализа и разрешения инцидента сотрудник записывает решение в систему. В некоторых случаях необходимо направить Запрос на Изменение (RFC) в Процесс Управления Изменениями. В наихудшем случае, если не найдено никакого решения, инцидент остается открытым.
После реализации решения, удовлетворяющего пользователя, группа поддержки направляет инцидент обратно в Службу Service Desk. Эта служба связывается с сотрудником, сообщившим об инциденте, с целью получения подтверждения об успешном решении вопроса. Если он это подтверждает, то инцидент может быть закрыт; в противном случае процесс возобновляется на соответствующем уровне. При закрытии инцидента необходимо обновить данные об окончательной категории, приоритете, сервисах (услугах), подвергшихся воздействию инцидента и Конфигурационной Единице (CI), вызвавшей сбой.
В большинстве случаев ответственной за мониторинг хода решения является Служба Service Desk, как "владелец" всех инцидентов. Эта служба должна также информировать пользователя о состоянии инцидента. Обратная связь с пользователем может быть уместной после изменения статуса, например, направлении инцидента на следующую линию поддержки, изменении расчетного времени решения, эскалации и т. д. Во время мониторинга возможна функциональная эскалация к другим группам поддержки или иерархическая эскалация для принятия руководящих решений.
Основой контроля процесса являются отчеты для различных целевых групп. Руководитель Процесса Управления Инцидентами является ответственным за эти отчеты, а также за составление списка рассылки и графика составления отчетов. Отчеты могут включать специализированную информацию для следующих функциональных подразделений:
- Руководителю Процесса Управления Инцидентами отчет необходим для:
- идентификации недостающих звеньев процесса;
- идентификации нарушений исполнения соглашений об Уровне Услуг (SLA);
- отслеживания хода выполнения процесса;
- определения тенденций развития.
- Руководство Линейными ИТ-подразделениями – отчет для руководства группы поддержки; он также может быть полезен в Управлении ИТ-подразделениями. Отчет должен содержать следующую информацию:
- прогресс в решении инцидентов;
- время разрешения инцидентов в различных группах поддержки.
- Управления Уровнем Сервисов (Услуг) – отчет должен, прежде всего, содержать информацию о качестве предоставляемых услуг. Руководитель Процесса Управления Уровнем Услуг должен получать всю информацию, необходимую для составления Отчетов об Уровне Услуг перед заказчиками. Отчеты для заказчиков должны предоставлять информацию о том, выполняются ли соглашения в отношении Уровня Сервисов (услуг) в рамках Процесса Управления Инцидентами.
- Руководителей других процессов ИТ Сервис-менеджмента – отчеты для руководителей других процессов должны быть, в первую очередь, информативными, то есть содержать всю необходимую им информацию. Например, Процесс Управления Инцидентами на основе регистрационных записей об инцидентах может предоставлять следующую информацию:
- число обнаруженных и зарегистрированных инцидентов;
- число разрешенных инцидентов, с разделением по времени разрешения;
- статус и число неразрешенных инцидентов;
- инциденты с разбивкой по периодам возникновения, группам заказчика, группам поддержки и временем разрешения в соответствии с соглашением (SLA);
- инциденты с разбивкой по категориям, приоритетам и группам поддержки и др.
Для успешного Управления Инцидентами необходимо следующее:
- Актуальная Конфигурационная База Данных (CMDB), помогающая оценить степень воздействия и срочность инцидентов. Эта информация также может быть получена от пользователя, но в этом случае она, возможно, будет менее полной и достаточно субъективной, что приведет к увеличению времени разрешения инцидентов.
- База знаний[69]. Например, актуальная база данных по проблемам/известным ошибкам, описывающая способ распознавания инцидентов, имеющиеся решения и обходные пути. Она также может включать аналогичные базы знаний от поставщиков.
- Соответствующую автоматизированную систему регистрации, отслеживания и мониторинга инцидентов.
Дополнительно необходимо тесное взаимодействие с Процессом Управления Уровнем Сервисов (Услуг) для определения требуемых приоритетов и времени разрешения инцидентов.
Для оценки производительности процесса необходимо четко определить контрольные параметры и измеряемые оценки, часто называемые показателями эффективности. Отчет по этим показателям производится регулярно, например раз в неделю, чтобы получить картину изменений, по которой можно было бы определить тенденции. Примерами таких параметров являются:
- общее количество инцидентов;
- среднее время разрешения инцидентов;
- среднее время разрешения инцидентов по приоритетам;
- среднее число инцидентов, разрешенных в рамках соглашений (SLA);
- процент инцидентов, разрешенных первой линией поддержки (без направления в другие группы);
- средняя стоимость поддержки на инцидент;
- число решенных инцидентов на одно рабочее место или на одного сотрудника службы Service Desk;
- инциденты, решенные без посещения пользователя (удаленно);
- число (или процент) инцидентов с первоначально некорректной классификацией;
- число (или процент) инцидентов, неправильно распределенных в группы поддержки.
Реализация процессов проходит в горизонтальной плоскости через иерархическую структуру организации. Это возможно только при четком определении ответственности и полномочий, связанных с реализацией процессов. Для повышения гибкости может быть использован ролевой подход (т.е. определение ролей). В небольших организациях или в целях снижения общих расходов возможно комбинирование ролей, например, совмещение ролей Руководителя Процессов Управления Изменениями и Управления Конфигурациями.