ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL

van Bon Jan

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

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

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

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

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

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

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

? Руководство

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

69

Knowledge Base.

4.5.2. Показатели эффективности [70]

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

? общее

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

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

70

Performance Indicators.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

? развитие и сопровождение системы Управления Инцидентами.

71

Effectiveness and Efficiency.

Персонал групп поддержки

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

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

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

4.6.1. Затраты

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

72

Т.е. программного обеспечения. – Прим. ред.