Проактивное управление проблемами

В редакцию портала поступил вопрос:

Добрый день!

Вопрос по проактивному управлению проблемами.

Поддержка, которая решает инциденты, может создавать отдельные запросы на вендора.

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

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

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

Новые обращения должны привязываться к проблеме или же к запросу, в рамках которого решается проблема?

Имеет ли смысл выделять главный инцидент, к которому привязываются инциденты с такой жен проблемой? Главный инцидент привязывать к проблеме (или к запросу на вендора)?

Спасибо

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Лилия (менеджер процесса PrbM)

    Добрый день!

    Если не крит. Мы делаем так: инциденты связываются с одной Проблемой, в Проблеме есть поле, в котором указывается тикет (баг, запрос на изменение), в вашем случае это будет запрос вендору. Таким образом, инциденты привязываются только к Проблеме.

  2. Виктор

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

    Но только оставить её надо было на своей стороне, а не на стороне вендора. Проблема на стороне вендора — лишь гипотеза, поэтому в рамках вашей проблемы нужно проработать разные варианты. Сюда же будете добавлять и обходные/временные решения.

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

  3. Игорь Гутник

    Каждая из описываемых сущностей (инцидент, проблема, запрос вендору), по идее, является объектом управления (в противном случае зачем мы их описываем?)

    В классической картине запись об инциденте (INC) — объект управления процесса/практики управления инцидентами, а запись о проблеме (PRB) — объект управления процесса/практики управления проблемами. Жизненный цикл каждого из этих объектов понятен (например, у INC это может быть: идентификация, регистрация, категоризация, приоритизация, диагностика, решение, закрытие). Хотя, разумеется, может иметь специфику в каждой конкретной реализации.

    Что такое в данном случае «запрос на вендора»? Каков его жизненный цикл? Это просто документирование коммуникаций с вендором? Как вы планируете использовать эту информацию? Может ли быть несколько запросов к вендору по одной проблеме? Или это часть жизненного цикла PRB, начиная с момента эскалации на вендора? Тогда зачем нужна эта отдельная сущность? Как вы планируете управлять этой частью работ?

    Думаю, в зависимости от понимания этой картины, «правильным» моет быть любой ответ.

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

  4. Андрей Вишняков

    Важно понимать, что запись о проблеме регистрируется только тогда, когда корневая причина инцидента(ов) действительна неизвестна. Если есть понимание — что это вендор, зачем вообще создавать запись о проблеме?

    1. Игорь Гутник

      Андрей, привет!

      А если RCA — не единственный механизм, работающий в управлении проблемами?

      Например, может понадобиться проанализировать решение, найденное (например, в рамках решения инцидента(ов)), на предмет оптимальности/рисков и т.п.

      Т.е. предположим для примера, что RC в рамках INC найдена верно. Но есть потребность убедиться в том, что применённое решение — ОК.

Добавить комментарий

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ИЮН
8
ИЮН
10
ИЮН
15
Учебный курс:
ITIL® 4 Strategist: Direct, Plan & Improve