- 1 Section
- 10 Lessons
- unbegrenzt
- IT-Betrieb & Support10
- 1.11st, 2nd, 3rd Level Support
- 1.2Incident Management
- 1.3Ticket-Priorisierung
- 1.4Problem Management: Root Cause Analysis
- 1.5Known Error Database (KEDB)
- 1.6Change Management: RFC, CAB
- 1.7Change-Typen: Standard, Normal, Emergency
- 1.8Knowledge Base aufbauen
- 1.9Netzwerkdrucker und Druckserver einrichten
- 1.10Aufgaben IT-Betrieb & Support
Ticket-Priorisierung
Wenn morgens 25 neue Tickets im Service Desk liegen, kann nicht alles gleichzeitig bearbeitet werden – jemand muss entscheiden, was zuerst dran ist. Genau dafür dient die Priorisierung: ein systematisches Verfahren, das jedem Ticket eine objektive Priorität zuweist, aus der dann automatisch die SLA-Frist folgt. Die ITIL-konforme Methode ist die Priority Matrix: Priorität entsteht aus dem Produkt von Impact (wie groß ist die Auswirkung) und Urgency (wie schnell muss gehandelt werden). Beide werden getrennt bewertet, ihre Kombination ergibt die Priorität. Das klingt formal, ist aber wichtig: ohne diese Trennung bekommen alle Tickets vom Chef Prio 1, weil der lauter schreit – und die wirklich kritischen Vorfälle gehen unter. Diese Lektion zeigt dir die 4×4-Matrix, übliche SLA-Fristen pro Stufe und übt mit konkreten Beispielen.
1) Impact – wie viele leiden mit?
Der Impact beschreibt die Ausweitung – wie viele Anwender, wie kritische Services sind betroffen?
| Stufe | Beschreibung | Beispiel |
|---|---|---|
| 1 – High | Ganze Organisation oder kritisches System betroffen, Geschäftsausfall | Hauptserver down, Internet komplett weg, ERP-System hängt |
| 2 – Medium | Mehrere Abteilungen oder ein wichtiger Service teilweise betroffen | Druckserver der Produktion down, eine Filiale ohne Verbindung |
| 3 – Low | Wenige Anwender oder unkritischer Service | 3 User können nicht drucken, Demo-Umgebung langsam |
| 4 – Very Low | Einzelner Anwender, kein Geschäftsausfall | Tastatur defekt, persönliche Mailbox-Frage |
2) Urgency – wie schnell muss reagiert werden?
Urgency beschreibt die Zeitkritikalität. Achtung: ist nicht identisch mit Impact! Ein einzelner Anwender (geringer Impact) kann hohe Urgency haben, wenn er gerade eine Präsentation für den Vorstand vorbereitet.
| Stufe | Beschreibung | Beispiel |
|---|---|---|
| 1 – High | Sofort, drohende Eskalation, Verlust droht | Online-Shop am Black Friday down, Cyberangriff läuft |
| 2 – Medium | Heute, aber nicht in Minuten | Tagesgeschäft betroffen, Workaround möglich |
| 3 – Low | Diese Woche genügt | Reporting-Tool langsam, Sammelanfrage |
| 4 – Very Low | Nicht zeitkritisch | Kosmetik-Wunsch, Optimierung |
3) Die Priority Matrix – interaktiv
Klick eine Zelle an, um die Priorität, typische SLA-Fristen und Beispiele zu sehen. Die Matrix folgt der klassischen ITIL-Konvention:
4) Beispielszenarien – wie würdest du priorisieren?
Lies die Situation, wähle die richtige Priorität, sieh die Begründung:
5) Typische SLA-Fristen pro Priorität
Aus der Priorität folgt direkt die SLA-Frist. Die folgenden Werte sind typisch für eine mittelständische IT, können aber je nach Branche und Geschäftszeit variieren:
| Prio | Bezeichnung | First Response | Resolution Time |
|---|---|---|---|
| P1 | Critical | 15 Min. | 4 Std. |
| P2 | High | 30 Min. | 8 Std. |
| P3 | Medium | 2 Std. | 24 Std. (1 AT) |
| P4 | Low | 4 Std. | 3 AT |
| P5 | Very Low / Planning | 1 AT | 5 AT |
„AT" steht für Arbeitstag. Wichtig: Resolution bedeutet Service wiederhergestellt, nicht „Ursache geklärt" – das ist Problem-Management-Sache.
6) Anpassung an Geschäftszeiten
SLA-Fristen werden meist an Geschäftszeiten gekoppelt. Ein P3-Ticket, das Freitag 17:55 Uhr ankommt, läuft nicht über das Wochenende mit – die Uhr stoppt Freitag 18:00 Uhr und läuft Montag 8:00 Uhr weiter. Ausnahme: P1-Tickets in 24/7-Umgebungen – da gibt es On-Call-Bereitschaft, die SLA-Uhr läuft durch. Definition in der SLA muss eindeutig sein.
7) Wann manuell hochstufen?
Die Matrix ist Pflichtwerkzeug, aber kein Diktator. Es gibt Fälle, in denen manuell hochgestuft werden muss:
- VIP-User: Geschäftsführer, Vorstand, Kunden mit Sonder-SLA. Auch ein „eigentlich P4"-Ticket kann hier P2 werden.
- Aggregation: 50 einzelne P4-Tickets über das gleiche Symptom werden zu einem P2-Sammelvorgang aggregiert.
- SLA-Druck: kurz vor Ablauf der SLA-Frist eskaliert das System automatisch eine Stufe höher (auto-promotion).
- Sicherheitsrelevanz: ein „nur ein User"-Vorfall kann ein Cyberangriff sein → unmittelbar P1.
- Externe Wirkung: ein „kleines technisches Problem" wird P1, wenn die Presse drüber schreibt.
8) Antipatterns
- „Anwender vergibt die Priorität". Anwender geben sich selbst immer P1. Lösung: Priorisierung durch Service Desk anhand der Matrix, nicht nach Selbsteinschätzung.
- „Alle Tickets sind P3". Wenn keine Differenzierung mehr stattfindet, ist die Matrix bedeutungslos. Lösung: Priority-Verteilung im Monatsreport prüfen – wenn 90 % P3 sind, läuft was schief.
- Politische Priorisierung. Wer am lautesten schreit oder die Hierarchie kennt, bekommt höhere Priorität. Lösung: dokumentierte Matrix-Regel verhindert Willkür.
- SLA-Schönung durch Re-Klassifizierung. Wenn die Frist droht zu reißen, wird das Ticket auf niedrigere Prio runtergestuft. Lösung: Audit der Priority-Änderungen.
Zusammenfassung
Priorisierung ist die objektive Reihung aller Tickets. Standard-Methode: die Priority Matrix mit zwei Achsen – Impact (wie viele/wie kritisch betroffen) und Urgency (wie zeitkritisch). Aus Impact × Urgency folgt die Priority (P1 Critical bis P5 Planning), aus der Priority folgt direkt die SLA-Frist für First Response und Resolution. Typisch P1=15Min/4Std, P3=2Std/1AT, P5=1AT/5AT. SLA läuft je nach Vertrag in Geschäftszeit oder 24/7. Manuelle Hochstufung erlaubt bei VIP-Usern, Aggregation, Sicherheitsrelevanz, externer Wirkung. Antipatterns: Anwender priorisiert selbst, alle Tickets in der Mitte, politische Priorisierung, SLA-Schönung. Eng verknüpft mit Incident Management – die Priority bestimmt den weiteren Eskalations- und Bearbeitungs-Pfad.
Verwandte Lektionen: Incident Management · SLA · Level Support · und mehrWeitere relevante LektionenService DeskProblem ManagementTicketsystemeAlertingChange ManagementCMDBKEDB
