Problem Management ist nicht kaputt — es wurde nie wirklich implementiert

Ein Major Incident tritt ein. Der War Room wird aktiviert. Vierzig Leute in einer Telefonkonferenz. Nach vier Stunden ist der Service wiederhergestellt.

Jemand erstellt einen Problem Record.

Er bleibt dort liegen. Monatelang. Nicht zugewiesen. Keine Root Cause dokumentiert. Kein Known Error. Kein Change angestoßen. Bis der nächste Major Incident eintritt — verursacht durch dasselbe zugrundeliegende Problem — und der Kreislauf von vorne beginnt.

Kommt Ihnen das bekannt vor?

Das ist kein Versagen der ServiceNow-Plattform. Das Modul ist vorhanden. Es ist seit dem ersten Tag aktiviert.

Das ist ein Prozessversagen. Ein Verantwortlichkeitsversagen. Und es ist die teuerste einzelne Lücke in Ihrem ITSM-Programm.

Was „Problem Management haben" in den meisten Unternehmen wirklich bedeutet

Der Friedhof reaktiver Problem Records

Öffnen Sie jetzt Ihr Problem-Modul. Zählen Sie die Einträge.

In den meisten Unternehmen, in die ich hineingeschaut habe, finden Sie ein paar Dutzend. Vielleicht hundert. Fast alle reaktiv erstellt — das heißt, jemand hat einen Problem Record nach einem Major Incident angelegt, weil der Major Incident-Prozess das so vorschrieb.

Die meisten dieser Records sind im Status „offen". Kein Verantwortlicher. Seit Monaten keine Aktivität. Keine dokumentierte Root Cause Analysis. Sie existieren, um ein Häkchen zu setzen.

Das ist kein Problem Management. Das ist Problem Record-Erstellung. Der Unterschied ist gewaltig.

Die leere Known Error Database

Die Known Error Database (KEDB) soll eines der wertvollsten Wissens-Assets in Ihrem ITSM-Ökosystem sein.

Sie soll Service Desk-Agenten einen sofortigen Weg zu Workarounds bieten, wenn bekannte Probleme wiederkehren. Sie soll die Lösungszeit verkürzen, Eskalationen reduzieren und Wiederholungskontakte senken.

Schauen Sie jetzt in Ihre hinein.

In den meisten ServiceNow-Instanzen ist sie leer. Oder es gibt eine Handvoll Einträge aus einer initialen ITIL-Implementierung vor drei Jahren, die seitdem niemand mehr angefasst hat.

Eine leere KEDB bedeutet: Jedes Mal, wenn ein bekanntes Problem wiederkehrt, diagnostizieren Ihre Agenten es von Grund auf neu. Das sind reale Kosten. Reales Volumen. Reale Kundenunzufriedenheit.

Das fehlende Bindeglied zur Trendanalyse

Und jetzt kommt der Teil, der Sie am meisten beunruhigen sollte.

Problem Management ist nicht nur reaktive Untersuchung nach Major Incidents. Das ITIL-Framework ist hier eindeutig: Proaktive Problemidentifikation durch Trendanalyse ist die Hälfte des Prozesses.

Das bedeutet, dass jemand regelmäßig Incident-Daten auswerten sollte — wiederkehrende Kategorien, wiederkehrende Configuration Items, wiederkehrende Assignment Groups — und Problem Records eröffnen sollte, bevor ein Major Incident die Sache erzwingt.

In fast jeder ServiceNow-Instanz, die ich bewertet habe, macht das niemand. Nicht, weil die Daten fehlen. Sie sind da. Die Incident Records existieren. Die CMDB-Beziehungen existieren. Die Reporting-Fähigkeiten existieren.

Niemand tut es, weil niemandem gesagt wurde, dass es seine Aufgabe ist.

Warum das passiert — es ist kein ServiceNow-Konfigurationsproblem

Keine dedizierte Problem Manager-Rolle

Das ist die Root Cause der Root-Cause-Lücke.

Incident Management hat in den meisten Organisationen einen klar definierten Verantwortlichen. Change Management hat ein CAB, ein Advisory Board, einen Process Owner. Selbst Request Fulfillment hat jemanden, der ein Auge darauf hat.

Problem Management? Es wird üblicherweise als Nebenverantwortung jemandem zugewiesen, der bereits in Incident-Koordination oder Change-Überwachung ertrinkt. Es wird jede einzelne Woche nach hinten geschoben. Weil Incidents dringend sind. Probleme sind wichtig.

Dringend gewinnt immer, wenn Governance fehlt.

Incident Management saugt den gesamten Sauerstoff ab

Incident Management ist sichtbar. Es hat SLAs. Es hat Dashboards. Es hat die Aufmerksamkeit der Geschäftsführung bei Ausfällen.

Problem Management ist von Natur aus unsichtbar. Sein Wert zeigt sich in Dingen, die nicht passiert sind — der Major Incident, der nicht wiederkehrte, das Ticketvolumen, das schrittweise sank, die Eskalationen, die aufhörten.

Das macht es unglaublich schwer, Budget, Headcount und Management-Aufmerksamkeit zu bekommen. Also bekommt es nichts davon.

Root Cause Analysis wird als einmalige Aktion behandelt, nicht als Disziplin

Wenn Organisationen tatsächlich eine Root Cause Analysis durchführen, dann fast immer unmittelbar nach einem Major Incident. Ein Post-Incident Review findet statt. Ergebnisse werden in einem Word-Dokument oder auf einer SharePoint-Seite festgehalten. Vielleicht werden ein paar Maßnahmen zugewiesen.

Aber diese Ergebnisse finden selten den Weg zurück ins ServiceNow Problem-Modul als strukturierte Daten. Sie werden nicht zu Known Errors. Sie erzeugen keine Change Requests. Sie fließen nicht in einen Trendanalyse-Kreislauf ein.

Root Cause Analysis ohne strukturierte Nachverfolgung ist nur ein teures Gespräch.

Wie echtes Problem Management auf der Now Platform aussieht

Proaktive Problemidentifikation aus Incident-Trends

Echtes Problem Management beginnt vor dem Major Incident.

Jemand — ein namentlich benannter Problem Manager oder ein Problem-Analyse-Team — wertet regelmäßig Incident-Daten aus. Wöchentlich oder zweiwöchentlich. Sie suchen nach Mustern: dasselbe CI taucht wiederholt auf, dieselbe Kategorie schnellt hoch, dieselbe Assignment Group wird überlastet.

ServiceNow liefert Ihnen die Werkzeuge dafür out of the box. Incident-Trendberichte. CMDB-verknüpfte Dashboards. Performance Analytics, wenn Sie die Lizenz dafür haben. Selbst einfache Listenansichten und gruppierte Berichte können diese Muster sichtbar machen.

Das Tool ist nicht der Engpass. Der Rhythmus und die Rolle sind es.

Eine lebendige Known Error Database, die Tickets abfängt

Jede abgeschlossene Root Cause Analysis sollte eines von zwei Ergebnissen liefern: einen Known Error mit dokumentiertem Workaround oder einen Change Request zur Behebung des zugrundeliegenden Problems.

Wenn Known Errors in ServiceNow sauber dokumentiert sind, werden sie für Service Desk-Agenten bei der Incident-Erstellung durchsuchbar. Sie können mit aktiven Incidents verknüpft werden. Sie können über den Virtual Agent oder die Employee Center-Suche ausgespielt werden.

Das ist echte Ticket-Deflection. Kein Chatbot-Deflection-Theater. Tatsächliche Reduzierung von Diagnosezeit und wiederholten Eskalationen, weil die Antwort bereits im System existiert.

Nachverfolgbarkeit von Problem zu Change

Das Problem-Modul in ServiceNow hat native Beziehungen zu Change Management. Ein Problem Record kann einen Change Request erzeugen. Dieser Change Request kann durch den CAB-Prozess verfolgt werden. Der Problem Record wird geschlossen, wenn der zugrundeliegende Fix deployed und validiert ist.

Diese Nachverfolgbarkeit ist der Beweis, dass Problem Management funktioniert. So zeigen Sie, dass eine Root Cause identifiziert, ein Fix geplant, der Fix deployed und das Problem nicht wiedergekehrt ist.

Ohne diese Verknüpfung hat Problem Management keinen messbaren Output. Und Prozesse ohne messbaren Output sterben.

Die Konfigurations- und Governance-Muster, die es nachhaltig machen

Fünf konkrete Maßnahmen für echtes Problem Management

1. Benennen Sie einen Problem Manager. Keine geteilte Verantwortung. Eine namentlich zugewiesene Rolle. Diese Person verantwortet den Prozess, steuert den Rhythmus und ist rechenschaftspflichtig für den Problem Record-Durchsatz und die KEDB-Qualität. Wenn Sie keine Vollzeitstelle rechtfertigen können, starten Sie mit einer dedizierten 50%-Zuweisung aus Ihrem ITSM-Team.

2. Etablieren Sie einen Problem Review-Rhythmus. Wöchentlich oder zweiwöchentlich. Der Problem Manager prüft offene Probleme, wertet Incident-Trenddaten aus und identifiziert neue Kandidaten für proaktive Problemuntersuchung. Tragen Sie es in den Kalender ein. Schützen Sie den Termin.

3. Erstellen Sie ein Incident-Trend-Dashboard. Konfigurieren Sie ein Dashboard in ServiceNow, das wiederkehrende Incidents nach Kategorie, CI, Assignment Group und Service sichtbar macht. Das erfordert kein Performance Analytics. Standard-Reporting und Dashboards reichen dafür aus. Machen Sie es zum Startpunkt jedes Problem Review-Meetings.

4. Erzwingen Sie den Known Error-Workflow. Jeder Problem Record, der eine Root Cause Analysis abschließt, muss entweder einen Known Error Record oder einen Change Request erzeugen. Machen Sie das zu einem Prozess-Gate. Wenn keines von beiden existiert, darf der Problem Record nicht in den Status „gelöst" wechseln. Sie können das mit einer einfachen UI Policy oder Business Rule durchsetzen.

5. Reporten Sie über Problem-to-Change-Abschlüsse. Verfolgen Sie die Anzahl der Probleme, die Changes ausgelöst haben, die Anzahl der Changes, die deployed wurden, und die Incident-Wiederkehrrate für diese CIs nach dem Fix. Das ist Ihre ROI-Story.

Reporting, das Verantwortlichkeit schafft

Drei Reports werden das Gespräch mit Ihrem Leadership verändern:

• Alterung offener Probleme: Wie lange liegen Problem Records ohne Aktivität herum? Das legt den Friedhof offen.
• Known Error-Abdeckung: Für wie viele Ihrer am häufigsten wiederkehrenden Incident-Kategorien gibt es einen entsprechenden Known Error? Das legt die KEDB-Lücke offen.
• Erfolgsrate von Problem-initiierten Changes: Wie viele der Changes, die aus Problem Records entstanden sind, haben das zugrundeliegende Problem gelöst? Das beweist den Wert.

Legen Sie diese Reports Ihrem ITSM-Director oder VP IT monatlich vor. Das Gespräch wird sich verändern.

Der ROI, über den niemand spricht

Alle fixieren sich auf Incident Management und Change Management. Sie sind sichtbar. Sie sind auditierbar. Sie haben SLAs.

Aber keiner dieser Prozesse reduziert Arbeit.

Incident Management stellt den Service wieder her. Es verhindert nicht den nächsten Ausfall. Change Management kontrolliert Risiken. Es beseitigt nicht die Ursache des Risikos.

Problem Management ist der einzige ITSM-Prozess, der darauf ausgelegt ist, das Gesamtvolumen der Arbeit über die Zeit zu reduzieren. Weniger wiederkehrende Incidents. Weniger Major Incidents. Weniger Eskalationen. Geringeres Service Desk-Kontaktvolumen.

Es ist die ITSM-Investition mit dem höchsten ROI, die die meisten Organisationen jemals tätigen werden. Und es liegt seit Jahren ungenutzt in Ihrer Instanz.

Das Modul ist da. Die Daten sind da. Die Plattform-Fähigkeiten sind da.

Was fehlt, ist die Rolle, der Rhythmus und die Governance, um es zum Leben zu erwecken.

Wenn Ihr Problem Management-Prozess aus einer Handvoll veralteter Records und einer leeren Known Error Database besteht, haben Sie kein ServiceNow-Problem.

Sie haben ein Leadership-Problem.

Und es ist lösbar.