asyoube logo asyoube

Incident, Problem und Change

5 min 3 Abschnitte
Was du nach diesem Konzept kannst 4

  1. Du bist in der Lage, die Beziehungen zwischen Incident, Problem und Change Management zu interpretieren ,

    indem die Schnittstellen und Abhängigkeiten zwischen den Prozessen analysiert und deren Bedeutung für die kontinuierliche Verbesserung der IT-Services dargestellt werden.

  2. Du bist in der Lage, das Konzept eines Incidents zu erklären ,

    indem die Definition, die Abgrenzung zu anderen Ereignissen und die typischen Schritte im Incident Management Prozess (Erfassung, Klassifizierung, Priorisierung, Bearbeitung, Abschluss) anhand konkreter Beispiele dargestellt werden.

  3. Du bist in der Lage, das Konzept eines Problems zu erklären ,

    indem die Definition, die Abgrenzung zu Incidents und die typischen Schritte im Problem Management Prozess (Identifizierung, Analyse, Lösung, Abschluss) anhand konkreter Beispiele dargestellt werden.

  4. Du bist in der Lage, das Konzept eines Changes zu erklären ,

    indem die Definition, die verschiedenen Arten von Changes (Standard, Normal, Emergency) und die typischen Schritte im Change Management Prozess (Antrag, Bewertung, Genehmigung, Umsetzung, Abschluss) anhand konkreter Beispiele dargestellt werden.

Was ist ein Incident und wie wird er behoben?

Vom unvorhergesehenen Ausfall zur schnellen Lösung

Stell dir vor, das zentrale Kassensystem in einer Filiale fällt mitten im Tagesgeschäft aus. Dieses ungeplante Ereignis ist ein klassischer Incident (Störung). Ein Incident ist definiert als eine unvorhergesehene Unterbrechung oder eine spürbare Qualitätsminderung eines IT-Services.

Das oberste Ziel im Incident Management ist immer die schnellstmögliche Wiederherstellung des normalen Betriebs. Oft geschieht dies durch einen temporären Workaround (Umgehungslösung), wie beispielsweise den simplen Neustart des Systems, damit die Kundschaft weiter bedient werden kann.

Aus deinem Vorwissen kennst du bereits den Service Request (Serviceanfrage). Die Abgrenzung ist simpel: Ein Service Request ist eine geplante Standardanfrage (z. B. "Ich benötige eine neue Maus"), während ein Incident immer ungeplant ist und einen Fehler darstellt (z. B. "Meine Maus ist plötzlich defekt").

Die fünf Schritte des Incident Managements

Um das Chaos bei Ausfällen zu minimieren und SLAs (Service Level Agreements) einzuhalten, folgt die Bearbeitung einem strikten, standardisierten Ablauf:

  1. Erfassung (Recording): Der Ausfall des Kassensystems wird im Ticketsystem mit allen relevanten Daten (Wer? Wann? Was?) dokumentiert.
  2. Klassifizierung (Classification): Das Ticket wird einer Kategorie zugeordnet (z. B. "Hardware" oder "Netzwerk"), damit es direkt beim richtigen Support-Team landet.
  3. Priorisierung (Prioritization): Wie dringend ist es? Ein kompletter Kassenausfall hat massive geschäftliche Auswirkungen und erhält eine kritische Priorität. Ein einzelner defekter Monitor im Backoffice wird niedriger priorisiert.
  4. Bearbeitung (Investigation & Resolution): Das Support-Team untersucht den Fehler und wendet eine Lösung oder einen Workaround an, damit die Kasse wieder läuft.
  5. Abschluss (Closure): Die meldende Person bestätigt, dass alles wieder funktioniert. Das Ticket wird dokumentiert und geschlossen.
Incident, Problem und Change — dec-service-management-it-service-management-basics-incident-problem-and-change_page1.svg

Was unterscheidet ein Problem von einem Incident?

Symptombekämpfung vs. Ursachenforschung

Wenn die Kasse aus dem vorherigen Beispiel jeden Montagmorgen abstürzt und durch einen Neustart (Workaround) wieder zum Laufen gebracht wird, haben wir zwar viele gelöste Incidents, aber die wahre Fehlerquelle bleibt bestehen. Hier kommt das Problem Management ins Spiel.

Ein Problem ist die noch unbekannte, zugrunde liegende Ursache (Root Cause) eines oder mehrerer Incidents. Der Unterschied ist fundamental: Während das Incident Management nur das "Symptom" bekämpft (den Ausfall schnell beheben), sucht das Problem Management nach der "Krankheit" (warum der Ausfall überhaupt passiert). Das Ziel ist es, zukünftige Störungen dauerhaft zu verhindern und die Qualität der IT-Services kontinuierlich zu verbessern.

Der systematische Problem-Management-Prozess

Um von wiederkehrenden Störungen zu einer dauerhaften Lösung zu gelangen, durchläuft ein Problem vier Phasen:

  1. Identifizierung (Identification): Durch die Analyse von Incident-Daten fällt auf, dass die Kasse immer montags abstürzt. Ein Problem-Record wird im System erstellt.
  2. Analyse (Diagnosis): Das Team sucht systematisch nach der Ursache. Mit Techniken wie den "5 Whys" (Fünfmaliges Warum-Fragen) wird herausgefunden, dass ein fehlerhaftes automatisches Update am Sonntagabend den Speicher der Kasse überlaufen lässt.
  3. Lösung (Resolution): Es wird ein dauerhafter Lösungsweg entwickelt – in diesem Fall ein Patch für die Update-Software. Bis dieser Patch installiert ist, wird der Workaround (Neustart) offiziell als Known Error (bekannter Fehler) dokumentiert, damit der Support bei neuen Incidents sofort reagieren kann.
  4. Abschluss (Closure): Sobald die dauerhafte Lösung erfolgreich implementiert wurde und keine neuen Incidents mehr auftreten, wird das Problem geschlossen.
Incident, Problem und Change — dec-service-management-it-service-management-basics-incident-problem-and-change_page2.svg

Wie werden Changes sicher umgesetzt und wie hängt alles zusammen?

Die drei Arten von Changes

Die dauerhafte Lösung eines Problems erfordert fast immer eine Anpassung an der IT-Infrastruktur. Ein Change ist das geplante Hinzufügen, Modifizieren oder Entfernen von Elementen, die IT-Services beeinflussen könnten. Um Risiken zu minimieren, werden Changes in drei Kategorien unterteilt:

  • Standard Change: Risikoarme, vorab genehmigte Routineaufgaben, die oft automatisiert ablaufen. Beispiel: Das Zurücksetzen eines Passworts nach einem festen Leitfaden.
  • Normal Change: Geplante Anpassungen, die individuell bewertet und genehmigt werden müssen. Beispiel: Das Upgrade des Betriebssystems auf allen Unternehmensservern.
  • Emergency Change (Notfall-Change): Hochkritische Anpassungen, die sofort umgesetzt werden müssen, um massiven Schaden abzuwenden. Beispiel: Das sofortige Einspielen eines Sicherheitspatches, weil das Netzwerk gerade aktiv von außen angegriffen wird.

Der sichere Weg zur Anpassung: Der Change-Prozess

Ein Normal Change darf niemals spontan durchgeführt werden, da ungetestete Änderungen das gesamte System lahmlegen können. Er folgt diesem strikten Ablauf:

  1. Antrag (Request for Change - RfC): Die geplante Server-Aktualisierung wird formal beantragt und dokumentiert.
  2. Bewertung (Assessment): Welche Risiken gibt es? Was kostet es? Was passiert, wenn das Update fehlschlägt?
  3. Genehmigung (Authorization): Ein Gremium (oft das Change Advisory Board, CAB) gibt den Change basierend auf der Bewertung offiziell frei.
  4. Umsetzung (Implementation): Das Update wird geplant, in einer sicheren Testumgebung geprüft und schließlich im Live-System ausgerollt.
  5. Abschluss (Review): Es wird geprüft, ob das Update erfolgreich war und keine unerwarteten Nebeneffekte aufgetreten sind.

Der Kreislauf: Incident, Problem und Change

Diese drei Prozesse bilden das Herzstück der kontinuierlichen Serviceverbesserung (Continual Improvement) und sind stark voneinander abhängig. Sie greifen wie Zahnräder ineinander:

Ein Incident (Kasse stürzt ab) macht auf einen Fehler aufmerksam. Die Untersuchung mehrerer solcher Incidents führt zur Eröffnung eines Problems (Speicherüberlauf durch Update). Um dieses Problem dauerhaft zu lösen, muss die Software aktualisiert werden – dies geschieht über einen kontrollierten Change.

Aber Vorsicht: Diese Abhängigkeit wirkt auch in die andere Richtung! Ein schlecht geplanter oder fehlerhaft umgesetzter Change (z. B. ein ungetestetes Server-Update) ist in der Praxis eine der häufigsten Ursachen für völlig neue Incidents. Daher ist die strikte Einhaltung der Prozesse essenziell für einen stabilen IT-Betrieb.

Incident, Problem und Change — dec-service-management-it-service-management-basics-incident-problem-and-change_page3.svg

Teste dein Wissen

Ein kritischer Server fällt während der Arbeitszeit aus. Was ist das oberste Ziel des IT-Supports im Rahmen des Incident Managements?

Bereit für mehr?

Thema verstanden?

Teste dein Wissen interaktiv in unserer App. 7 Tage kostenlos, dann nur 5 € im Monat.

Jetzt kostenlos testen Preise ansehen