Управление Проблемами

Общие положения

Данный документ определяет политику управления ИТ проблемами в организации. Документ является внутренним руководящим документом ИТ департамента. Документ должен соответствовать следующим требованиям:

•Действующему законодательству и иными правовыми актам Азербайджанской Республики,

•Нормативной документацией Контролирующего органа Азербайджанской Республики,

•Уставу организации

•Уставу ИТ департамента

•Внутренним регламентирующими документами (приказы, распоряжения и т п) организации.

•Рекомендациям лучших практик и стандартов, принятых в отрасли и сфере информационных технологий

Цели документа

Внесения ясность в организацию Управления ИТ проблемами в организации. Цели документа:

•Формирование концепции и принципов и организации процесса управления ИТ проблемами в организации.

•Повышение эффективности взаимодействия ИТ департамента и бизнеса.

Принятые сокращения и определения

Владелец сервиса (service owner) – роль или структурное подразделение организации, который занимается постановкой целей, принимает решения и управляет финансированием по сервису.

Менеджер сервиса (service manager) – роль или структурное подразделение организации, который занимается выполнением целей и задач, поставленных владельцем сервиса, обеспечивает развертывание и сопровождение сервиса.

Инцидент – любое не запланированное снижение уровня предоставления сервиса.

Значительный инцидент (major incident) – инцидент, имеющий высокий уровень воздействия (impact) на функционирование сервиса.

Запрос – любой запрос в ИТ департамент, связанный с функционированием ИТ сервисов.

Запрос на изменения – запрос, выполнение которого связанно с необходимостью внести изменения в любой из компонентов ИТ сервиса.

Стандартный Запрос – любой запрос в ИТ департамент, связанный с функционированием ИТ сервисов заранее авторизирован и с предопределенным порядком исполнения.

Запрос на предоставление сервиса – тип запроса, связанный с предоставлением сервиса, не имеющегося в списке каталога сервисов. Как правило новый сервис.

Запрос на обслуживание – тип запроса, связанный с предоставлением сервиса, имеющегося в списке каталога сервисов.

Запрос на предоставление информации – тип запроса, связанный с предоставлением информации.

Запрос на предоставление доступа – тип запроса, связанный с предоставлением / изменением доступа к сервису.

Уровень воздействия (impact) – границы воздействия запроса на функционирование сервиса. Может определяться как степенью отказа сервиса (частичный, полный), так и уровнем охвата пользователей (один сотрудник, группа сотрудников и т п). Является составляющей, определяющей приоритет инцидента.

Уровень срочности (urgency) – степень, определяющая срочность исполнения запроса. Является составляющей, определяющей приоритет инцидента.

Приоритет (priority) – определяет важность запроса и порядок его разрешения.

Обходное решение (work around) – действия, позволяющие временно или выполнить запрос.

Эскалация – механизм, позволяющий своевременно исполнить запрос с помощью привлечения дополнительных ресурсов (горизонтальная) или более компетентного уровня знаний или полномочий (вертикального). Цель данного механизма исполнить запрос в рамках принятого соглашения об обслуживании.

Комитет по изменениям – комитет, разрешающий внесение изменений

Стандартный запрос на изменения— любой запрос в ИТ департамент на изменения, связанный с функционированием ИТ сервисов заранее авторизирован и с предопределенным порядком исполнения.

Проблема – причина появления инцидентов.

Известная проблема – причина появления инцидентов, известная производителю.

Сфера действия документа

Действия данного документа распространяется на все аспекты деятельности ИТ департамента связанные с управлением проблемами.

Документ является высокоуровневым руководящим документом ИТ департамента и предназначен для ознакомления и соблюдения со стороны руководства структурных подразделений организации и сотрудников.

Документ утверждается решением ИТ комитета и является обязательным для исполнения и соблюдения всеми подразделениями организации.

Процедура принятия документа, внесения изменений определены в документе «Процедура организации, руководящей ИТ документации».

Связанные документы

Действия данного документа дополняется или является основополагающим для следующих ИТ документов:

•«Политика управления запросами»

•«Процедура управления запросами»

•«Стандарты и метрики процесса управления запросами»

•«Процедура регистрации пользователей»

•«Политика управления инцидентами»

•«Стандарты и метрики процесса управления инцидентами»

•«Процедура управления инцидентами»

•«Политика управления изменениями»

•«Стандарты и метрики процесса управления изменениями»

•«Процедура управления изменениями»

•«Процедура управления проблемами»

•«Стандарты и метрики процесса управления проблемами»

•«Политика управления релизами»

•«Стандарты и метрики процесса управления релизами»

•«Процедура управления релизами»

Влияние при отсутствии процесса Управления Проблемами

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

•Нехватка управленческой информации для принятия решений

•Хаотичный порядок реагирования ИТ сотрудников на запросы, инциденты, изменения

•Отсутствие фактической и точной информации по функционированию сервисов

•Не эффективное использование ИТ ресурсов при решении проблем

Цели процесса Управления Проблемами

Основные цели политики управления ИТ проблемами можно определить, как:

•Своевременное реагирование на проблемы и скорейшее их исполнение

•Формирование процесса управления проблемами, определение процедур, стандартов и метрик.

•Обеспечение прозрачности функционирования ИТ департамента для бизнеса

•Снижение негативного влияния на бизнес, при неэффективном решении проблем

Рациональное использование ИТ ресурсов

•Повышения удовлетворенности бизнеса и сотрудников работой ИТ департамента

Задачи процесса Управления Проблемами

Задачи ИТ департамента по управлению проблемами можно определить, как следующие:

•Организация процесса управления проблемами

•Классификация и категоризация проблем

•Классификация воздействия, срочности и приоритета

•Классификация метрик и показателей работы процесса

•Определение ролей и уровень вовлеченности сотрудников

•Организации деятельности по регистрации проблем

•Организации деятельности по классификации и оценке проблем

•Организации деятельности по решению проблем

•Организации деятельности по закрытию проблем

•Организации деятельности по коммуникации в процессе управления проблемами

•Организации деятельности по мониторингу и отчетности по работе процесса

•Организации деятельности по взаимодействию с другими процессами управления ИТ сервисами

•Оптимизация процесса управления проблемами

Процесс Управления Проблемами

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

•Определение проблемы

•Оценка проблемы

•Диагностика проблемы

•Решение проблемы

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

Процесс управления проблемами в организации, представлен на диаграмме.

Диаграмма 1: блок схема управления проблемами

Для построения эффективного процесса управления проблемами необходимо наличие следующих входных данных:

•Наличие каталога сервисов, предоставляемых ИТ департаментом

•Определены каналы инициализации проблем

•Наличие базовых и/или специфических соглашений по предоставлению услуг

•Определены группы решения проблем

•Определены каналы обратной связи по информированию о статусе проблемы

•Определены ключевые атрибуты проблемы

•Определены метрики процесса

•Наличие компонентной базы ИТ инфраструктуры

При функционировании процесса управления проблемами необходимы следующие инструменты:

•Процедуры управления проблемами

•Инструменты по решению проблем

•Инструменты для регистрации, мониторинга и управления проблемами

•База знаний по известным проблемам

•Статистика и аналитика по управлению инцидентами

При функционировании процесса управления проблемами формируются следующие выходных данные:

•Запросы на изменения (часть процесса управления изменениями)

•Регистрация проблем

•Отчеты

•Сообщения

В процессе управления проблемами определены следующие группы:

•Группа решения проблем —группы поддержки, непосредственно выполняющие проблемы.

Под-процесс определения проблемы

Данный под-процесс жизненного цикла управления проблемами определяет порядок регистрации проблемы. В качестве основных каналов инициализации проблемы можно определить следующие типы:

•Регистрация запроса по звонку пользователя

•Регистрация запроса при непосредственном контакте с сотрудником

•Регистрация запроса с использованием электронной почты

•Регистрация запроса по средствам электронного портала средств управления ИТ сервисами

Входная информация включает, но не ограничена следующими данными:

•Канал инициализации запроса

•Контактная информация по пользователю

•Краткое название запроса

•Классификация и категоризация запроса

•Детальная информация по запросу

Выходная информация включает, но не ограничена следующими данными:

•Уникальная запись по запросу

В качестве триггера используется:

•Неудовлетворенность пользователя качеством предоставляемого сервиса

Под-процесс оценки проблемы

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

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

В качестве классификации запроса можно определить следующие типы и источники:

•Общие классы запросов (сеть, оборудование, сервера и т п)

•Каталог ИТ сервисов и критичности сервисов

•Уровень соглашения по обслуживанию

Кроме этого необходимо определить дополнительные типы:

•Запросы пользователей (End user requests)

•Прочие и неклассифицированные (Other requests)

Для определения приоритета необходимо определить воздействие и срочность запроса. В качестве воздействия (impact) запроса можно определить, как минимум следующие типы:

•Минимальное (Low)

•Среднее (Medium)

•Высокое (High)

В качестве срочности выполнения (urgency) запроса можно определить, как минимум следующие типы:

•Минимальное (Low)

•Среднее (Medium)

•Высокое (High)

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по запросу

•Классификация и категоризация

•Приоритет запроса

•Связанные компоненты ИТ инфраструктуры

•Связанный шаблон активности по запросу

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по запросу

•Определённая группа поддержки

•Определенный шаблон действий по запросу

•Определенная группа одобрения запроса

В качестве триггера используется:

•Наличие уникальной записи по запросу

Под-процесс диагностики и расследования проблемы

Под-процесс одобрения запроса является следующим этапом жизненного цикла управления запросами. На данном этапе происходит одобрение действий по запросу.

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по запросу

•Классификация и категоризация

•Приоритет запроса

•Связанные компоненты ИТ инфраструктуры

•База знаний и т п

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по запросу

•Определённая группа поддержки

•Установленное время выполнения запроса

•Информация по разрешению запроса

В качестве триггера используется:

•Наличие уникальной записи по запросу

Под-процесс решения проблемы

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

•Назначение «Assign to ME» запроса на конкретного исполнителя (Request Resolver)

•Выполнение действий по выполнению запроса

•Обращение за дополнительной информацией

•Эскалация инцидента как горизонтальная, так и вертикальная с привлечением внешней стороны (L4)

•Документирование

•Формирование запроса на изменения по необходимости

•Формирование проблемы по необходимости

•Создание или обновление базы знаний

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по запросу

•Классификация

•Приоритет запроса

•Определённая группа поддержки

•Связанные компоненты ИТ инфраструктуры

•База знаний и т п

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по запросу

•Информация по выполнению запроса

В качестве триггера используется:

•Наличие уникальной записи по запросу

•Счетчик времени по выполнению запроса в соответствии с соглашением об уровне предоставления услуг

Под-процесс закрытия проблемы

Под-процесс закрытия запроса является финальным этапом жизненного цикла управления запросами. При этом различается:

•Выполнение запроса —полное выполнение запроса сотрудником группы поддержки и подтверждения со стороны инициатора запроса,

•Выполнение запроса с незначительными проблемами – выполнение запроса с наличием незначительных замечаний,

•Частичное выполнение запроса —запрос выполнен не полностью,

•Реактивация запроса – повторное активирование запроса

Данный этап содержит такие действия, как:

•Обновление информации по запросу

•Документирование

•Закрытие запроса

•Формирование запроса на изменения по необходимости

•Формирование проблемы по необходимости

•Создание или обновление базы знаний

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по запросу

•Классификация

•Приоритет запроса

•Категория разрешения запроса

•Статус запроса

•Связанные компоненты ИТ инфраструктуры

•База знаний и т п

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по запросу

•Определённая группа поддержки

•Информация по выполнению запроса (категория, время разрешения и т п)

В качестве триггера используется:

•Наличие уникальной записи по запросу

•Счетчик времени по выполнению запроса в соответствии с соглашением об уровне предоставления услуг

Метрики процесса Управления Проблемами

Для обеспечения высокого уровня функционирования процесса управления проблемами необходимо обеспечить мониторинг состояния следующих метрик и активности процесса:

•Количество запросов

•Выполнение запросов при первом контакте

Роли и ответственности

В соответствии с организационной структурой организации и ИТ департамента в частности, определены следующие роли и ответственности:

Владелец сервиса

Цели:

•Восстановление и сопровождение сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с владельцем процесса по улучшению сопровождения

•Получение информации по инцидентам, относящимся к функционированию его сервиса

Менеджер сервиса

Цели:

•Восстановление и сопровождение сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с владельцем процесса по вопросам улучшения сопровождения сервиса

•Взаимодействие с владельцем сервиса по вопросам улучшения сопровождения сервиса

•Получение информации по инцидентам, относящимся к функционированию его сервиса

•Предоставление информации по инцидентам, относящимся к функционированию его сервиса

Оператор отдела «Поддержки Пользователей»

Отдел «Поддержки Пользователей»

Цели:

•Восстановление сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с пользователями

•Классификация обращения пользователя

•Регистрация пользовательской информации

•Регистрация и классификация инцидентов и ключевых атрибутов

•Привязка компонентной базы, базы знаний, связанных инцидентов и т п

•Использование имеющихся инструментов или обходных методов для разрешения инцидента

•Обновление информации по инциденту

•Назначение или эскалация инцидента на соответствующую группу поддержки

•Предложение по улучшению процесса управления инцидентами

•Предложения по улучшению функционирования сервиса

Специалист поддержки (Problem Resolver)

Цели:

•Восстановление сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с пользователями

•Классификация обращения пользователя

•Регистрация пользовательской информации

•Регистрация и классификация инцидентов и ключевых атрибутов

•Привязка компонентной базы, базы знаний, связанных инцидентов и т п

•Использование имеющихся инструментов или обходных методов для разрешения инцидента

•Назначение инцидента «на себя» из группы поддержки

•Обновление информации по инциденту

•Эскалация инцидента на соответствующую группу поддержки

•Предложение по улучшению процесса управления инцидентами

•Предложения по улучшению функционирования сервиса

•Инициирование запроса на изменения

•Регистрация проблемы по необходимости

•Написание и обновление базы знаний

Менеджер процесса управления проблемами (Problem Manager)

Цели:

•Эффективное и результативное функционирование процесса управления инцидентами

•Обеспечение соответствия процесса требованиям ИТ архитектуры

•Повышение полноты и точности информации, вовлеченной в процесс

•Снижение количества инцидентов и времени их разрешения

Ответственность:

•Улучшение и оптимизация процесса

•Точное и оптимальное распределение ролей сотрудников, вовлеченных в процесс

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

•Оперативное вмешательство в процесс для обеспечения соответствия требованиям

•Разработка и применение метрик и показателей процесса

•Анализ процесса и под-процессов

•Мониторинг и предоставление отчетности по работе процесса

•Предоставление отчетности по сервисам и связанными с ними инцидентам

•Оценка и предоставление отчетности по эффективности сотрудников, задействованных в процессе

•Взаимодействие с другими отделами и подразделениями по вопросам, связанным с процессом

Роли и ответственности сотрудников указаны в соответствующих должностных инструкциях.

Порядок взаимодействия процесса Управления Проблемами

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

•Владелец процесса отвечает за организацию процесса, внесения изменений и дополнений.

•Владельцы сервисов обращаются к владельцу процесса по вопросам организации управления запросами.

Риски при внедрении и сопровождении процесса Управления Проблемами

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

•Отсутствие поддержки со стороны руководства организации

•Отсутствие достаточного уровня культуры в организации в целом, так и сотрудников в частности

•Отсутствие достаточного уровня организации со стороны бизнеса, и как следствие четкой постановки задач ИТ

•Отсутствие необходимых ресурсов, для внедрения и сопровождения процесса

•Нехватка знаний и навыков у специалистов ИТ департамента

•Недостатки системы автоматизации процесса управления запросами

•Недостатки сопутствующей ИТ инфраструктуры

Ключевые факторы успеха внедрения и сопровождения процесса Управления Проблемами

Ключевые факторы успеха при внедрении и сопровождении процесса управления запросами можно определить, как:

•Пристальное внимание к процессу

•Реалистичные цели

•Соответствие бизнес процессов и процесса управления запросами

•Наличие и соблюдение четких, измеряемых соглашений по уровню предоставления услуг

•Измеряемые показатели

•Наличие актуальной и полной компонентной базы

•Наличие актуальной и постоянно обновляемой базы знаний по запросам

•Высокий уровень квалификации сотрудников ИТ департамента

•Приемлемый уровень осведомленности сотрудников организации

•Наличие инструментов диагностики и выполнения запросов

Показатели эффективности и критерии оценки деятельности

•Критериями оценки деятельности, связанной с информационной безопасностью являются:

•Снижение количества ИТ запросов в организации

•Повышение уровня доступности ИТ сервиса

•Отсутствие претензий со стороны сотрудников подразделений организации,

•Отсутствие претензий со стороны контролирующих органов по вопросам, связанным с управлением запросами

•Удовлетворенность руководства организации.

Контроль документа:

•Номер документа:

•Наименование документа:

•Статус документа:

•Маркер безопасности:

•Дата утверждения:

•Дата вступления в силу:

•Протокол ИТ комитета:

•Заменяет документ:

•Документ разработан:

•Дата разработки:

•Документ одобрен:

•Дата одобрения:

•Утвержден:

•Дата утверждения:

Контроль версии документа:

•Версия документа:

•Дата внесения изменений:

•Автор:

•Содержание изменений: