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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Показатели эффективности

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

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

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

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

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

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

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

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

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

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

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

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

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

Руководитель Процесса Управления Инцидентами

Во многих организациях роль Руководителя Управления Инцидентами играет менеджер Службы Service Desk. В сферу ответственности Руководителя Процесса Управления Инцидентами включа­ется следующее:

• мониторинг эффективности и рациональности работы процесса;

• контроль работы групп поддержки;

• составление рекомендаций по совершенствованию работы процесса;

• развитие и сопровождение системы Управления Инцидентами. Персонал групп поддержки

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

• Остальные группы поддержки, прежде всего, принимают участие в расследовании, диагностике и разрешении инцидентов в рамках установленных приоритетов.

• 4.6. Затраты и проблемы

1. Затраты

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

2. Проблемы

При внедрении Управления Инцидентами могут возникнуть следующие проблемы:

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

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

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

• Отсутствие Каталога Услуг и Соглашений об Уровне Сервисов (SLA) — если поддерживаемые услуги и продукты недостаточно точно определены, тогда специалистам, вовлеченным в Управле­ние Инцидентами, бывает трудно обоснованно отказать пользователям в помощи.

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