Assets in Jira Service Management: Herz und Verstand deines ITSM

MESKRU knowledge: Was Jira Service Management wirklich leisten kann

Die meisten Unternehmen haben Jira Service Management technisch im Griff. Es ist eingerichtet, konfiguriert und läuft. Trotzdem erleben wir bei MESKRU immer wieder dieselbe Situation: Das System ist da, aber es lebt nicht.

Tickets werden verwaltet, es werden aber keine Services geführt. Genau an diesem Punkt entscheidet sich, ob JSM nur ein weiteres System bleibt oder zu einem Werkzeug wird, das euren Betrieb aktiv prägt.

Wir stellen früh in der Zusammenarbeit mit Kunden fest, dass vielen Unternehmen ein klarer Plan zur Nutzung von JSM fehlt: Tickets stapeln sich, SLAs werden nicht eingehalten, Mitarbeiter nutzen das Portal kaum und Reportings sind nicht aussagekräftig.

Obwohl JSM als Service Desk in Unternehmen längst ein fester Bestandteil der technischen Infrastruktur ist, ist das Potential, es als Betriebsmodell zu implementieren, oft nicht ausgeschöpft.

Der Schlüssel liegt in der Verbindung von technischer Konfiguration und organisatorischer Verankerung - beides muss synchron gedacht und umgesetzt werden. 

MESKRU deep dive: Was zeichnet ein Betriebsmodell aus?

Ein Betriebsmodell beschreibt, wie ein Service im Kern funktioniert. Es geht nicht nur um den Aufbau, sondern insbesondere darum, wie der Service geführt wird.

Als MESKRU auditieren wir täglich Jira-Instanzen, die in der Theorie technisch optimal aufgebaut sind: Queues sind gut strukturiert, SLAs sind sauber konfiguriert und Portale haben eine gute Usability. Jedoch erleben wir als Ausgangssituation bei Kunden oftmals stagnierende Aktivitäten des Betriebs.

Die Ursache dafür ist schnell klar: Der JSM-Konfiguration fehlt eine klare Ownership. Weder Reportings noch Eskalationsprozesse, die im System existieren und stets aktuell sind, werden aktiv genutzt.

Wer ist für welchen Service verantwortlich? Nach welchen Kriterien werden Anfragen grundsätzlich priorisiert? Wer entscheidet, in welcher Reihenfolge Tickets bearbeitet werden, wenn Kapazitäten begrenzt sind? Wie werden SLAs dokumentiert und was passiert, wenn sie nicht eingehalten werden?

Jede Frage hängt unmittelbar mit organisatorischen Strukturen, die erst technische Prozesse ermöglichen, zusammen. Bevor also Unternehmen ihre jeweilige JSM-Konfiguration effizient und praktisch nutzen können, sind diese Fragen zu klären und es bedarf klarer, daraus abgeleiteter Prozesse, in die das JSM integriert wird.

MESKRU experience: Häufige strukturelle Herausforderungen in JSM-Umgebungen

1. Ownership fehlt: Ein Service-Queue ohne eine verantwortliche Person oder ein verantwortliches Team ist kein Service, sondern ein Postfach im Leerlauf. Wer keine Ownership definiert, kann keinen zuverlässigen Service anbieten.
   
   

2. SLAs sind nicht verankert: Unternehmen setzen SLA-Ziele in JSM, ohne die notwendigen organisatorischen Voraussetzungen zu schaffen diese einzuhalten. Kapazitätsplanung, Eskalationspfade, Vertretungsregelungen: Diese und weitere Themen müssen zunächst strukturell außerhalb des Systems definiert und erprobt sein, um sie dann nachhaltig im System abbilden zu können.
   
   

3. Kundenportal wird nicht genutzt: Obwohl ein Portal existiert, schreiben User weiterhin E-Mails. Meist liegt das nicht an der Usability, sondern an mangelnder Kommunikation und Einführung.
   Wer das Portal nicht aktiv einführt und erklärt, erreicht darüber kein Engagement und verharrt in veralteten, zeit- und kostenintensiven Prozessen.
   
   

4. Reporting wird nicht genutzt: JSM bietet umfangreiche Auswertungsmöglichkeiten. In der Theorie existieren sie, in der Praxis werden oft de-priorisiert. Wer die Kennzahlen seines Service nicht aktiv trackt und analysiert, kann ihn nicht optimieren.

MESKRU blueprint: So setzen wir JSM als Betriebsmodell auf

1. Klare Servicekataloge: Ein strukturierter Servicekatalog hilft Usern, die richtige Anfrage zu stellen, und dem Team, sie schnell zu bearbeiten. Das reduziert Rückfragen und Bearbeitungszeit.
   

   
   

2. Definierte Eskalationspfade: Was passiert, wenn ein Ticket nicht innerhalb des SLA gelöst wird? Wer wird informiert? Wer hat das Mandat einzugreifen? Diese Pfade müssen im Vorfeld definiert, getestet und im System konfiguriert sein.

   
   

3. Aktives Service-Review: Service-Teams tauschen sich regelmäßig und transparent aus, um Kennzahlen zu bewerten, Prozesse anzupassen und Trends zu analysieren.

   
   

4. Dynamische Optimierung: Regelmäßige Pflege und Weiterentwicklung sind aufgrund sich ändernder Regulationen, neuer technischer Anforderungen, aufgrund wachsender Teams und neuer Services essentiell, um Relevanz zu gewährleisten.  

MESKRU competence: Was wir mitbringen und wie wir arbeiten

Im ersten Schritt auditiert und begleitet das jeweilige Projektteam die technische Implementierung von JSM - alle weiteren Projektschritte fokussieren wir auf die Entwicklung des Betriebsmodells.

Diese Schritte umfassen u.a. die Definition von Services und Ownership-Strukturen, die Entwicklung von Eskalationspfaden und SLA-Konzepten sowie die Begleitung bei der Einführung.

Darüber hinaus bieten wir regelmäßige Health Checks für bestehende JSM-Umgebungen an, bei denen wir gemeinsam mit euren Teams schauen, worin der größte Optimierungshebel liegt.

Ihr wollt JSM konfigurieren oder nutzt es schon und wollt jetzt das volle Potential als Betriebsmodell ausschöpfen?

Lasst uns gemeinsam herausfinden, was ihr braucht, um JSM als Betriebsmodell zu nutzen!

Jetzt Erstgespräch mit Alexander Kruse buchen