ИТ Сервис-менеджмент. Введение - [22]
- число обнаруженных и зарегистрированных инцидентов;
- число разрешенных инцидентов, с разделением по времени разрешения;
- статус и число неразрешенных инцидентов;
- инциденты с разбивкой по периодам возникновения, группам заказчика, группам поддержки и временем разрешения в соответствии с соглашением (SLA);
- инциденты с разбивкой по категориям, приоритетам и группам поддержки и др.
4.5.1. Критические факторы успеха
Для успешного Управления Инцидентами необходимо следующее:
• Актуальная Конфигурационная База Данных (CMDB), помогающая оценить степень воздействия и срочность инцидентов. Эта информация также может быть получена от пользователя, но в этом случае она, возможно, будет менее полной и достаточно субъективной, что приведет к увеличению времени разрешения инцидентов.
• База знаний[69]. Например, актуальная база данных по проблемам/известным ошибкам, описывающая способ распознавания инцидентов, имеющиеся решения и обходные пути. Она также может включать аналогичные базы знаний от поставщиков.
• Соответствующую автоматизированную систему регистрации, отслеживания и мониторинга инцидентов.
Дополнительно необходимо тесное взаимодействие с Процессом Управления Уровнем Сервисов (Услуг) для определения требуемых приоритетов и времени разрешения инцидентов.
4.5.2. Показатели эффективности[70]
Для оценки производительности процесса необходимо четко определить контрольные параметры и измеряемые оценки, часто называемые показателями эффективности. Отчет по этим показателям производится регулярно, например раз в неделю, чтобы получить картину изменений, по которой можно было бы определить тенденции. Примерами таких параметров являются:
• общее количество инцидентов;
• среднее время разрешения инцидентов;
• среднее время разрешения инцидентов по приоритетам;
• среднее число инцидентов, разрешенных в рамках соглашений (SLA);
• процент инцидентов, разрешенных первой линией поддержки (без направления в другие группы);
• средняя стоимость поддержки на инцидент;
• число решенных инцидентов на одно рабочее место или на одного сотрудника службы Service Desk;
• инциденты, решенные без посещения пользователя (удаленно);
• число (или процент) инцидентов с первоначально некорректной классификацией;
• число (или процент) инцидентов, неправильно распределенных в группы поддержки.
4.5.3. Функции и роли
Реализация процессов проходит в горизонтальной плоскости через иерархическую структуру организации. Это возможно только при четком определении ответственности и полномочий, связанных с реализацией процессов. Для повышения гибкости может быть использован ролевой подход (т.е. определение ролей). В небольших организациях или в целях снижения общих расходов возможно комбинирование ролей, например, совмещение ролей Руководителя Процессов Управления Изменениями и Управления Конфигурациями.
Руководитель Процесса Управления Инцидентами
Во многих организациях роль Руководителя Управления Инцидентами играет менеджер Службы Service Desk. В сферу ответственности Руководителя Процесса Управления Инцидентами включается следующее:
• мониторинг эффективности и рациональности работы[71] процесса;
• контроль работы групп поддержки;
• составление рекомендаций по совершенствованию работы процесса;
• развитие и сопровождение системы Управления Инцидентами.
Персонал групп поддержки
• Первая линия поддержки несет ответственность за регистрацию, классификацию, сопоставление (привязку), распределение по группам поддержки, разрешение и закрытие инцидентов.
• Остальные группы поддержки, прежде всего, принимают участие в расследовании, диагностике и разрешении инцидентов в рамках установленных приоритетов.
4.6. Затраты и проблемы
4.6.1. Затраты
Затраты, связанные с Управлением Инцидентами, включают первоначальные затраты на внедрение (например, расходы на разработку процесса, обучение и инструктаж персонала), выбор и закупку инструментальных средств[72] поддержки процесса. Выбор инструментальных средств может занять значительное количество времени. Кроме того, существуют операционные расходы, связанные с оплатой работы персонала и использованием инструментальных средств. Эти затраты во многом зависят от структуры Управления Инцидентами, диапазона видов деятельности, включенных в процесс, сфер ответственности и числа подразделений.
4.6.2. Проблемы
При внедрении Управления Инцидентами могут возникнуть следующие проблемы:
• Пользователи и ИТ-специалисты работают в обход процедур Управления Инцидентами – если пользователи будут устранять возникающие ошибки сами или напрямую связываться со специалистами, не следуя установленным процедурам, ИТ-организация не получит информацию о реально предоставляемом Уровне Услуг, числе ошибок и многое другое. Отчеты руководству также не будут адекватно отражать ситуацию.
• Перегруженность инцидентами и откладывание «на потом» – при неожиданном росте количества инцидентов для правильной регистрации может не оказаться достаточно времени, т. к. до окончания ввода информации об инциденте от одного пользователя возникает необходимость обслуживать следующего. В этом случае ввод описания инцидентов может производиться недостаточно точно и процедуры по распределению инцидентов по группам поддержки не будут выполняться должным образом. В результате решения получаются некачественными и рабочая нагрузка увеличивается еще больше. В случаях, если число открытых инцидентов начинает интенсивно расти, процедура экстренного выделения дополнительных ресурсов внутри организации может предотвратить перегрузку персонала.