Es gibt zwei Auslöser für die Einleitung des Problemmanagement-Prozesses: a) die Beobachtung, dass ein Prozess nicht innerhalb der Spezifikation liegt oder ausfällt, ohne dass eine Ursache bekannt ist, und b) dass es für das Unternehmen einen Nutzen hat, diese Grundursache zu finden und zu beseitigen.
Je früher der Prozess angestoßen wird, desto besser – idealerweise, bevor ein Incident auftritt (proaktives PM). Bei Incidents mit einem ausreichend hohen Ausmaß an Auswirkungen, sodass Bedingung b) erfüllt ist, und unbekannter Ursache ist es sinnvoll, das PM zu starten, während das Incident-Team an der Wiederherstellung arbeitet. Die Wiederherstellungsaktivitäten werden die Daten voraussichtlich verfälschen, sodass das Finden der Ursache erschwert oder unmöglich wird; daher ist es hilfreich, die Bedingungen zu erfassen, solange der Incident noch aktiv ist. Das kann auch bei Incidents mit geringerer Auswirkung zutreffen, insbesondere wenn sie sich häufig genug wiederholen, um insgesamt eine erhebliche Störung zu verursachen.
Die Aktivitäten parallel durchzuführen ist einfach, sofern Sie die Prozesse gemeinsam konzipiert haben. Wenn die Teams getrennt sind und jeweils ihr eigenes Vorgehen haben, sind Verwirrung und Konflikte unvermeidlich. Denken wir daran, dass ITIL nie vorgeschrieben hat, dass wir separate Problem- und Incident-Teams haben sollten. Es gibt kaum oder gar keine Belege, die die Wirksamkeit einer Trennung (oder einer Zusammenlegung der Funktionen) stützen. ITIL sagt sinnvollerweise, dass zwei Prozesse zu befolgen sind; mein Vorschlag ist, dass ein gewisses Maß an Integration hilfreich ist. So kann ein integrierter Prozess funktionieren:
