IT-Service-Management
Der Ticketsystem-Workflow
Fast jede Serviceanfrage, die im Unternehmen eingeht — ob per Telefon, Mail oder Self-Service-Portal — durchläuft im Ticketsystem einen festen Lebenszyklus. Diesen Ablauf solltest du in der Prüfung in eigenen Worten skizzieren können.
- Erfassung: Die Anfrage wird als Ticket angelegt. Wichtig sind vollständige Angaben: betroffener Nutzer, System/Anwendung, Fehlerbeschreibung, Zeitpunkt des Auftretens und Kontaktweg.
- Priorisierung: Das Ticket wird anhand von Dringlichkeit und Auswirkung eingestuft (siehe unten), damit die Bearbeitungsreihenfolge nachvollziehbar ist.
- Bearbeitung/Untersuchung: Der zuständige Support (1st-, 2nd- oder 3rd-Level) analysiert die Ursache, testet Lösungsansätze und dokumentiert Zwischenschritte im Ticket.
- Lösung: Die Störung wird behoben oder die Anfrage erfüllt, der Anwender wird informiert und bestätigt die Wiederherstellung.
- Abschluss/Dokumentation: Das Ticket wird mit Lösungstext geschlossen und archiviert.
Eine strukturierte Erfassung ist mehr als Formalismus: Sie sorgt für Nachvollziehbarkeit (wer hat wann was gemacht, wichtig bei Reklamationen oder Audits) und für Wissensaufbau — dokumentierte Lösungen fließen in eine Knowledge Base ein und beschleunigen künftige Bearbeitungen ähnlicher Fälle, auch durch andere Mitarbeitende.
Wird nach dem "Lebenszyklus eines Tickets" gefragt, nenne die Schritte in der richtigen Reihenfolge und begründe jeweils kurz den Zweck — reines Aufzählen ohne Begründung bringt in der AP1 meist weniger Punkte.
ITIL: Incident, Problem & Change Management
ITIL (IT Infrastructure Library) ist eine Sammlung von Best Practices für das IT-Servicemanagement. Sie beschreibt, wie IT-Dienstleistungen geplant, erbracht und kontinuierlich verbessert werden — kein starres Gesetz, sondern ein Referenzrahmen, an dem sich viele Unternehmen orientieren.
Incident Management vs. Problem Management
Der Unterschied zwischen diesen beiden Prozessen ist ein Klassiker in der AP1:
- Incident Management: Ziel ist die möglichst schnelle Wiederherstellung des vereinbarten Servicebetriebs nach einer Störung. Es geht um "Symptombehandlung" — der Service soll schnell wieder laufen, auch wenn die eigentliche Ursache noch unbekannt ist (z. B. Neustart eines hängenden Dienstes).
- Problem Management: Ziel ist die dauerhafte Ursachenanalyse (Root Cause Analysis), um wiederkehrende Störungen zu vermeiden. Es geht um "Ursachenbehandlung" — mehrere ähnliche Incidents werden zu einem Problem zusammengefasst und systematisch untersucht.
Merksatz: Incident Management behandelt das Symptom und will den Betrieb schnell zurück, Problem Management behandelt die Ursache und will das Wiederauftreten verhindern.
Change Management
Change Management regelt die kontrollierte Durchführung von Änderungen an der IT-Umgebung — etwa Softwareupdates, Konfigurationsänderungen oder Hardwaretausch. Änderungen durchlaufen typischerweise Planung, Bewertung (u. a. Risiko und Auswirkung), Genehmigung, Umsetzung und Nachkontrolle, damit sie keine neuen Störungen verursachen.
Ein beliebtes Fallbeispiel: "Ein Drucker fällt wiederholt in mehreren Filialen aus." Die schnelle Reaktion (Gerät neu starten, Ersatzgerät bereitstellen) ist Incident Management. Die Suche nach der gemeinsamen Ursache (z. B. fehlerhafter Treiber) und deren dauerhafte Behebung ist Problem Management.
Service Level Agreements (SLA)
Ein SLA ist eine vertraglich vereinbarte Leistungsbeschreibung zwischen IT-Dienstleister und Kunde. Es legt konkrete, messbare Leistungsmerkmale fest, zum Beispiel:
- Reaktionszeit: Zeit bis zur ersten Rückmeldung nach Ticketeingang.
- Wiederherstellungszeit (Recovery Time): Zeit bis zur Behebung der Störung.
- Verfügbarkeit: Anteil der Zeit, in der ein Service innerhalb der vereinbarten Betriebszeit tatsächlich nutzbar ist, meist in Prozent angegeben.
Beispielrechnung: Verfügbarkeit
Frage: Ein Service ist mit 99,9 % Verfügbarkeit im Jahr vereinbart. Wie viel Ausfallzeit ist das ungefähr?
Rechenweg: Ein Jahr hat 365 Tage × 24 Stunden = 8.760 Stunden. Die zulässige Ausfallzeit entspricht 0,1 % davon:
8.760 h × 0,001 = 8,76 h
Bei 99,9 % Verfügbarkeit dürfte der Service also rechnerisch rund 8,76 Stunden im Jahr ausfallen, ohne dass das SLA verletzt wird. Zum Vergleich: Bei 99,99 % wären es nur noch etwa 0,876 Stunden (ca. 53 Minuten) — jede zusätzliche "Neun" senkt die zulässige Ausfallzeit deutlich.
Merke dir den Rechenweg allgemein: gewünschte Verfügbarkeit in Prozent von den Gesamtstunden des Zeitraums abziehen bzw. die Ausfallquote (100 % − Verfügbarkeit) mit den Gesamtstunden multiplizieren. So kannst du die Formel auch auf Monate oder Wochen übertragen.
Priorisierung: Dringlichkeit × Auswirkung
Damit Tickets nicht einfach nach Eingangsreihenfolge (First-In-First-Out) abgearbeitet werden, wird die Priorität aus zwei Faktoren gebildet:
- Dringlichkeit (Urgency): Wie schnell muss reagiert werden, bevor der Schaden wächst?
- Auswirkung (Impact): Wie viele Nutzer bzw. wie kritische Prozesse sind betroffen?
Beispiel: Fällt der Arbeitsplatz-PC einer einzelnen Mitarbeiterin aus, ist die Auswirkung gering (nur eine Person betroffen) — die Priorität bleibt trotz hoher gefühlter Dringlichkeit für die Betroffene eher niedrig bis mittel. Fällt dagegen ein zentraler Server aus, von dem alle Mitarbeitenden abhängen (z. B. Datei- oder Mailserver), ist die Auswirkung sehr hoch, und das Ticket erhält die höchste Priorität — selbst wenn es formal genauso spät gemeldet wurde.
| Fall | Dringlichkeit | Auswirkung | Priorität |
|---|---|---|---|
| Einzelner Arbeitsplatz-PC ausgefallen | mittel | gering (1 Person) | niedrig/mittel |
| Zentraler Server für alle Mitarbeitenden ausgefallen | hoch | hoch (ganzes Unternehmen) | sehr hoch |
Eskalation
Kann ein Ticket auf der aktuellen Ebene nicht gelöst werden, wird es eskaliert. Dabei unterscheidet man zwei Arten:
- Fachliche Eskalation: Das Ticket wird an spezialisierteres Personal weitergegeben, z. B. vom 1st-Level-Support an den 2nd- oder 3rd-Level-Support, wenn tieferes Fachwissen nötig ist (etwa Netzwerk- oder Datenbankspezialisten).
- Hierarchische Eskalation: Wird eine vereinbarte Frist (z. B. Reaktions- oder Lösungszeit aus dem SLA) überschritten, wird das Ticket an eine höhere Verantwortungsebene gemeldet, etwa an die Teamleitung oder das Management, um zusätzlichen Druck bzw. Ressourcen zu mobilisieren.
Beide Eskalationsarten dienen demselben Ziel: sicherzustellen, dass ein Vorgang nicht "hängen bleibt", sondern zeitnah und mit den richtigen Ressourcen gelöst wird.