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