SLAs in Jira Service Management, die tatsächlich eingehalten werden

Warum SLAs rot werden, obwohl die Konfiguration stimmt

Wir sehen bei MESKRU regelmäßig Jira-Instanzen, in denen die SLAs technisch sauber eingerichtet sind und trotzdem verfehlt werden. Der Grund liegt fast immer außerhalb des Systems: Ein SLA-Ziel wird gesetzt, ohne die organisatorischen Voraussetzungen zu schaffen, es einzuhalten. Typisch sind vier Lücken:

• Niemand besitzt den Service. Eine Queue ohne verantwortliche Person oder verantwortliches Team ist kein Service, sondern ein Postfach. Wenn die Uhr abläuft, fühlt sich niemand zuständig.

• Das Ziel passt nicht zur Kapazität. Vier Stunden bis zur Lösung klingen gut, solange niemand nachrechnet, wie viele Tickets in welcher Zeit mit wie vielen Leuten ankommen.

• Es gibt keine Vertretung. Urlaub, Krankheit, Schichtende: Wenn die eine Person fehlt, die das Thema kann, steht das Ticket, und die Uhr läuft weiter.

• Eskalation heißt Nachfassen nach dem Bruch. Ob ein SLA verletzt wurde, steht im Report. Wer vorher informiert wird und wer eingreifen darf, ist nirgends festgelegt.

Keine dieser Lücken lässt sich mit einer weiteren SLA-Bedingung schließen. Sie müssen erst organisatorisch geklärt und erprobt sein. Dann lassen sie sich dauerhaft im System abbilden.

Vier Fragen, bevor ein SLA-Ziel ins System kommt

1. Wem gehört der Service? Eine Person oder ein Team, das für die Einhaltung geradesteht und die Zahlen kennt.

2. Reicht die Kapazität, auch mit Vertretung? Das Ziel muss zu Ticketaufkommen, Besetzung und Servicezeiten passen, nicht zum Wunsch.

3. Was passiert, bevor die Zeit abläuft? Wer wird wann informiert, und wer hat das Mandat, umzupriorisieren oder Hilfe zu holen?

4. Wie wird das SLA dokumentiert und überprüft? Wo steht es für Kunden und Team nachlesbar, und wann schaut ihr euch die Zahlen gemeinsam an?

Erst wenn diese vier Antworten stehen, lohnt es sich, das Ziel in Jira Service Management einzutragen.

Was die Uhr in Jira Service Management misst

Ein SLA in JSM besteht aus Bedingungen, Zielen und Kalendern. Wer die Regeln dahinter kennt, vermeidet die häufigsten Messfehler:

• Start, Pause, Stopp. Die Uhr startet, sobald eine der Startbedingungen erfüllt ist, und stoppt, sobald eine der Stoppbedingungen erfüllt ist. Die Pause ist optional, typisch ist das Warten auf eine Antwort des Kunden.

• Ziele werden von oben nach unten geprüft. Jedes Ziel filtert per JQL, welche Tickets es betrifft. Die Reihenfolge entscheidet, und am Ende steht ein Auffangziel für alle übrigen Tickets. Passt ein Ticket auf kein konkretes Ziel, landet es dort, im Zweifel ohne Zielzeit.

• Kalender bestimmen die Zeit. Über Kalender legst du Arbeitszeiten und Feiertage fest. Außerhalb davon steht die Uhr still. Ein SLA ohne passenden Kalender misst rund um die Uhr.

Zwei Fallen nennt Atlassian selbst: Sind Start- und Stoppbedingung identisch, kann ein Ticket mehrere SLA-Zyklen bekommen. Und wird die Stoppbedingung erfüllt, bevor der Zyklus richtig begonnen hat, steht das Ticket ohne SLA da. Beides verfälscht die Auswertung, ohne dass es jemand merkt.

Eskalation vor dem Bruch, nicht danach

Eine Eskalation, die erst nach dem Bruch greift, dokumentiert das Problem nur. JSM bringt die Bausteine mit, um früher zu reagieren:

• Eine Queue für drohende Brüche. Mit JQL-Funktionen für SLAs filterst du Tickets nach der verbleibenden Zeit, zum Beispiel "Time to resolution" < remaining("2h"). Damit sieht das Team, was gleich kippt, und nicht nur, was schon gekippt ist.

• Bereits verletzte SLAs sichtbar machen. breached() findet Tickets, deren letzter SLA-Zyklus das Ziel verfehlt hat. Das gehört ins Service-Review, nicht in eine Schuldfrage.

• Benachrichtigung an die richtige Person. Mit Jira-Automation kannst du auf SLA-Schwellen reagieren. Entscheidend ist der Empfänger: die Person mit dem Mandat einzugreifen, nicht das ganze Team.

Die Technik ist der kleinere Teil. Der größere ist die Vereinbarung, wer bei einer Warnung was tun darf. Diese Pfade müssen vorher definiert, getestet und dann im System konfiguriert sein.

SLA-Ziele aus dem Service ableiten, nicht aus dem Formular

Viele SLA-Ziele hängen an der Priorität, und die Priorität wählt oft der Melder. Damit entscheidet die Einschätzung im Portal darüber, wie schnell ihr liefern müsst.

Robuster ist es, das Ziel aus dem betroffenen Service abzuleiten. Mit Assets ergeben sich SLA-Ziele aus Objektattributen wie dem Service-Tier. Ein Produktivsystem und ein Testsystem teilen sich dann nie dieselbe Uhr. Wie du so ein Modell aufbaust, beschreiben wir in Assets in Jira Service Management modellieren .

Zahlen gemeinsam anschauen

Ein SLA, dessen Zahlen niemand regelmäßig bespricht, verliert seine Wirkung. Im Service-Review bewertet das Team die Kennzahlen, sucht nach Mustern und passt Prozesse an: Welche Tickets reißen das Ziel? Liegt es an der Kapazität, an fehlenden Informationen oder an einer Übergabe? Und passt das Ziel überhaupt noch zum Service?

Ziele dürfen sich ändern. Neue Services, wachsende Teams und neue Anforderungen gehören in dieselbe Runde.

Fünf Fragen zum Selbsttest

1. Kannst du für jedes SLA eine Person oder ein Team nennen, das dafür verantwortlich ist?

2. Ist das Ziel aus Ticketaufkommen und Besetzung abgeleitet, einschließlich Vertretung?

3. Sieht dein Team drohende Brüche, bevor sie passieren?

4. Ist festgelegt, wer bei einer Warnung eingreifen darf?

5. Bespricht ihr die SLA-Zahlen regelmäßig und passt Ziele oder Prozesse daraufhin an?

Jedes Nein ist ein Grund, warum ein SLA rot wird, egal wie gut es konfiguriert ist.

Wie wir unterstützen

Bei MESKRU prüfen wir zuerst die technische Umsetzung von Jira Service Management. Danach geht es um das Betriebsmodell: Services und Ownership definieren, Eskalationspfade und SLA-Konzepte entwickeln und die Einführung begleiten. Für bestehende Umgebungen bieten wir Health Checks an, in denen wir mit euren Teams den größten Hebel finden.

Mehr dazu auf unserer Seite Servicemanagement & Zusammenarbeit . Den Hintergrund zum Betriebsmodell findest du im Artikel Jira Service Management als Betriebsmodell .