Выбор ответа

Регистрация события

Авто ответ

Пример:

• Перезагрузка устройства

• Перезапуск услуги

• Передача задания в пакет

• Изменение значения параметра в устройстве

• Блокировка устройства или приложения

Сигнал предупреждения и человеческое вмешательство

Инцидент, проблема или изменение?

• Инцидент –в управление инцидентами

• Проблема –в управление проблемами

• Изменение – в управление изменениями

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

Процесс выполнения запросов

Основные понятия

Запрос на обслуживание (Service Request) – запрос от пользователя на предоставление информации или совета, на Стандартное изменение, или на Доступ к ИТ-услуге.

Модели запросов (Request Models) – это маршруты, заранее определяющие шаги по обработке запросов (Примечание: аналоги - маршрутизация, диспетчеризация).

Выполнение запросов (Request Fulfilment) – процесс ответственный за управление циклом жизни всех Запросов на обслуживание.

Цели процесса:

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

• Предоставлять информацию пользователям и Заказчикам о доступности услуг и процедур их получения.

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

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

Действия в рамках процесса:

• Выбор пункта из меню;

• Финансовое утверждение;

• Другие утверждения;

• Выполнение;

• Закрытие.

Схема процесса выполнения запросов

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

Основные понятия

Проблема (Problem) – неизвестная причина одного или более Инцидентов.

Во время создания записи о Проблеме причина инцидента (инцидентов) обычно неизвестна и процесс управления проблемами отвечает за ее исследование.

Обходной путь (Workaround) – снижение или устранение Влияния Инцидентов или Проблем, для которых еще невозможно их полное разрешение. Например с помощью рестарта отказавшей Конфигурационной единицы.

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

Известная ошибка (Known Error) – это Проблема, у которой задокументированы ее Корневая причина и Обходной путь.

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

Корневая причина (Root Cause) – основная или истинная причина Инцидента или Проблемы.

База известных ошибок (Known Error Database - KEDB) – база данных, содержащая все записи об известных ошибках.

Эта база данных создается в процессе Управления проблемами и используется процессами Управления инцидентами и Управления проблемами. База известных ошибок - это часть Системы управления знаниями об услугах.

Модели проблем (Problem Models) – это маршруты, заранее определяющие шаги для решения проблем. (Примечание: аналогия – маршрутизация, диспетчеризация)

Управление проблемами (Problem Management) – процесс, отвечающий за управления циклом жизни всех Проблем.

Ключевые цели Управления проблемами - это предотвращение Инцидентов, и минимизация влияния тех Инцидентов, которые не могут быть предотвращены.

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

• предотвращение проблем и инцидентов, возникающих вследствие этих проблем;

• устранение повторяющихся инцидентов;

• уменьшение влияния тех Инцидентов, которые не могут быть предотвращены.

Управление проблемами состоит из двух основных частей:

• реактивное Управление проблемами ( обычно реализуется как часть Эксплуатации услуг).

• проактивное Управление проблемами ( обычно реализуется как часть Постоянного улучшения услуг).

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

• Обнаружение проблемы;

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

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

• Назначение приоритета проблемы;

• Исследование и диагностика проблем;

• Обходной путь;

• Заведение записи об известной ошибке;

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

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

• Анализ крупных проблем.

Назначение приоритета проблеме

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

Необходимо учитывать серьезность проблемы для перспективы развития ИТ-инфраструктуры:

• Система может быть восстановлена или ее необходимо заменить?

• Сколько будет это стоить?

• Сколько специалистов, и с какой квалификацией, необходимо для определения проблемы?

• Сколько времени потребуется для определения проблемы?

• Насколько обширна проблема (например, как много компонент ИТ-инфраструктуры затронуто)?

Методы исследования и диагностики ПРОБЛЕМЫ:

• Хронологический анализ;

• Анализ ценности боли;

• Метод Кепнера и Трего;

• «Мозговой штурм» ;

• Диаграммы Ишикава;

• Анализ Парето.

Обходной путь

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

После нахождения обходного пути:

• Проблема остается открытой;

• Подробности обходного пути всегда документируются в записи о Проблеме.

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

• После нахождения решения проблемы при необходимости формируется Запрос на изменение, который передается в процесс Управления изменениями.

• Если проблема серьезная, может формироваться запрос на проведение срочного изменения.

• Во время рассмотрения Управлением изменениями способа решения проблемы должна использоваться база данных Известных ошибок.

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

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

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

• Должны быть также закрыты любые Записи об Инцидентах, связанных с этой проблемой

• Должна быть проверена полнота описания всех исторических событий по решению проблемы.

• Обновление записи об Известной ошибке.

Анализ крупных проблем

В результате анализа должны быть исследованы:

• Те вещи, которые были сделаны правильно.

• Те вещи, которые были сделаны неправильно.

• Что могло бы быть сделано в будущем лучше?

• Как предотвратить повторение?

• Была ли какая-нибудь ответственность третьей стороны и необходимы ли дополнительные меры?

Схема процесса реактивного управления проблемами

Взаимосвязи с другими процессами:

• Управление изменениями;

• Управление конфигурациями;

• Управление релизами и их развертыванием;

• Управление доступностью;

• Управление мощностями;

• Управление непрерывностью ИТ-услуг;

• Управление уровнями услуг;

• Управление финансами.