что такое матрица эскалации
Что такое матрица эскалации
Наиболее широко используемой структурной моделью бизнес-процессов в отрасли является модель eTOM (The enhanced Telecom Operations Map). Отличительной чертой еТОМ является её гибкость, возможность интеграции с разными методологиями, например ITIL (Information Technology Infrastructure Library) [1]. Центральными компонентами ITIL являются этапы Предоставление услуг и Поддержка услуг.
Если инцидент не может быть разрешен первой линией поддержки за согласованное время, необходимо привлечение механизма эскалаций. Механизм эскалации помогает своевременно разрешить инцидент путем увеличения возможностей персонала, уровня усилий и приоритета, нацеленных на решение этого инцидента. Для этого используется матрица уровней важности, основанная на степени влияния на бизнес, временных рамках разрешения инцидента и интервалах времени, в которые инцидент должен быть передан в более продвинутую группу (табл. 1).
Для обеспечения предоставления инциденту соответствующего приоритета и выделения необходимых ресурсов до того, как будут перекрыты временные рамки его разрешения, применяют иерархическую эскалацию, вовлекающую в процесс руководство.
Таблица 1. Матрица эскалаций
Уровень
Инцидента
Описание
Срок
решения
Первая
линия
поддержки
Вторая
линия
поддержки
Третья
линия
поддержки
Первый менеджер
Свыше 50 пользователей сообщили о прерывании сервиса
Управление по исключениям или эскалация в проектном менеджменте
Известная всем «простая истина» гласит, что менеджер проекта всецело отвечает за достижение целей проекта (об этом говорит и PMBoK, и стандарты ISO). При этом в зависимости от масштаба и бюджета проекта различные группы навыков руководителей проектов выходят на разные уровни: маленький проект чаще всего предполагает сильные технические скиллы, крупные проекты – лидер ские и стратегические навыки взаимодействия со стейкхолдерами и заинтересованными лицами.
Так как ни один проект невозможен без людей, то роль менеджера проекта, заключающаяся в интеграции и координации работ различных специалистов и заинтересованных лиц, при зрелом менеджменте всегда выходит на первый план (даже при прогнозировании). Управление заинтересованными сторонами (даже неблагоприятно влияющих на проект) – очень яркая и многогранная работа. А там, где есть люди, там всегда присутствуют конфликты: ресурсные, межличностные, приоритетные, административные и т.д.
В странах со зрелым управленческим менеджментом давно применяются процессы управления по исключениям. Самое явное определение таким процессам дает стандарт PRINCE2: Руководство проектами следует осуществлять путем определения обязанностей и ответственности на каждом уровне проекта при помощи строгого делегирования полномочий. Допустимые отклонения должны быть определены для каждого уровня плана проекта.
К сожалению, в российском проектном менеджменте (даже в больших корпорациях) до сих пор не развивается применение принципа управления по исключениям. Многие большие начальники давно изучили техники и методики делегирования, но в обратную сторону «вскрытие» проблемных зон проекта до верхнего уровня заинтересованных сторон работает очень плохо. Другими словами, очень многие менеджеры проектов боятся эскалировать проблемы «наверх» и выносить лишний раз вопросы на уровень спонсоров и кураторов проекта. Возможно, в российской действительности это отчасти связано с моральными устоями, что жаловаться нехорошо, или с боязнью показаться некомпетентным.
Изначально слово «эскалация» произошло от латинского слова scala «лестница», в русский язык пришло из английского слова escalation «расширение, распространение». В современном русском языке чаще всего слово эскалация понимается больше с политическим или военным смыслом в части наращивания силы, расширение или распространение конфликта. Впрочем, в проектном менеджменте эскалация, при правильном понимании и использовании, не несет столь негативной окраски, а, наоборот, является полезным инструментом для достижения целей проекта и удовлетворенности заказчика. Нужно всегда помнить, что нерешенные вовремя проблемы повышают риски неуспеха проекта, вызывают нарушения сроков и бюджетов, снижают качество продукта проекта.
Эскалация вопросов и проблем в проекте (ресурсных, межличностных, административных) не будет вызывать нездоровый негатив, если всегда пользоваться принципами честности и открытости. Шаги, которыми пользуюсь я в своей практике (и они правда приносят успех):
Выявите заинтересованность или ее отсутствие в решении проблемы путем диалога. Другими словами – попробуйте просто спросить почему нет (почему не решается проблема или у кого отсутствует интерес к ее решению).
Открыто оповестите противоположную сторону о необходимости/потребности в эскалации, тем самым вы избавитесь от подковёрных игр и наращивания негатива в проекте после эскалации.
Подготовьте аргументированную базу для эскалации с учетом планов проекта, управления рисками, допущений и ограничений. Здесь хорошим подспорьем будут ранее фиксированные договоренности, статус-встречи и планы.
Эскалируйте на вышестоящие уровни, это страшно только в первый раз. В рамках договорных отношений Заказчик – Исполнитель эскалацию на уровни выше лучше переносить в разряд официальных писем (для юридической подстраховки от «плохих людей» и штрафных санкций).
В качестве личного совета могу добавить, что не надо забывать об открытости к сотрудничеству даже в момент эскалации, ведь любой конфликт – это точка для роста, и в проектной практике нужно использовать его конструктивные функции. Проектная эскалация не пересекается (и не должна пересекаться) с личными отношениями, и ни коем образом не является жалобой. В момент эскалации задача менеджера проектов – приведение вышестоящих уровней, принимающих решение, к принятию качественного и полезного решения для всех, а главное для проекта. Эффективна только открытая и честная эскалация.
Управление событиями и инцидентами в рамках Эксплуатации услуг
12.2. Управление инцидентами
Ценность Управления инцидентами для бизнеса более очевидна, чем у других процессов этапа Внедрения. Часто именно этот процесс является основой для формирования обоснования бизнесу о необходимости остальных процессов этапа Внедрения. В частности, Управление инцидентами помогает бизнесу тем, что:
ITIL вводит также понятие Модель инцидентов, которая включает в себя:
Таким образом, Модель инцидентов описывает последовательность действий при возникновении определенного типа инцидентов. Использование моделей инцидентов позволяет стандартизовать процесс Управления инцидентами и ускорить его. Этот подход применим в отношении часто возникающих «стандартных» инцидентов. «Нестандартные» случаи обрабатываются отдельно, например, инциденты, связанные с информационной безопасностью. В отдельную категорию выделяются «значительные инциденты», которые должны разрешаться максимально быстро. Значительный инцидент (Major Incident ) наивысшая категория влияния для инцидента. Значительный инцидент означает значительные потери для бизнеса[1]. То, какие инциденты будут считаться значительными, каждая организация решает индивидуально.
На рис. 12.2 схематически отображены основные деятельности в рамках Управления инцидентами.
Рассмотрим основные этапы, изображенные на рис. 12.2.
Для того чтобы разрешить инцидент, его необходимо сначала обнаружить, то есть идентифицировать. С точки зрения непрерывности бизнеса неприемлемо ждать обращений пользователей или технического персонала в сервис-деск. Все ключевые компоненты должны контролироваться, чтобы своевременно обнаруживать сбои или возможности их возникновения.
Запись об инциденте должна включать:
Нет стандартных методов для категорирования инцидентов, каждая организация сама определяет, какие категории будет использовать.
Другие факторы, которые можно использовать для оценки влияния:
В таблицах 12.1 и 12.2 приведен пример матриц для определения приоритета инцидента и времени, в течение которого его необходимо разрешить.
| Влияние | ||||
|---|---|---|---|---|
| Высокое | Среднее | Низкое | ||
| Срочность | Высокая | 1 | 2 | 3 |
| Средняя | 2 | 3 | 4 | |
| Низкая | 3 | 4 | 5 | |
| Приоритет | Характеристика | Время разрешения |
|---|---|---|
| 1 | Критичный | 1 час |
| 2 | Высокий | 8 часов |
| 3 | Средний | 24 часа |
| 4 | Низкий | 48 часов |
| 5 | Планируемый | Запланировать |
Для персонала поддержки необходимо разработать четкие инструкции определения приоритета инцидента на основе срочности и влияния на бизнес. Необходимо отметить, что приоритет инцидента может меняться в зависимости от изменения окружающих условий и требований бизнеса.
Далее следует этап начальной диагностики. В первую очередь он относится к инцидентам, поступившим в сервис-деск. Специалист службы сервис-деск должен попытаться найти причину, вызвавшую инцидент, понять, что именно работает некорректно и выявить максимальное количество характеристик инцидента во время связи с пользователем, например, по телефону. Другими словами, специалист должен попытаться решить инцидент и закрыть его. Если это невозможно, он сообщает пользователю идентификационный номер инцидента.
Если сервис-деск не может разрешить инцидент или сроки первой ступени разрешения инцидентов истекли, инцидент должен быть немедленно передан дальше.
Сервис-деск, в свою очередь проверяет, что все действия, необходимые для разрешения инцидента, выполнены, пользователи удовлетворены и согласны закрыть инцидент. Это включает в себя следующее:
В некоторых случаях инцидент может быть повторно открыт даже после формального закрытия. Правильным будет заранее определить правила о том, как, когда и при каких условиях инцидент может быть повторно открыт. Это используется, в частности, когда в один и тот же день возникают одинаковые инциденты. Для нового инцидента, тем не менее, необходимо сформировать новую запись со ссылкой на предыдущий инцидент. Запись о предыдущем инциденте может быть использована для разрешения нового.
Метриками эффективности процесса Управления инцидентами могут быть:
Для эффективного Управления инцидентами необходимо обеспечить следующее:
Основные риски для процесса Управления инцидентами:
Глава 4. Управление Инцидентами
Задача Процесса Управления Инцидентами является реактивной – уменьшение или исключение отрицательного воздействия (потенциальных) нарушений в предоставлении ИТ-услуг, таким образом обеспечивая наиболее быстрое восстановление работы пользователей. Для выполнения этой задачи производится регистрация, классификация и назначение инцидентов соответствующим группам специалистов, мониторинг хода работ по разрешению инцидентов, решение инцидентов и их закрытие. Так как это требует тесного взаимодействия с пользователями, фокусной точной Процесса управления Инцидентами обычно является функция Service Desk[58], которая играет роль центра контактов пользователей с «внутренними» коллективами технических служб. Управление Инцидентами является важнейшей основой для работы других процессов ITIL, предоставляя ценную информацию об ошибках в работе ИТ-инфраструктуры.
На рис. 4.1 показан схематичный пример Управления Инцидентами как горизонтальный процесс, охватывающий разные ИТ-отделы и осуществляющий эффективное управление и контроль обработки инцидентов.
Рис. 4.1. Позиционирование Процесса Управления Инцидентами относительно других функций (подразделений) ИТ-организации
Библиотека ITIL использует широкое определение термина «инцидент», поэтому почти все обращения пользователей могут регистрироваться и отслеживаться как инциденты.
В книге «Поддержка услуг» библиотеки ITIL дается следующее определение:
Инцидент[59] — это любое событие, не являющееся частью стандартных операций по предоставлению услуги, которое привело или может привести к нарушению или снижению качества этой услуги.
В контексте библиотеки ITIL инцидентами считаются не только ошибки аппаратного или программного обеспечения, но также и Запросы на Обслуживание.
Запрос на обслуживание[60] — это Запрос от Пользователя на поддержку, предоставление информации, консультации или документации, не являющийся сбоем ИТ-инфраструктуры.
Примеры Запросов на Обслуживание:
• вопрос о функционировании ИТ-систем или запрос о предоставлении какой-либо информации;
• запрос о состоянии (статусе) чего-либо в ИТ-инфраструктуре;
• запрос о замене пароля;
• запросы на выполнение пакетных заданий, восстановление или авторизацию пароля;
• получение информации из базы данных.
Для того чтобы можно было отличить «настоящие инциденты» от «инцидентов-Запросов на Обслуживание», рекомендуется присваивать Запросам на Обслуживание специальную категорию. Важно также отметить, что Запрос на Обслуживание это не то же самое, что Запрос на Изменение:
Запрос на Изменение (RFC)[61] – это экранная или бумажная форма, используемая для записи детальной информации о предлагаемом Запросе на Изменение какой-либо Конфигурационной Единицы[62] (CI) в ИТ-инфраструктуре или процедуры или какого-либо иного объекта ИТ-инфраструктуры.
Запрос на Изменение RFC считается завершенным после проведения изменения в инфраструктуре, например, замены зарегистрированных компонентов, инсталляции ПК и т. д. Это не инциденты, а изменения.
Степень воздействия[63], срочность[64] и приоритет[65]
При одновременной обработке нескольких инцидентов необходимо расставлять приоритеты. Обоснованием для назначения приоритета служит уровень важности ошибки для бизнеса и для пользователя. На основе диалога с пользователем и в соответствии с положениями Соглашений об Уровнях Услуг (Service Level Agreements – SLAs) Служба Service Desk назначает приоритеты, определяющие порядок обработки инцидентов. При эскалации инцидентов на вторую, третью или более линии поддержки, тот же приоритет должен быть соблюден, но иногда он может быть скорректирован по согласованию со Службой Service Desk.
Конечно, каждый пользователь будет считать, что его инцидент имеет наивысший приоритет, но мнения пользователей часто бывают субъективными. Для объективной оценки приоритета в диалоге с пользователем употребляются следующие критерии:
• степень воздействия инцидента: степень отклонения от нормального уровня предоставления услуги, выражающаяся в количестве пользователей или бизнес-процессов, подвергшихся воздействию инцидента;
• срочность инцидента: приемлемая задержка разрешения инцидента для пользователя или бизнес-процесса.
Приоритет определяется на основе срочности и степени воздействия. Для каждого приоритета определяется количество специалистов и объем ресурсов, которые могут быть направлены на разрешение инцидента. Порядок обработки инцидентов одинакового приоритета может быть определен в соответствии с усилиями, необходимыми для разрешения инцидента. Например, легко разрешаемый инцидент может быть обработан перед инцидентом, требующим больших усилий.
При Управлении Инцидентами существуют способы снижения степени воздействия и срочности, такие, как переключение системы на резервную конфигурацию, перенаправление очереди печати и др.
Рис. 4.2. Определение степени воздействия, срочности и приоритета
Степень воздействия и срочность также могут сами меняться во времени, например, при росте количества пользователей, подвергшихся воздействию инцидента или в критические моменты времени.
Степень воздействия и срочность могут быть объединены в матрицу, как показано в табл. 4.1.
Таблица 4.1. Пример системы кодирования приоритетов
Если инцидент не может быть разрешен первой линией поддержки за согласованное время, необходимо привлечение дополнительных знаний или полномочий. Это называется эскалацией, которая происходит в соответствии с рассмотренными выше приоритетами и, соответственно, временем разрешения инцидента.
Различают функциональную и иерархическую эскалацию:
• Функциональная эскалация (горизонтальная) – означает привлечение большего количества специалистов или предоставление дополнительных прав доступа для разрешения инцидента; при этом, возможно, происходит выход за пределы одного структурного ИТ-подразделения.
• Иерархическая эскалация (вертикальная) – означает вертикальный переход (на более высокий уровень) в рамках организации, так как для разрешения инцидента недостаточно организационных полномочий (уровня власти) или ресурсов.
Задачей Руководителя Процесса Управления Инцидентами является заблаговременное резервирование возможностей для функциональной эскалации в рамках линейных подразделений организации так, чтобы разрешение инцидентов не требовало регулярной иерархической эскалации. В любом случае, линейные подразделения должны предоставить для этого процесса достаточное количество ресурсов.
Первая, вторая и n-линия поддержки
Выше была изложена маршрутизация инцидента, или функциональная эскалация. Маршрутизация определяется требуемым уровнем знаний, полномочий и срочностью. Первой линией поддержки (называемой также поддержкой 1-го уровня) обычно является Служба Service Desk, второй линией – подразделений, осуществляющие Управление ИТ-инфраструктурой, третья – отделы разработки и архитектуры программного обеспечения, и четвертая – поставщики. Чем меньше организация, тем меньше в ней уровней эскалации. В больших организациях Руководитель Процесса Управления Инцидентами может назначить Координаторов инцидентов в соответствующих подразделениях для поддержки своей деятельности. Например, координаторы могут играть роль интерфейса между процессной деятельностью и линейными организационными подразделениями. Каждый из них координирует деятельность собственных групп поддержки. Процедура эскалации графически представлена на рис. 4.3.
Рис. 4.3. Эскалация инцидента (источник: OGC)
4.2. Цель
Целью Процесса Управления Инцидентами является скорейшее восстановление нормального Уровня Услуг, определенного в Соглашении об Уровне Услуг (Service Level Agreement – SLA), с минимальными возможными потерями для бизнес-деятельности организации и пользователей. Кроме того, Процесс Управления Инцидентами должен вести точную регистрацию инцидентов для оценки и совершенствования процесса и предоставления необходимой информации для других процессов.
4.2.1. Преимущества использования процесса
• Для бизнеса в целом:
— своевременное разрешение инцидентов, ведущее к уменьшению потерь для бизнеса;
— повышение производительности работы пользователей;
— независимый, ориентированный на потребности заказчика мониторинг инцидентов;
— доступность объективной информации о соответствии предоставляемых услуг согласованным договоренностям (SLA).
— улучшенный мониторинг, позволяющий проводить точное сопоставление уровня производительности ИТ-систем с соглашениями (SLA);
— эффективное руководство и мониторинг выполнения соглашений (SLA) на основе достоверной информации;
— эффективное использование персонала;
— предотвращение потерь инцидентов и Запросов на Обслуживание или их неправильной регистрации;
— повышение точности информации в Конфигурационной Базе Данных (Configuration Management Database – CMDB) за счет ее проверки при регистрации инцидентов в привязке к Конфигурационным Единицам (Configuration Item – CI);
— повышение удовлетворенности пользователей и заказчиков.
Отказ от использования Процесса Управления Инцидентами может привести к следующим отрицательным последствиям:
• инциденты могут быть потеряны или, наоборот, необоснованно восприняты как чрезвычайно серьезные из-за отсутствия ответственных за мониторинг и эскалацию, что может привести к снижению общего уровня обслуживания;
• пользователи могут перенаправляться к одним и тем же специалистам «по кругу» без успешного разрешения инцидента;
• специалисты могут постоянно отрываться от работы телефонными звонками пользователей, из-за чего им становится трудно эффективно выполнять свою работу;
• могут возникать ситуации, когда несколько человек будут работать над одним и тем же инцидентом, непродуктивно теряя время, и примут противоречивые решения;
• может ощущаться недостаток информации о пользователях и предоставляемых услугах, необходимой для принятия руководящих решений;
• из-за указанных выше возможных проблем затраты компании и ИТ-организации на поддержку услуг будут выше, чем реально требуется.
4.3. Процесс
На рис. 4.4 показаны входы и выходы процесса, а также виды деятельности, которые охватывает этот процесс.
Рис. 4.4. Положение Процесса Управления Инцидентами
4.3.1. Входы процесса
Инциденты могут возникнуть в любой части инфраструктуры. Часто о них сообщают пользователи, но возможно их обнаружение и сотрудниками других отделов, а также автоматическими системами управления, настроенными на регистрацию событий в приложениях и технической инфраструктуре.
4.3.2. Управление конфигурациями
4.3.3. Управление Проблемами
Эффективное Управление Проблемами требует качественной регистрации инцидентов, что значительно облегчит поиск корневых причин. С другой стороны, Управление Проблемами помогает Процессу Управления Инцидентами, предоставляя информацию о проблемах, известных ошибках, обходных решениях и быстрых исправлениях[66].
4.3.4. Управление Изменениями
Инциденты могут быть решены путем внесения изменений, например, заменой монитора. Управление Изменениями предоставляет Процессу Управления Инцидентами информацию о запланированных изменениях и их статусах. Кроме того, изменения могут вызвать инциденты, если изменения произведены неправильно или содержат ошибки. Процесс Управления Изменениями получает информацию о них из Процесса Управления Инцидентами.
4.3.5. Управление Уровнем Услуг
Управление Уровнем Услуг контролирует выполнение договоренностей (соглашений – SLA) с заказчиком о предоставляемой ему поддержке. Сотрудники, участвующие в Управлении Инцидентами должны хорошо знать эти соглашения, чтобы использовать необходимую информацию при контактах с пользователями. Кроме того, регистрационные данные об инцидентах требуются при составлении отчетов для проверки выполнения согласованного Уровня Услуг.
4.3.6. Управление Доступностью
Для определения показателей доступности услуг Процесс Управления Доступностью использует регистрационные данные об инцидентах и данные мониторинга статуса, предоставляемые Процессом Управления Конфигурациями. Аналогично Конфигурационной Единице (CI) в Конфигурационной Базе Данных (CMDB), сервису (услуге) может быть также назначен статус «не работает»[67]. Это может быть использовано для проверки действительных показателей доступности услуги и времени реагирования поставщика. При осуществлении такой проверки необходима фиксация времени действий, произошедших в процессе обработки инцидента, от момента обнаружения и до закрытия.
4.3.7. Управление мощностями
Процесс Управления Мощностями получает информацию об инцидентах, связанных с функционированием самих ИТ-систем, например, инцидентах, произошедших в связи с недостатком дискового пространства или медленной скоростью реакции и т.д. В свою очередь, информация об этих инцидентах может поступать в Процесс Управления Инцидентами от системного администратора или от самой системы на основе мониторинга своего состояния.
Ни рис. 4.5. показаны этапы процесса:
Рис. 4.5. Процесс Управления Инцидентами
• Прием и регистрация инцидента (Acceptance and Recording) – принимается сообщение и создается запись об инциденте.
• Классификация и начальная поддержка (Classification and Initial Support) – присваиваются тип, статус, степень воздействия, срочность, приоритет инцидента, SLA и т.п. Пользователю может быть предложено возможное решение, даже если оно только временное.
• Если вызов касается Запроса на Обслуживание (Service Request), то инициируется соответствующая процедура.
• Привязка (или сопоставление – Matching) – проверяется, не является ли инцидент уже известным инцидентом или известной ошибкой, нет ли для него уже открытой проблемы, и нет ли для него известного решения или обходного пути.
• Расследование и диагностика (Investigation and Diagnosis) – при отсутствии известного решения производится исследование инцидента с целью как можно быстрее восстановить нормальную работу.
• Решение и восстановление (Resolution and Recovery) – если решение найдено, то работа может быть восстановлена.
• Закрытие (Closure) – с пользователем связываются, чтобы он подтвердил согласие с предложенным решением, после чего инцидент может быть закрыт.
• Мониторинг хода работ и отслеживание (Progress monitoring and Tracking) – весь цикл обработки инцидента контролируется, и если инцидент не может быть разрешен вовремя, производится эскалация.
4.4. Виды деятельности
4.4.1. Прием и регистрация
В большинстве случаев инциденты регистрируются Службой Service Desk, куда поступают сообщения о них. Регистрация всех инцидентов должна производиться немедленно после поступления сообщения по следующим причинам:
• трудно произвести точную регистрацию информации об инциденте, если это не сделано сразу;
• мониторинг хода работ по решению инцидента возможен, только если инцидент зарегистрирован;
• зарегистрированные инциденты помогают при диагностике новых инцидентов;
• Управление Проблемами может использовать зарегистрированные инциденты при работе над поиском корневых причин;
• легче определить степень воздействия, если все сообщения (звонки) зарегистрированы;
• без регистрации инцидентов невозможно контролировать исполнение договоренностей (SLA);
• немедленная регистрация инцидентов предотвращает ситуации, когда или несколько человек работают над одним звонком, или никто ничего не делает для разрешения инцидента.
Место обнаружения инцидента определяется по признаку, откуда пришло сообщение о нем. Инциденты могут быть обнаружены следующим образом:
• Обнаружен пользователем: он докладывает об инциденте в Службу Service Desk.
• Обнаружен системой: при обнаружении события в приложении или технической инфраструктуре, например, при превышении критического порога, событие регистрируется как инцидент в системе регистрации инцидентов и, при необходимости, направляется в группу поддержки.
• Обнаружен сотрудником Службы Service Desk: сотрудник производит регистрацию инцидента.
• Обнаружен кем-либо в другом подразделении ИТ: этот специалист регистрирует инцидент в системе регистрации инцидентов или докладывает о нем в Службу Service Desk.
Необходимо избегать двойной регистрации одного инцидента. Поэтому при регистрации инцидента следует проверить, нет ли аналогичных открытых инцидентов:
• Если есть (и они касаются того же инцидента), информация об инциденте обновляется или же инцидент регистрируется отдельно и устанавливается связь (привязка) к главному инциденту; при необходимости изменяется степень воздействия и приоритет, и добавляется информация о новом пользователе.
• Если нет (отличается от открытого инцидента), производится регистрация нового инцидента.
В обоих случаях продолжение процесса одинаково, хотя в первом случае последующие действия гораздо проще.
При регистрации инцидента производятся следующие действия:
• Назначение номера инцидента: в большинстве случаев система автоматически назначает новый (уникальный) номер инцидента. Часто этот номер сообщается пользователю, чтобы он мог ссылаться на него при дальнейших контактах.
• Запись базовой диагностической информации: время, признаки (симптомы), пользователь, сотрудник, принявший вопрос в обработку, место произошедшего инцидента и информация о затронутой услуге и/или технических средствах.
• Запись дополнительной информации об инциденте: добавляется информация, например, из скрипта (script) или процедуры опроса или из Конфигурационной Базы Данных – CMDB (обычно на основе взаимоотношений Конфигурационных Единиц, определенных в CMDB).
• Объявление сигнала тревоги: если происходит инцидент, имеющий высокую степень воздействия, например, сбой важного сервера, производится предупреждение других пользователей и руководства.
Классификация инцидентов направлена на определение его категории для облегчения мониторинга и составления отчетов. Желательно, чтобы опции классификации были как можно шире, но при этом требуется более высокий уровень ответственности персонала. Иногда пытаются объединить в одном перечне несколько аспектов классификации, таких, как тип, группа поддержки и источник. Это часто вносит путаницу. Лучше использовать несколько коротких перечней. В данном разделе рассматриваются вопросы, относящиеся к классификации.
Прежде всего, инцидентам присваивается категория и подкатегория, например, исходя из предполагаемого источника инцидента или соответствующей группы поддержки:
• Центральная процессинговая система – подсистема доступа, центральный сервер, приложение.
• Сеть – маршрутизаторы, сегменты, концентратор (hub), IP-адреса.
• Рабочая станция – монитор, сетевая карта, дисковод, клавиатура.
• Использование и функциональность – услуга (сервис), возможности системы, доступность, резервное копирование (back-up), документация.
• Организация и процедуры – заказ, запрос, поддержка, оповещение (коммуникации).
• Запрос на Обслуживание – запрос пользователя в Службу Service Desk на поддержку, предоставление информации, документации или оказание консультации. Это может быть выделено в отдельную процедуру или обработано таким же образом, как реальный инцидент.
Приоритет = Срочность х Степень воздействия.
Для определения услуг, подвергшихся воздействию инцидента, может быть использован перечень существующих договоренностей (соглашений) об Уровне Услуг – SLA. Этот перечень позволит также установить время эскалации для каждой из услуг, определенных в SLA.
Если Служба Service Desk не может разрешить инцидент незамедлительно, то определяется группа поддержки, которая будет заниматься разрешением инцидента. Основой для распределения (маршрутизации) инцидентов часто является информация о категориях. При определении категорий может потребоваться рассмотрение структуры групп поддержки. Правильное распределение инцидентов имеет существенное значение для эффективности Процесса Управления Инцидентами. Поэтому одним из ключевых показателей эффективности[68] (KPI) Процесса Управления Инцидентами может быть число неправильно распределенных обращений.
С учетом приоритета и соглашения SLA пользователь информируется о максимальном расчетном времени разрешения инцидента. Эти сроки также фиксируются в системе.
Идентификационный номер инцидента
Абонент информируется о номере инцидента для его точной идентификации при последующих обращениях.
Статус инцидента указывает на его положение в процессе обработки инцидента. Примерами статусов могут быть:
4.4.3. Привязка (сопоставление)
После классификации проводится проверка, не возникал ли аналогичный инцидент ранее и нет ли готового решения или обходного пути. Если инцидент имеет те же признаки, что и открытая проблема или известная ошибка, то может быть установлена связь с ними.
4.4.4. Расследование и диагностика
Служба Service Desk или группа поддержки направляет инциденты, не имеющие готового решения или выходящие за пределы компетенции работающего с ним сотрудника, группе поддержки следующего уровня с большим опытом и знаниями. Эта группа исследует и разрешает инцидент или направляет его группе поддержки очередного уровня.
В процессе разрешения инцидента различные специалисты могут обновлять регистрационную запись о нем, изменяя текущий статус, информацию о выполненных действиях, пересматривая классификацию и обновляя время и код работавшего сотрудника.
4.4.5. Решение и восстановление
После успешного завершения анализа и разрешения инцидента сотрудник записывает решение в систему. В некоторых случаях необходимо направить Запрос на Изменение (RFC) в Процесс Управления Изменениями. В наихудшем случае, если не найдено никакого решения, инцидент остается открытым.
После реализации решения, удовлетворяющего пользователя, группа поддержки направляет инцидент обратно в Службу Service Desk. Эта служба связывается с сотрудником, сообщившим об инциденте, с целью получения подтверждения об успешном решении вопроса. Если он это подтверждает, то инцидент может быть закрыт; в противном случае процесс возобновляется на соответствующем уровне. При закрытии инцидента необходимо обновить данные об окончательной категории, приоритете, сервисах (услугах), подвергшихся воздействию инцидента и Конфигурационной Единице (CI), вызвавшей сбой.
4.4.7. Мониторинг хода решения и отслеживание
В большинстве случаев ответственной за мониторинг хода решения является Служба Service Desk, как «владелец» всех инцидентов. Эта служба должна также информировать пользователя о состоянии инцидента. Обратная связь с пользователем может быть уместной после изменения статуса, например, направлении инцидента на следующую линию поддержки, изменении расчетного времени решения, эскалации и т. д. Во время мониторинга возможна функциональная эскалация к другим группам поддержки или иерархическая эскалация для принятия руководящих решений.
4.5. Контроль процесса
Основой контроля процесса являются отчеты для различных целевых групп. Руководитель Процесса Управления Инцидентами является ответственным за эти отчеты, а также за составление списка рассылки и графика составления отчетов. Отчеты могут включать специализированную информацию для следующих функциональных подразделений:
• Руководителю Процесса Управления Инцидентами отчет необходим для:
— идентификации недостающих звеньев процесса;
— идентификации нарушений исполнения соглашений об Уровне Услуг (SLA);
— отслеживания хода выполнения процесса;
— определения тенденций развития.
• Руководство Линейными ИТ-подразделениями – отчет для руководства группы поддержки; он также может быть полезен в Управлении ИТ-подразделениями. Отчет должен содержать следующую информацию:
— прогресс в решении инцидентов;
— время разрешения инцидентов в различных группах поддержки.
• Управления Уровнем Сервисов (Услуг) – отчет должен, прежде всего, содержать информацию о качестве предоставляемых услуг. Руководитель Процесса Управления Уровнем Услуг должен получать всю информацию, необходимую для составления Отчетов об Уровне Услуг перед заказчиками. Отчеты для заказчиков должны предоставлять информацию о том, выполняются ли соглашения в отношении Уровня Сервисов (услуг) в рамках Процесса Управления Инцидентами.
• Руководителей других процессов ИТ Сервис-менеджмента – отчеты для руководителей других процессов должны быть, в первую очередь, информативными, то есть содержать всю необходимую им информацию. Например, Процесс Управления Инцидентами на основе регистрационных записей об инцидентах может предоставлять следующую информацию:
— число обнаруженных и зарегистрированных инцидентов;
— число разрешенных инцидентов, с разделением по времени разрешения;
— статус и число неразрешенных инцидентов;
— инциденты с разбивкой по периодам возникновения, группам заказчика, группам поддержки и временем разрешения в соответствии с соглашением (SLA);
— инциденты с разбивкой по категориям, приоритетам и группам поддержки и др.
4.5.1. Критические факторы успеха
Для успешного Управления Инцидентами необходимо следующее:
• Актуальная Конфигурационная База Данных (CMDB), помогающая оценить степень воздействия и срочность инцидентов. Эта информация также может быть получена от пользователя, но в этом случае она, возможно, будет менее полной и достаточно субъективной, что приведет к увеличению времени разрешения инцидентов.
• База знаний[69]. Например, актуальная база данных по проблемам/известным ошибкам, описывающая способ распознавания инцидентов, имеющиеся решения и обходные пути. Она также может включать аналогичные базы знаний от поставщиков.
• Соответствующую автоматизированную систему регистрации, отслеживания и мониторинга инцидентов.
Дополнительно необходимо тесное взаимодействие с Процессом Управления Уровнем Сервисов (Услуг) для определения требуемых приоритетов и времени разрешения инцидентов.
4.5.2. Показатели эффективности[70]
Для оценки производительности процесса необходимо четко определить контрольные параметры и измеряемые оценки, часто называемые показателями эффективности. Отчет по этим показателям производится регулярно, например раз в неделю, чтобы получить картину изменений, по которой можно было бы определить тенденции. Примерами таких параметров являются:
• общее количество инцидентов;
• среднее время разрешения инцидентов;
• среднее время разрешения инцидентов по приоритетам;
• среднее число инцидентов, разрешенных в рамках соглашений (SLA);
• процент инцидентов, разрешенных первой линией поддержки (без направления в другие группы);
• средняя стоимость поддержки на инцидент;
• число решенных инцидентов на одно рабочее место или на одного сотрудника службы Service Desk;
• инциденты, решенные без посещения пользователя (удаленно);
• число (или процент) инцидентов с первоначально некорректной классификацией;
• число (или процент) инцидентов, неправильно распределенных в группы поддержки.
4.5.3. Функции и роли
Реализация процессов проходит в горизонтальной плоскости через иерархическую структуру организации. Это возможно только при четком определении ответственности и полномочий, связанных с реализацией процессов. Для повышения гибкости может быть использован ролевой подход (т.е. определение ролей). В небольших организациях или в целях снижения общих расходов возможно комбинирование ролей, например, совмещение ролей Руководителя Процессов Управления Изменениями и Управления Конфигурациями.
Руководитель Процесса Управления Инцидентами
Во многих организациях роль Руководителя Управления Инцидентами играет менеджер Службы Service Desk. В сферу ответственности Руководителя Процесса Управления Инцидентами включается следующее:
• мониторинг эффективности и рациональности работы[71] процесса;
• контроль работы групп поддержки;
• составление рекомендаций по совершенствованию работы процесса;
• развитие и сопровождение системы Управления Инцидентами.
Персонал групп поддержки
• Первая линия поддержки несет ответственность за регистрацию, классификацию, сопоставление (привязку), распределение по группам поддержки, разрешение и закрытие инцидентов.
• Остальные группы поддержки, прежде всего, принимают участие в расследовании, диагностике и разрешении инцидентов в рамках установленных приоритетов.
4.6. Затраты и проблемы
Затраты, связанные с Управлением Инцидентами, включают первоначальные затраты на внедрение (например, расходы на разработку процесса, обучение и инструктаж персонала), выбор и закупку инструментальных средств[72] поддержки процесса. Выбор инструментальных средств может занять значительное количество времени. Кроме того, существуют операционные расходы, связанные с оплатой работы персонала и использованием инструментальных средств. Эти затраты во многом зависят от структуры Управления Инцидентами, диапазона видов деятельности, включенных в процесс, сфер ответственности и числа подразделений.
При внедрении Управления Инцидентами могут возникнуть следующие проблемы:
• Пользователи и ИТ-специалисты работают в обход процедур Управления Инцидентами – если пользователи будут устранять возникающие ошибки сами или напрямую связываться со специалистами, не следуя установленным процедурам, ИТ-организация не получит информацию о реально предоставляемом Уровне Услуг, числе ошибок и многое другое. Отчеты руководству также не будут адекватно отражать ситуацию.
• Перегруженность инцидентами и откладывание «на потом» – при неожиданном росте количества инцидентов для правильной регистрации может не оказаться достаточно времени, т. к. до окончания ввода информации об инциденте от одного пользователя возникает необходимость обслуживать следующего. В этом случае ввод описания инцидентов может производиться недостаточно точно и процедуры по распределению инцидентов по группам поддержки не будут выполняться должным образом. В результате решения получаются некачественными и рабочая нагрузка увеличивается еще больше. В случаях, если число открытых инцидентов начинает интенсивно расти, процедура экстренного выделения дополнительных ресурсов внутри организации может предотвратить перегрузку персонала.
• Эскалация – как известно, в рамках Процесса Управления Инцидентами возможна эскалация инцидентов. Слишком большое число эскалаций может оказать отрицательное воздействие на работу специалистов, которые из-за этого отрываются от своей запланированной работы.
• Отсутствие Каталога Услуг и Соглашений об Уровне Сервисов (SLA) – если поддерживаемые услуги и продукты недостаточно точно определены, тогда специалистам, вовлеченным в Управление Инцидентами, бывает трудно обоснованно отказать пользователям в помощи.
• Недостаточная приверженность[73] процессному подходу со стороны руководства и персонала – решение инцидентов с помощью процессного подхода обычно требует изменения культуры и более высокого уровня ответственности за свою работу со стороны персонала. Это может вызвать серьезное сопротивление внутри организации. Эффективное Управление Инцидентами требует от сотрудников понимания и реальной приверженности процессному подходу, а не просто участия.