Не секрет, что диагностика и поиск решения проблем весьма ресурсоемкая задача и если проблемы выявляются и поступают на обработку, то рано или поздно возникнет задача расстановки приоритетов.
Если предположить, что связь между процессом управления инцидентами и проблемами работает, и к проблемам привязываются инциденты, то одним из способов расстановки приоритетов может быть оценка количества привязанных к проблеме инцидентов, с учетом их весов, которые в свою очередь могут зависеть от степени влияния инцидента. Т.е. приоритет проблемы тем выше, чем больше сумма весов инцидентов, привязанных к проблеме.
Таким образом, проблема, вызвавшая пару инцидентов с уровнем влияния "Критичный", будет иметь больший приоритет, чем проблема, к которой привязано несколько инцидентов с уровнем влияния "Низкий". При этом, могут быть ситуации, когда количество инцидентов с уровнем влияния "Низкий" станет настолько большим, что суммарный вес этих инцидентов станет больше, чем вес пары инцидентов с уровнем влияния "Критичный". Такая ситуация укладывается в нашу обычную логику.
При этом конечно все дело в магических "Весах" инцидентов и схеме определения уровней влияния, точнее в ее точности. Поэтому, как мне кажется, для таких инцидентов в обязательном порядке должна выполняться проверка корректности уровня влияния при закрытии инцидента.
Есть конечно у этой схемы один существенный недостаток – она зависит от предположения, что "связь между процессом управления инцидентами и проблемами работает и к проблемам привязываются инциденты". На этапе создания проблемы привязка обычно делается для подтверждения необходимости регистрации проблемы, но этого мало. В идеале инциденты должны привязываться до тех пор пока проблема не закрыта и факт привязки новых инцидентов может поднять приоритет проблемы.
А вот кого заставить осуществлять привязку – большой вопрос, т.к. решающим инциденты эта привязка ничего не дает, а тем кто занят проблемой не до отслеживания потока инцидентов.
Возможно, я не до конца понял идею, но пока мне кажется так:
Цель определения приоритета проблем в описанной ситуации – решение о порядке выделения ресурсов на диагностику, выявление ошибок и поиск решений. Следствием такого решения будет выделение (или не-) определенного времени определенных специалистов на проведение диагностики и, возможно, формирование очереди проблем, подлежащих обработке. Маловероятно, что эта очередь будет состоять из десятков проблем, скорее из единиц.
Если так, то актуализация данных о влиянии в реальном времени (привязка новых инцидентов к старым проблемам) не очень нужна, а если и нужна, то может проводиться не онлайн, а, скажем, раз в несколько дней – при перестройке очереди.