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

6.1. Политики процесса

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

Целями процесса управления проблемами в данной редакции являются:

l минимизация количества повторяющихся Инцидентов;

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

Основными участниками процесса являются следующие роли:

l Регистратор проблемы;

l Аналитик;

l Ответственный по группе;

l Исполнитель;

l Менеджер процесса.

1. Процесс управления проблемами является единым для всех подразделений, вовлеченных в предоставление ИТ-услуг.

2. Автоматизация процесса управления проблемами в АСУ ИТУ реализуется с использованием следующих объектов:

· Проблема;

· Известная ошибка;

· Задача (по проблеме).

3. Все проблемы/известные ошибки, а так же их решения регистрируются в единой базе данных управления проблемами.

4. Проблема может быть зарегистрирована:

· по решению аналитика на основе анализа инцидентов и информации из других процессов;

· по решению менеджера процесса управления инцидентами – с целью предотвращения или остановки потока массовых или критических инцидентов;

· по инициативе второй линии поддержки и других подразделений Службы ИТ.

5. Процесс управления проблемами является отдельным от процесса управления инцидентами. Процесс управление проблемами выявляет и устраняет корневые причины возникновения Инцидентов (ориентирован на качество и стабильность предоставления ИТ-услуг), в то время как процесс управления инцидентами преследует цель скорейшего решения инцидентов любыми доступными способами, в том числе с помощью обходного решения (ориентирован на скорость).

6. Процесс управления проблемами обеспечивает выявление корневых причин инцидентов и негативных тенденций на основе данных, полученных из:

· процесса управления инцидентами;

· других источников (например, база известных ошибок производителей/подрядных организаций).

7. Известная ошибка формируется на основании проблемы при выполнении следующих условий:

· проблема успешно диагностирована;

· для проблемы найдено обходное решение.

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

· между записями об инцидентах и записями о проблемах/известных ошибках.

9. Проблема закрывается в одном из следующих случаев:

· корневая причина была устранена;

· Проблема является дублем;

· Проблема не может быть причиной инцидентов;

· Менеджер процесса принял решение о нецелесообразности дальнейшей обработки проблемы.

Если работы по проблеме не могут быть продолжены по иной причине, то она переводится в статус «Отложена» с указанием соответствующей причины.

10. В рамках процесса управления проблемами аналитик является координатором работ по проблеме. Аналитик наделяется полномочиями привлекать к решению проблемы любые подразделения службы ИТ путём создания задач в АСУ ИТУ на соответствующие рабочие группы.

11. За контроль соблюдения технологии и совершенствование процесса отвечает Менеджер процесса.

12. Ключевые показатели эффективности (КПЭ) собираются с целью:

· оценки качества работы подразделений службы ИТ и систем;

· регулярного совершенствования процесса управления проблемами.

6.2. Описание процесса

Процесс управления проблемами состоит из нескольких процедур. Каждая процедура состоит из нескольких шагов. Для идентификации составляющих процесса применяется каскадная нумерация: процесс управления проблемами имеет порядковый номер 6, процедуры нумеруются как 6.1., 6.2. и т.д., шаги — как 6.1.1., 6.1.2. и т.д.

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

6.3. Выявление и регистрация проблем

6.4. Анализ и диагностика проблемы

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

6.6. Выполнение работ

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

6.8. Контроль

6.9. Формирование отчётности

6.10. Оценка и совершенствование процесса

6.3. Выявление и регистрация проблем

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

Основанием для обязательной регистрации Проблем являются:

· Инцидент с приоритетом «Критичный» с неизвестной корневой причиной.

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

· тенденции в Инцидентах;

· информация о проблеме, способной стать причиной инцидентов (например, информация журналов ошибок, выводы специалистов).

6.3.1. Анализ информации по инцидентам

Анализ информации по инцидентам, зарегистрированным в АСУ ИТУ, выполняется аналитиком регулярно, независимо от потока поступающих Инцидентов (например, один раз в неделю). При этом аналитик также выступает в роли регистратора проблемы. Обязательному анализу подвергаются инциденты, отмеченные в ходе устранения флагом «Кандидат для управления проблемами».

По результатам проведённого анализа аналитик выполняет одно из следующих действий:

· регистрирует новую проблему согласно шагу " Регистрация проблемы" и привязывает к ней Инциденты;

· привязывает инциденты к существующей проблеме.

В случае привязки инцидента к существующей проблеме аналитик должен провести дополнительный анализ этой проблемы на предмет уточнения/изменения проблемы (например, повысить её приоритет и т.д.).

6.3.2. Получение информации от специалистов

Специалисты, выявившие информацию о проблеме на основании данных в АСУ ИТУ и тенденций в других системах (например, системах мониторинга), могут сообщить о ней ответственному по своей группе, который зарегистрирует проблему.

6.3.3. Получение информации от поставщиков/производителей

Проблемы и известные ошибки могут поступать от разработчиков, производителей и поставщиков. Ответственный по группе, осуществляющей взаимодействие с поставщиком, выполняет анализ проблем и известных ошибок с целью исключить дублирование. В случае если аналогичных проблем/известных ошибок в АСУ ИТУ не зарегистрировано, ответственный по группе выполняет регистрацию соответствующей записи. Если аналогичная проблема/известная ошибка уже зарегистрирована в АСУ ИТУ, то информация о ней должна быть дополнена/скорректирована с учётом новых данных, полученных от поставщика/производителя.

6.3.4. Регистрация проблемы

Регистрацию проблемы выполняет аналитик или ответственный по группе в зависимости от источника проблемы. Автоматически устанавливаются следующие атрибуты:

· ФИО регистратора проблемы;

· время и дата создания;

· номер (уникальный ID) проблемы;

· начальный статус = «Открыта».

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

· краткое описание Проблемы;

· подробное описание Проблемы;

· основная КЕ (если известна);

· затронутые КЕ (если известны);

· категория;

· источник проблемы;

· обходные решения, примененные при устранении инцидентов;

· связи с инцидентами (если имеются).

В зависимости от сути проблемы указывается одна из следующих категорий Проблемы:

· аппаратное обеспечение;

· прикладное ПО;

· системное ПО;

· безопасность;

· данные;

· прочее.

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

· из инцидентов (заполняется по умолчанию для проблем, которые регистрирует аналитик);

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

· от разработчиков.

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

Комментарий: Проблемы могут быть зарегистрированы также вне зоны ответственности регистратора проблемы (например, если проблема находится в зоне ответственности другого ИТ-подразделения или внешней организации).

Комментарий: Проблемы могут регистрироваться только по КЕ, находящимся в промышленной эксплуатации.

Комментарий: Вновь открытую проблему можно связать в АСУ ИТУ с закрытыми проблемами. Например, это актуально в случае, если проблемы имеют общую причину, либо проблема была закрыта ошибочно, решение проблемы не было в достаточной степени протестировано, что привело к повторному появлению инцидентов.

После выполнения данного шага аналитик приступает к выполнению процедуры " Анализ и диагностика проблемы".

6.4. Анализ и диагностика проблемы

6.4.1. Анализ проблемы

Аналитик устанавливает статус проблемы в «В работе» и выполняет координацию работ по поиску корневой причины.

Аналитик выполняет предварительный анализ и определяет влияние и срочность проблемы, с которой требуется ее устранение.

Приоритет проблемы определяется следующим образом:

l Аналитик указывает для проблемы:

· Влияние – относится ли данная проблема к одному пользователю или она затронула существенное количество пользователей в подразделении/организации;

· Срочность – является ли проблема срочной или нет (с точки зрения предоставления ИТ-услуг);

l на основании полученной информации АСУ ИТУ автоматически устанавливает приоритет по следующей таблице:

Рис.6.4.1. Правило определения приоритета проблемы.

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

Очередность дальнейшей обработки проблем определяется приоритетом.

В рамках анализа проблемы аналитик также по данным АСУ ИТУ определяет, не является ли проблема дублем другой, уже зарегистрированной проблемы или известной ошибки. Если аналогичная проблема известная ошибка уже зарегистрирована в АСУ ИТУ, то осуществляется переход к шагу «Обновление информации по существующей проблеме».

В случае, если проблема создана ошибочно, она закрывается с кодом закрытия «Отклонена» в соответствии с процедурой «Закрытие проблемы».

В иных случаях Аналитик переходит к выполнению шага «Диагностика и локализация Проблемы».

6.4.2. Диагностика и локализация проблемы

Аналитик координирует работу по диагностике и локализации проблемы.

Привлечение специалистов в ходе диагностики проблемы оформляется задачами по проблеме согласно процедуре «Выполнение задачи». Каждая работа оформляется в виде отдельной задачи. Результаты выполнения работ (результаты диагностики) исполнитель протоколирует в задаче в поле «Решение».

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

После окончания диагностики аналитик уточняет КЕ, с которой связана проблема, и вносит эту информацию в АСУ ИТУ.

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

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

6.4.3. Поиск решения и регистрация известной ошибки

По завершении диагностики аналитик выполняет поиск и формирование наилучшего обходного решения.

Если в поиске обходного решения проблемы аналитику понадобилось участие других специалистов, то их привлечение оформляется задачами согласно процедуре «Выполнение Задачи».

При наличии неисполненных инцидентов, связанных с проблемой, исполнители информируются о том, что обходное решение проблемы было найдено.

Возможно, что в ходе работы с проблемой будет обнаружено подходящее постоянное решение.

При нахождении обходного или постоянного решения аналитик устанавливает для проблемы признак «Известная ошибка» и переходит к выполнению процедуры «Решение проблемы».

В случае, если обходное или постоянное решение не было выработано в течение одного месяца, аналитик обращается к менеджеру процесса для принятия решения о приостановке работы над проблемой или продолжении поиска.

В случае если принято решение о продолжении работы над проблемой, осуществляется переход к шагу «Диагностика и локализация проблемы».

6.4.4. Обновление информации по существующей проблеме

Информация по существующей проблеме или известной ошибке должна быть дополнена/скорректирована с учётом новых данных. После этого зарегистрированная (дублирующая) проблема закрывается с кодом закрытия «Дублирование» в соответствии с процедурой «Закрытие проблемы».

6.4.5. Приостановка работы над проблемой

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

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

6.5.1. Поиск постоянного решения

Аналитик осуществляет анализ известной ошибки, по результатам которого документирует один или несколько возможных способов её устранения (постоянных решений), а также дополнительные обходные решения, если они были обнаружены.

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

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

По результатам работы процесса управления изменениями решение может быть признано неверным или неприемлемым. Аналитик (при необходимости, совместно с менеджером процесса) может принять одно из следующих решений:

l вернуться к исследованию известной ошибки и продолжить поиск решения;

l отложить известную ошибку и связанную с ней проблему (статус " Отложено") в рамках шага «Приостановка работы над проблемой».

В случае если предложенное решение принято, осуществляется переход к шагу «Применение постоянного решения».

6.5.2. Применение постоянного решения

В рамках данного шага осуществляется фактическое выполнение работ по устранению известной ошибки.

Для выполнения работ по устранению известной ошибки в АСУ ИТУ назначаются задачи по проблеме.

После выполнения данного шага аналитик переходит к выполнению процедуры «Закрытие проблемы».

6.5.3. Приостановка работы над проблемой

В случае, если постоянное решение по проблеме было отклонено, работа над проблемой приостанавливается (проблема переводится в статус «Отложена»). При появлении новой информации осуществляется переход к выполнению шага «Поиск постоянного решения» с целью поиска нового постоянного решения с учётом новых обстоятельств.

6.6. Выполнение задачи

Привлечение специалистов для выполнения работ по проблеме/известной ошибке осуществляется только аналитиком.

6.6.1. Регистрация Задачи

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

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

l категория;

l приоритет;

l краткое описание задачи;

l подробное описание задачи;

l КЕ, над которой необходимо выполнить работу (копируется основная КЕ из проблемы).

Аналитик может скорректировать описание задачи для исполнителя.

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

После выполнения данного шага аналитик переходит к шагу «Назначение в группу».

6.6.2. Назначение в группу

Назначение задачи выполняется в рабочую группу.

Аналитик выполняет выбор нужной группы на основании имеющейся у него информации. При необходимости аналитик обращается за консультацией к менеджеру процесса и ответственным по группам.

После выполнения данного шага статус задачи автоматически устанавливается в значение «Направлена в работу».

6.6.3. Анализ информации по задаче

При поступлении новой задачи все сотрудники рабочей группы автоматически информируются по электронной почте.

Ответственный по группе или исполнитель проводит анализ задачи в целях:

l определения правильности назначения в рабочую группу;

l определения исполнителя.

В рамках анализа может использоваться информация, указанная в задаче, а также информация из CMDB.

6.6.4. Отклонение задачи

Если задача направлена неверно, ответственный по группе или исполнитель выполняет следующие действия:

l переводит задачу в статус «Отклонена» (при этом счётчик количества перенаправленный задач увеличивается на единицу);

l протоколирует причину отклонения в протоколе, в т.ч. указывает рекомендации по назначению и/или составу работ.

Аналитик оповещается по электронной почте об отклонении задачи и переходит к выполнению шага " Назначение в группу".

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

6.6.5. Назначение исполнителя в группе

Назначение исполнителя выполняется указанием его ФИО в задаче. Дополнительные комментарии, рекомендации, распоряжения указываются в " Описании" или в протоколе.

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

Исполнитель всегда автоматически информируется по электронной почте о назначении на него новой задачи.

6.6.5. Принятие к исполнению

После назначения исполнителя по задаче он выполняет следующие действия:

l проводит анализ полученной задачи (поле " Краткое описание", " Описание", информация о КЕ, протокол и пр.);

l устанавливает статус «В работе» (при этом автоматически устанавливается дата/время принятия в работу);

l приступает к выполнению необходимой работы.

6.6.6. Исполнение и протоколирование

Исполнитель выполняет работы по задаче, протоколируя ход их выполнения.

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

В случае, если в ходе выполнения работ по устранению проблемы были добавлены новые КЕ или изменены атрибуты, связи или статус существующего КЕ, исполнитель, действуя в соответствии с процессом управления конфигурациями, вносит соответствующие корректировки в CMDB или сообщает о необходимости внесения таких корректировок выделенному специалисту рабочей группы администраторов КЕ, который обладает полномочиями для корректировки CMDB.

6.6.7. Отметка о выполнении

После того, как все необходимые работы в рамках задачи выполнены, исполнитель:

l контролирует правильность оформления задачи, при необходимости вносит корректировки (код закрытия; КЕ, над которыми велись работы и т.д.);

l проверяет актуальность CMDB в части КЕ, которые были изменены в рамках выполнения работ;

l указывает фактические трудозатраты, связанные с выполнением Задачи;

l меняет статус задачи на «Выполнена» (дата/время выполнения работы отмечается автоматически).

Комментарий: Выполненные задачи в системе недоступны для редактирования никому, кроме менеджера процесса и администратора АСУ ИТУ.

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

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

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

В случае если выполнение работ по применению постоянного решения проблемы не привело к устранению проблемы, осуществляется переход к выполнению шага «Анализ и диагностика проблемы», при этом проблема остается в статусе «В работе».

Чтобы определить, привело ли выполнение работ к решению проблемы, может потребоваться определённый период тестирования (или ожидания возникновения инцидентов, подобных возникавшим ранее). Критерии и период тестирования определяются аналитиком. На время тестирования проблема переводится в статус «Анализ решения». Время начала и окончания тестирования автоматически фиксируется в АСУ ИТУ.

После того, как аналитик убедился, что выполненные работы привели к решению проблемы, он закрывает проблему, изменяя её статус на значение «Закрыта».

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

l Решена (успешно проведены работы, устранившие корневую причину Инцидентов);

l Неактуальна (например, сбойная КЕ более не используется, была выведена из эксплуатации);

l Дублирование (при этом в комментарии к проблеме аналитик указывает номер проблемы, которая дублируется);

l Отклонена (не может быть причиной инцидентов).

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

6.8. Контроль

В рамках процедуры проводятся мероприятия по оперативному контролю исполнения процесса, выяснению нестандартных ситуаций.

Таблица 6.8.1. Действия аналитика в оперативном режиме

Таблица 6.8.2. Действия ответственного по группе в оперативном режиме

Таблица 6.8.3. Действия менеджера процесса в оперативном режиме

6.9. Формирование отчётности

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

l регулярные:

· отчёты для руководства (компании, службы ИТ);

· отчеты для менеджеров процессов (по показателям качества процессов);

· отчеты для ответственных по группе;

l специализированные.

Спецификация каждого отчёта должна включать:

l название отчёта;

l перечень используемых показателей;

l формат (внешний вид) отчёта;

l периодичность формирования;

l список и способ рассылки.

Спецификации отчётов утверждает менеджер процесса.

Все подготовленные отчёты должны унифицировано именоваться, храниться и распространяться.

Менеджер процесса утверждает следующие регулярные отчёты:

l базовый еженедельный отчёт;

l ежемесячный аналитический отчёт.

Базовый еженедельный отчёт

Отчет включает основные показатели работы процесса:

l количество зарегистрированных проблем;

l количество закрытых проблем.

По форме отчет должен содержать перечень показателей и их значений, а также информацию о ходе работ по проблемам.

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

Ежемесячный аналитический отчёт о работе процесса

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

Отчет должен включать выводы и рекомендации.

Отчет готовится ежемесячно и передается руководству службы ИТ в бумажном или электронном виде.

6.10. Оценка и совершенствование процесса

Основная задача данной процедуры — определение путей совершенствования процесса управления проблемами и его адаптация под происходящие в организации изменения.

Каждые 12 месяцев (или по требованию) процессу управления проблемами должна быть дана оценка.

Исходные данные:

l описание процесса управления проблемами;

l отзывы исполнителей процесса;

l показатели процесса и процедур;

l зарегистрированные в системе проблемы и задачи;

l стандартные отчёты.

Анализ процесса проводится менеджером процесса в ходе совещаний с обязательным участием менеджерных смежных процессов.

Результат:

l отчёт для руководства о работе процесса, включающий рекомендации по улучшению процесса.

Контроль исполнения рекомендаций по совершенствованию процесса возлагается на менеджера процесса.

Таблица 6.10.1. Ключевые показатели качества по процессу

Рис.6.10.1. Диаграмма жизненного цикла проблемы и известной ошибки

Таблица 6.10.2. Перечень статусов проблемы и известной ошибки

Рис.6.10.2. Диаграмма жизненного цикла задачи

Таблица 6.10.3. Перечень статусов задачи