Auch wenn der Unterschied zwischen Incident Management und Problem Management auf den ersten Blick gering erscheinen mag, ist er tatsächlich erheblich. Deshalb ist es wichtig zu verstehen, was die beiden im IT-Umfeld voneinander trennt.

Warum ist es wichtig, den Unterschied zwischen Problemen und Incidents zu kennen?

Oberflächlich betrachtet können ein „Incident“ und ein „Problem“ gleich wirken. Im allgemeinen Sprachgebrauch können beide eine Situation beschreiben, die sich negativ auf ein Unternehmen auswirkt. In der IT sind die beiden Begriffe jedoch sehr unterschiedlich und müssen entsprechend – mit unterschiedlichen Zielen – behandelt und gemanagt werden. Kurz gesagt: Incident Management und Problem Management sind nicht dasselbe.

In seiner grundlegendsten Definition ist ein Incident ein einzelnes, eigenständiges Ereignis. Incidents sind häufig Ereignisse oder Störungen, bei denen Anwender ein IT-Helpdesk-Ticket eröffnen und erwarten, dass die IT es schnell behebt. Ein Problem ist die Ursache von Incidents. Problem Management versucht, Incidents zu verhindern, indem es die zugrunde liegenden Gründe adressiert, die wiederkehrende Incidents verursachen können.

Stellen Sie sich folgendes Incident-vs.-Problem-Szenario vor: Ein Speditionsunternehmen betreibt eine Fahrzeugflotte. Bei einem seiner Lkw kann ein Reifen platzen, der schnell gewechselt werden muss, damit das Fahrzeug wieder auf die Straße kann. Dieses Ereignis ist ein Incident, weil es isoliert ist und nur diesen einen Lkw betrifft. In diesem Fall bedeutet Incident Management, den Reifen zu wechseln, damit der Lkw so schnell wie möglich wieder einsatzbereit ist.

Aus platten Reifen kann ein Thema für das Problem Management werden, wenn sie wiederholt oder häufiger auftreten, als vernünftigerweise zu erwarten wäre. In diesem Fall würde das Speditionsunternehmen weiter untersuchen, um die Ursache für die überdurchschnittlich vielen platten Reifen zu ermitteln.

Welches Problem liegt diesen Incidents zugrunde? Möglicherweise unterliegen genau diese Reifen einem Rückruf. Oder der Wartungsplan für die Reifen wird nicht eingehalten, wodurch häufiger Reifenpannen entstehen. Oder die Fahrer nutzen eine Route mit Gefahren auf der Fahrbahn – etwa Bauschutt –, die die Reifenpannen verursacht.

Durch die Identifizierung dieser zugrunde liegenden Ursache kann das Unternehmen Maßnahmen umsetzen, um künftige damit verbundene Incidents zu verhindern.

Grundprinzipien, die für die Behebung von Störungen unerlässlich sind

Diese Grundprinzipien werden von der IT genutzt, um Incidents und Probleme korrekt zu identifizieren und angemessen zu behandeln. Deshalb ist es für Geschäftsinhaber und Führungskräfte außerhalb der IT wichtig, den Unterschied zwischen einem Incident und einem Problem zu verstehen – und zu wissen, wann Incident Management und wann Problem Management anzuwenden ist.

Auch wenn die Begriffe austauschbar erscheinen mögen: Eine klare Kommunikation in der Fachsprache des IT-Supports hilft, Verwirrung und Frustration zu reduzieren. Wenn Sie dem IT-Support melden, Sie hätten einen Incident, obwohl es sich tatsächlich um ein weitreichenderes Problem handelt, bleibt die zugrunde liegende Ursache möglicherweise unbehandelt – mit künftigen Schwierigkeiten als Folge.

Das Verständnis des Unterschieds kann der Organisation helfen, schneller zu einer angemessenen Lösung zu gelangen.

Betrachten wir IT-Incident Management und Problem Management genauer. Beide sind ITIL-Prozesse, die in Unternehmen verschiedenster Branchen häufig eingesetzt werden.

Was ist Incident Management?

Um Incident Management und Problem Management voneinander abzugrenzen, betrachten wir zunächst das IT Incident Management. Sein Ziel: den Servicebetrieb so schnell wie möglich wiederherzustellen und die Auswirkungen eines Ausfalls oder einer Servicebeeinträchtigung zu minimieren. In der Praxis zeigt sich das daran, dass der IT-Support-Desk auf die Fehlerbehebung einzelner Tickets fokussiert ist – manchmal mit einem Workaround statt einer echten Lösung.

Die mit dem Incident Management verbundenen Aktivitäten konzentrieren sich vor allem darauf, die Details des Incidents zu erfassen, ihn zu klassifizieren, zu untersuchen und den Incident letztlich zu beheben.

Die Strategie und der Prozess, die wirksamem Incident Management zugrunde liegen, finden sich auch in vielen Bereichen außerhalb der IT. Zur Veranschaulichung, wie Incident Management funktioniert, stellen wir uns vor, wir hätten Rückenschmerzen. Gutes Incident Management sollte wie eine gut organisierte Arztpraxis funktionieren.

Bei unserem ersten Besuch beim Orthopäden füllen wir Formulare aus, um den Kontext unserer allgemeinen Gesundheit anzugeben und unsere Symptome detailliert zu beschreiben. Unser Arzt nutzt diese Informationen zusammen mit einer Röntgenaufnahme, um eine Diagnose zu stellen und einen Behandlungsplan zu verschreiben.

Der Arzt hat den Incident (die Rückenschmerzen) gründlich dokumentiert, untersucht und einen wirksamen Plan umgesetzt, um das Problem schnell und effektiv zu beheben.

Die Incident-Management-Funktion im Unternehmen

In Geschäftsumgebungen sind viele Incidents IT-bezogen. Unabhängig davon, ob eine IT-Organisation an ITIL ausgerichtet ist oder nicht, gibt es fast immer eine Rolle oder Funktion, die für das Management von Incidents verantwortlich ist – ganz gleich, ob es sich um ein Team von zwei oder zweihundert Personen handelt.

Die Ziele und Key Performance Indicators (KPIs) für das Incident Management sind relativ eindeutig:

  • Den Incident so schnell wie möglich beheben.
  • Die Priorität des Incidents berücksichtigen.
  • Die Kosten der Lösung berücksichtigen.
  • Die Zufriedenheit der Anwender während des gesamten Prozesses bewerten.
  • Ergebnisse anhand konkreter Kennzahlen messen, beispielsweise Erstkontaktlösung, Kosten pro Kontakt und Kundenzufriedenheit.

Wenn ein Incident nicht isoliert zu sein scheint, müssen IT-Teams ihn möglicherweise an das Problem-Management-Team eskalieren.

Was ist Problem Management?

Der nächste Schritt bei der Definition von Incident Management vs. Problem Management besteht darin, zu betrachten, wie Problem Management innerhalb der IT funktioniert. Sein Ziel ist es, die negativen Auswirkungen von Incidents und Problemen zu minimieren, die durch Fehler in der Infrastruktur verursacht werden, und das Wiederauftreten von Incidents im Zusammenhang mit diesen Fehlern zu verhindern.

Die mit dem Problem Management verbundenen Aktivitäten konzentrieren sich vor allem darauf, zu ermitteln, warum der Incident überhaupt entstanden ist, sowie bekannte Fehler zu identifizieren und zu dokumentieren.

Anders als beim Incident Management gibt es häufig keine Rolle oder Funktion, die für das Problem Management verantwortlich ist (dies geht über den IT-Support-Desk hinaus, der auf Incident Management fokussiert ist). Ebenso besteht nicht immer ein solides Verständnis der damit verbundenen Ziele und Key Performance Indicators.

Unternehmen müssen bewusst einen zusätzlichen Schritt gehen, um Problem Management einzuführen, Ressourcen dafür bereitzustellen und die erwarteten Ergebnisse sowie die KPIs zu definieren, die am besten zu ihrer Organisation passen.

Problem Management in der Praxis

Kehren wir zur Analogie mit den Rückenbeschwerden zurück, um zu verstehen, wie Problem Management – wenn es gut umgesetzt wird – wie eine umfassende Behandlung funktioniert.

Während der Arzt zunächst eine gewisse unmittelbare Linderung verschafft hat (indem er den Incident behandelt hat), könnte er darauf hinweisen, dass es sich um etwas Schwerwiegenderes handeln kann, wenn der Behandlungsplan nicht wirkt und der Patient weiterhin Schmerzen hat. In diesem Fall wären ein MRT und weitere Analysen erforderlich.

Wichtig ist: Das schmälert nicht die ursprüngliche Arbeit des Arztes. Er konnte keine unmittelbare endgültige Lösung bieten, sondern einen Workaround (Medikamente und Übungen bei gleichzeitiger Einschränkung von Reisen), den er zuvor identifiziert und dokumentiert hatte, da er ähnliche Beschwerden bereits in der Vergangenheit gesehen hatte. Er empfahl beim ersten Besuch keine Operation, weil er wusste, dass sie weder kosteneffizient noch angemessen ist, solange die Ursache nicht bestimmt wurde.

Den Unterschied zwischen Incident Management und Problem Management zu verstehen, ist lediglich der erste Schritt. Die Analogie mit der Arztpraxis hilft uns zu verstehen:

  • Incident Management befasst sich so schnell wie möglich mit einem einzelnen Incident.
  • Problem Management befasst sich damit, warum der Incident (oder mehrere ähnliche Incidents) aufgetreten ist.

Letzteres zielt darauf ab, entweder die Ursache zu beseitigen oder einen wirksamen, leicht einsetzbaren Workaround zu schaffen.

Was erfordert die Behebung eines Incidents?

Der nächste Bereich, den wir beim Vergleich von Incident Management und Problem Management betrachten sollten, sind die vorhandenen Strukturen oder Praktiken, mit denen Incidents und Probleme tatsächlich „gemanagt“ werden können.

Wie bereits erläutert, muss jede Organisation mindestens einige Personen oder ein Team haben, das für Incident Management und Incident-Behebung zuständig ist (wahrscheinlich ein IT-Support-Desk oder das Team, das IT-Support-Tickets bearbeitet).

Ohne klar zugewiesene Verantwortliche werden Incidents möglicherweise nicht schnell, effektiv oder konsistent behoben. Neben einem bestehenden Team gibt es einige Schlüsselfaktoren für erfolgreiches Incident Management, insbesondere bei IT- und betriebsbezogenen Incidents.

Damit Incident Management effektiv ist, müssen die folgenden Anforderungen erfüllt werden:

  • Kontinuierliche Weiterentwicklung der Problem- und Fehlerkontrolle.
  • Eine mehrstufige Supportstruktur, in der das Team Eskalationen auf Tier 1 und 2 versteht.
  • Ein Programm zur kontinuierlichen Serviceverbesserung, das Effizienz und Effektivität anhand von KPIs misst, die an den Zielen der Organisation ausgerichtet sind.
  • Klare, dokumentierte Rollen und Verantwortlichkeiten innerhalb der IT in Bezug auf die gewünschten Ergebnisse.

Darüber hinaus muss der IT eine robuste Incident-Management-Software zur Verfügung stehen, die Folgendes umfasst:

  • Integration der IT-Service-Desk-Software und des IT-Asset-Management-Repositorys. Diese Integration stellt dem IT-Support Kontext zu den Assets und Services bereit, die der Anwender nutzt, und macht das Ausfüllen von Formularen überflüssig.
  • Eine Wissensdatenbank im ITSM-Tool, die dabei hilft, Symptomatiken zu verbreiten, zu skalieren und zu standardisieren. Die Wissensdatenbank unterstützt den IT-Support dabei, schneller zu arbeiten und teamweit Konsistenz zu gewährleisten.
  • Die Ansicht einer IT-Service-Map, die von der Configuration Management Database (CMDB) der ITSM-Lösung bereitgestellt wird. Service-Maps helfen der IT zu verstehen, was auf Serviceebene geschieht, und problematische Configuration Items, die Verfügbarkeit und Performance beeinträchtigen, besser zu isolieren.

Diese Tools und Prozesse erleichtern es der IT oder dem Service Desk, die benötigten Informationen mit dem passenden Kontext zu erfassen, um den Incident und seine Auswirkungen vollständig zu verstehen.

Das führt zur zweiten Phase der Behebung eines Incidents: Kategorisierung und Priorisierung. Nicht alle Incidents haben dieselben Auswirkungen auf eine Organisation, und diejenigen, die die größten Störungen verursachen, müssen zuerst adressiert werden (z. B. ein nicht funktionierender interner Drucker im Vergleich zu einem nicht erreichbaren Kundenportal, das mit Service Level Agreements (SLAs) des Unternehmens verknüpft ist).

Was erfordert die Behebung eines Problems?

Die Integration von Changes, Assets und Wissen schafft Mehrwert für den Incident-Management-Prozess und damit für die Organisation. Warum sehen wir also einen so starken Rückgang, wenn es um den Problem-Management-Prozess geht?

Eine Studie von ITSM.tools aus dem Jahr 2022 ergab, dass nur 38 % der Organisationen Problem-Management-Prozesse eingeführt hatten. Man könnte argumentieren, dass die geringe Verbreitung von Problem Management meist auf ein mangelndes Verständnis dafür zurückzuführen ist, warum Problem Management für die Organisation wichtig ist. Dies wirkt sich auf die Ausrichtung der mit dem Prozess verbundenen Rollen und Verantwortlichkeiten aus.

Hinzu kommt häufig eine zu starke Abhängigkeit von Technologie: Sie erstellt Problem-Datensätze und weist Verantwortlichkeiten zu, kann aber nicht aus sich heraus Menschen dazu motivieren, Ursachen zu ermitteln, Workarounds zu identifizieren und Lösungsansätze zu empfehlen.

Das Verständnis des Incidents und seiner Auswirkungen hilft IT-Teams dabei, die richtigen Ressourcen und Prioritäten zuzuweisen.

Sobald die IT davon ausgeht, den Incident behoben oder einen Workaround bereitgestellt zu haben, sollte sie bei den Endanwendern nachfragen, ob die Lösung wie vorgesehen funktioniert und keine weiteren Pain Points bestehen.

Das Problem mit dem Problem Management

Um erfolgreiche Problem-Management-Prozesse aufzubauen, muss die IT zunächst bestimmen, warum der Prozess für sie wichtig ist (Reduzierung künftiger Incidents, Minimierung von Ausfallzeiten, Verbesserung der Infrastruktur usw.) und die Rollen und Ressourcen entsprechend zuweisen.

IT-Führungskräfte müssen mindestens dieselbe Sorgfalt anwenden wie beim Incident Management.

Eine für Problem Management verantwortliche Führungskraft muss sicherstellen, dass:

  • Probleme und Fehler regelmäßig (und korrekt) klassifiziert und identifiziert werden.
  • Workarounds dokumentiert und an die Incident-Management-Funktion kommuniziert werden.
  • Der Problem-Management-Prozess über klar definierte und relevante KPIs verfügt (entsprechend der Organisation und ihren Zielen für das Problem Management).
  • Rollen und Verantwortlichkeiten klar und dokumentiert sind.

Die IT muss außerdem sicherstellen, dass sie über die passende unterstützende ITSM-Lösung mit dedizierten Problem-Management-Funktionen verfügt, die Folgendes leistet:

  • Umfassende Incident-Dashboards und filterbare Tabellen mit Incident-Datensätzen bereitstellen, die Problem Manager in die Lage versetzen, ähnliche wiederkehrende Incidents zu erkennen und zu isolieren.
  • Die Details des Incidents sowohl mit der Wissensdatenbank als auch mit der Known-Error-Datenbank abgleichen, damit Incident-Datensätze leichter mit Problem-Datensätzen verknüpft werden können.
  • Die Zuweisung der Verantwortung für Problem-Datensätze an Einzelpersonen oder Funktionsgruppen vereinfachen.
  • Die schnelle Überführung von Problemen in einen Request for Change (RFC) erleichtern – einschließlich des gesamten erforderlichen Kontexts und der Dokumentation.
  • Ein vollständiges und aussagekräftiges Dashboard bereitstellen, das kritische Problem-Management-Kennzahlen intuitiv in einem einzigen Panel organisiert.

Problem Management ist sowohl ein reaktiver als auch ein proaktiver Prozess. Incident Analysts können wiederkehrende Incidents identifizieren und als reaktive Maßnahme Problem Requests einreichen. Die eigentliche Stärke des Problem Managements zeigt sich, wenn Problem-Management-Teams sorgfältig nach potenziellen Problemen oder Schwachstellen in der Infrastruktur suchen, die noch keine Incidents verursacht haben, dies aber künftig wahrscheinlich tun werden. Dies ist ein wichtiger Bestandteil eines wirklich effektiven Problem-Management-Ansatzes, und es gibt Möglichkeiten, ihn dabei zu unterstützen.

Probleme gelten als gelöst, wenn eine Lösung implementiert wurde oder ein gut dokumentierter und kommunizierter Workaround vorhanden ist und die Incidents nicht mehr auftreten.

Incident Management vs. Problem Management: Es ist entscheidend, den Unterschied zu kennen

Beim Vergleich von Incident Management und Problem Management müssen wir anerkennen, dass sie sich ähneln – so sehr, dass viele ITIL-Neulinge Schwierigkeiten haben, die beiden zu unterscheiden. Es gibt jedoch einen entscheidenden Unterschied, und der liegt im letztendlichen Ziel.

Wir sollten uns vor Augen führen, dass Incident Management darauf abzielt, einen Incident schnell und effektiv zu beheben und dabei negative Auswirkungen zu minimieren. Von dort aus können Supportteams zum Problem Management übergehen, mit dem Ziel, das erneute Auftreten ähnlicher Incidents zu verhindern, indem die zugrunde liegende Ursache adressiert wird.

Für Geschäftsinhaber und Führungskräfte kann das Verständnis des Unterschieds zwischen einem IT-Incident und einem Problem dazu beitragen, effektiv mit dem IT-Support zu kommunizieren und realistische Erwartungen an die Ergebnisse zu formulieren.

Letztlich geht es weniger um Incident Management vs. Problem Management, sondern vielmehr darum, wie sich beide ergänzen. Effektives Incident Management und Problem Management umzusetzen, kann komplex sein – insbesondere, wenn Ihre Organisation neu mit ITIL arbeitet. Entscheidend ist, sich auf die gewünschten Ergebnisse zu konzentrieren und die Prozesse zu finden, die für Ihr Unternehmen und Ihr Team am besten funktionieren.