Incident Management mit Jira Service Management

Vom Ticket-Chaos zur strukturierten Störungsbehebung

Modernes Incident Management steht auf drei Säulen: intelligente Ticket-Aufnahme über dynamische Portale, ein eigener Workflow für Major Incidents und automatisierte Alarmierung via Opsgenie. Wer diese drei Elemente in Jira Service Management sauber verbindet, verkürzt die Wiederherstellungszeit und entlastet den First-Level-Support von manueller Vorarbeit.

Konkret bedeutet das:

• Dynamische Formulare im Kundenportal fragen nur die relevanten Felder ab, abhängig von der Störungskategorie.
• Ein separater Major-Incident-Workflow informiert Stakeholder automatisch und schafft klare Verantwortlichkeiten in der akuten Phase.
• Opsgenie routet Alarme aus dem Monitoring an den zuständigen Pikett-Mitarbeitenden, inklusive Eskalationsstufen.

Als Atlassian Platinum Solution Partner in der Schweiz begleitet Swarmit IT-Organisationen bei genau dieser Umsetzung, von der ersten Portalstruktur bis zum eingespielten Pikett-Dienst.

Wo Incident Management in der Praxis scheitert

Die häufigste Ursache für schlechtes Incident Management ist nicht das fehlende Tool, sondern die fehlende Struktur. Tickets landen in einer generischen Queue, enthalten zu wenig Kontext, und der First-Level verbringt die ersten zehn Minuten damit, überhaupt zu verstehen, worum es geht. Dann wird zurückgefragt, das Ticket wandert von Hand in die zuständige Gruppe, und irgendwann in diesem Prozess beginnt die eigentliche Arbeit.

Ein Incident ist per Definition eine ungeplante Unterbrechung eines Services. Das Ziel ist immer dasselbe: den Service so schnell wie möglich wiederherstellen. Alles, was diesen Weg verkürzt, lohnt sich. Alles, was ihn verlängert, gehört auf den Prüfstand.

In den Mandaten, die wir bei Schweizer Kunden begleiten, sehen wir drei wiederkehrende Muster: unklare Ticket-Aufnahme, kein definierter Ablauf für Major Incidents und Alarme, die im falschen Postfach landen. Alle drei Punkte lassen sich in Jira Service Management (JSM) adressieren.

Intelligente Ticket-Aufnahme mit dynamischen Portalen

Ein Portal wird nur genutzt, wenn es dem Mitarbeitenden schneller hilft als ein Anruf bei der IT. Damit das gelingt, braucht es zwei Dinge: eine überschaubare Kategorienstruktur und Formulare, die sich abhängig von der Auswahl anpassen.

Konkret: Wählt jemand "Applikation funktioniert nicht", fragt das Formular nach der betroffenen Applikation und lädt automatisch verwandte Wissensartikel. Wählt jemand "Zugriff verloren", geht es um Benutzername und System, nicht um Bildschirmfotos. Das ist keine Kosmetik. Das ist der Unterschied zwischen einem Ticket, das direkt bearbeitet werden kann, und einem, bei dem der Agent dreimal zurückfragen muss.

In JSM setzen wir das mit Request Types und bedingten Feldern um. Die Kategorienstruktur bleibt bewusst schlank: Wir sehen in der Praxis, dass mehr Top-Level-Kategorien die Nutzung eher senken als heben. Wer alles anbieten will, wird zur Suchmaschine, die niemand nutzt.

In diesem Blog gibt Anja noch weitere Insights zum Thema Service-Portal: Wer baut das Service-Portal und warum das die entscheidende Frage ist

Der Major-Incident-Workflow: Wenn es wirklich brennt

Ein Major Incident ist etwas anderes als ein normaler Incident. Betroffen sind meist mehrere Business-Services, die Zeit ist kritisch, und mehrere Personen arbeiten parallel. Wer in dieser Situation denselben Workflow verwendet wie bei einem vergessenen Passwort, verliert Zeit.

Wir empfehlen einen eigenen Major-Incident-Workflow mit vier Elementen:

• Automatische Benachrichtigung definierter Stakeholder-Gruppen (Business, Kommunikation, Geschäftsleitung) beim Wechsel in den Major-Status.
• Ein festes Kommunikationsmuster, das im Ticket selbst geführt wird, nicht auf Teams oder Slack verteilt.
• Automatisches Anlegen eines Post-Incident-Reviews nach Abschluss.

Der Wechsel in den Major-Status geschieht per Knopfdruck aus dem normalen Incident-Ticket heraus. Voraussetzung ist, dass die Kriterien vorher definiert sind: Ab wann ist ein Incident ein Major Incident? Diese Frage klären wir mit dem Kunden zu Beginn und hinterlegen sie als Regel.

On-Call und Alerting: Vom Monitoring direkt zum Incident

Ein Alarm aus dem Monitoring nützt nichts, wenn er im falschen Postfach landet. Jira Service Management verbindet Monitoring-Systeme mit dem Incident Management. Eingehende Alerts werden anhand hinterlegter On-Call- oder Pikettpläne an die zuständige Person weitergeleitet und bei Bedarf automatisch eskaliert, wenn keine Reaktion erfolgt.

Zwei Punkte sind bei der Einführung entscheidend:

Der Pikettplan muss die Realität abbilden. Ferien, Krankheit, Stellvertretungen oder geteilte Verantwortung zwischen Standorten müssen laufend gepflegt werden. Ein veralteter On-Call-Plan führt dazu, dass kritische Alarme die falschen Personen erreichen oder unbeantwortet bleiben.

Die Alarm-Schwellenwerte müssen bewusst gesetzt werden. Ein System, das ständig alarmiert, erzeugt Alarmmüdigkeit. Sinnvoll ist es, mit klar definierten Schwellenwerten zu starten und diese anhand der Betriebserfahrung schrittweise zu optimieren.

Kritische Alerts können automatisch einen Incident in Jira Service Management erstellen. Dadurch entsteht aus einem Monitoring-Ereignis unmittelbar ein Incident mit klaren Verantwortlichkeiten, standardisierten Workflows und vollständiger Nachvollziehbarkeit.

Abgrenzung: Was Incident Management nicht ist

Incident Management stellt den Service wieder her. Es klärt nicht die Ursache. Diese Trennung ist wichtig, weil sie sonst zu vermischten Tickets führt: Ein Incident wird offen gehalten, um die Root Cause zu suchen, obwohl der Service längst wieder läuft.

Die Regel ist einfach. Läuft der Service wieder, wird der Incident geschlossen. Bleibt eine Ursache offen, entsteht ein Problem-Ticket, das mit dem Incident verknüpft wird. Diesem Thema widmen wir uns in einem der nächsten Beiträge dieser Serie.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Incident und Problem in Jira Service Management? Ein Incident beschreibt die Auswirkung: Ein Service funktioniert nicht wie erwartet. Ein Problem beschreibt die Ursache dahinter. Ein Incident wird geschlossen, sobald der Service wieder läuft. Ein Problem bleibt offen, bis die Ursache eliminiert ist. Beide werden in JSM als eigene Issue Types abgebildet und miteinander verknüpft.

Reicht Jira Service Management Standard aus?
Für viele kleine und mittlere Service-Teams reicht JSM Standard aus. Es bietet Ticket-Management, Workflows, Automatisierungen und grundlegendes Reporting. Werden jedoch Funktionen wie integriertes Incident Management, Alerting, On-Call-/Pikettpläne, Eskalationen oder erweiterte Service-Management-Funktionen benötigt, ist in der Regel JSM Premium oder Enterprise die passende Wahl.

Wie misst man, ob das Incident Management funktioniert? Die zentralen Kennzahlen sind Mean Time to Resolution (MTTR), Anteil beim ersten Kontakt gelöster Tickets (First Contact Resolution) und der Anteil eskalierter Major Incidents. JSM liefert diese Kennzahlen out of the box im Reporting.

Wie ist die Situation in der Schweiz bezüglich Datenresidenz? Atlassian Cloud unterstützt Datenstandort Schweiz. Für Organisationen mit Anforderungen aus dem revidierten Datenschutzgesetz (revDSG) oder aus dem regulierten Umfeld (FINMA, kantonale Vorgaben) ist das die Grundlage für eine konforme Nutzung. Swarmit begleitet die Konfiguration und dokumentiert die Data-Residency-Einstellungen prüfsicher.

‍

Nächste Schritte

Wer den Ist-Zustand seines Incident Managements neutral einordnen will, findet einen guten Einstieg über ein Assessment: Wir schauen uns die aktuelle Ticket-Struktur an, prüfen die Portalgestaltung und identifizieren die Hebel mit der grössten Wirkung.