Jira Service Management (Update 2024)

Nach der Umstellung des Lizenzmodells, wurde Jira Service Management für zahlreiche Unternehmen als Lösung für die Abwicklung von Supportfällen interessant. Für mich der richtige Zeitpunkt, die Kernpunkte der Service Desks sowie meine Erfahrungen damit zu schildern.

Was ist Jira Service Management

Jira Service Management ist eine der 3 sogenannten Anwendungen des Jira Kernsystems. Jede Anwendung beinhaltet individuelle Projekttypen, welche dem Nutzer jeweils unterschiedliche Funktionen zur Verfügung stellen. Das Ziel von Jira Service Management ist es, die Abwicklung von internen und externen Support-Anfragen in einem Unternehmen zu unterstützen. Der Ursprung von Jira Service Management ist das ehemalige VertygoSLA-Plugin von Valiantys, das von Atlassian übernommen und als eigenes Produkt weiterentwickelt wird.

Grundprinzip

In einer Jira-Instanz können beliebig viele Service Management Projekte erstellt werden. Im Wesentlichen handelt es sich dabei um typische Jira-Projekte mit Vorgängen und Feldern, welche aber um verschiedene Support-Funktionen erweitert werden. Jedem Service Projekt werden Agenten (d.h. Support-Mitarbeiter) zugeordnet, welche die eingehenden Tickets bearbeiten können. Jedes Service Management Projekt stellt darüber hinaus ein flexibel konfigurierbares Kundenportal bereit (siehe Punkt „Kundensicht“) und kann frei definierbare SLAs mit jeweils eigenen Zielsetzungen umsetzen (siehe „Administrator-Sicht“).

Supporter-Sicht

Aus Sicht eines Support-Mitarbeiters bietet Jira Service Management zwei Kernfunktionen. Alle in einen Service Projekt eingehenden Tickets werden in frei definierbaren Queues sortiert – es kann es z.B. jeweils eine Warteschlange für jeden Support-Mitarbeiter geben sowie Queues für jedes SLA-Level, jedes Produkt, jede Komponente usw. Die Queues basieren auf standardmäßigen Filtern und bieten demzufolge alle von dort gewohnten Funktionen. Natürlich sind Queues sortierbar, z.B. nach der verbleibenden Zeit bis zum Ablauf einer in einem SLA definierten Zeitspanne.

Alle eingehenden Support-Anfragen – egal ob per E-Mail oder Kundenportal erstellt – sind normale Jira-Vorgänge und werden aus Supporter-Sicht auch als solche bearbeitet.

Für die Kommunikation mit dem Kunden werden Kommentare verwendet: deren Eingabemaske unterscheidet in einem Service Projekt zwischen einem „Internen Kommentar“, der nur für Support-Agenten und projektbeteiligte Rollen sichtbar ist, und einem „Kundenkommentar“, der auch für den Ersteller der Support-Anfrage sichtbar ist. Dies gilt auch, wenn die Anfrage per E-Mail erstellt wurde: der Autor der E-Mail wird als Autor des entsprechenden Tickets eingetragen und erhält Benachrichtigungen über Kommentare oder Statusänderungen an seinem Ticket per E-Mail.

Kundensicht

Für die Kunden eines Service Portals stehen 3 Wege zum Erstellen von Tickets offen:

  • Über die standardmäßige „Vorgang erstellen“ Funktion von JIRA, falls der Kunde Zugriff auf Jira und das entsprechende Projekt besitzt.
  • Über ein (im Service Projekt konfiguriertes) Kundenportal, welches eine vereinfachte Maske zum Erstellen von Support-Anfragen bereitstellt.
  • Per E-Mail an eine vorgegebene E-Mail Adresse, die einem Service Projekt zugewiesen wurde.

Für jedes Service Projekt kann ein Kundenportal definiert werden, in dem Kunden auf einfache Weise Support-Anfragen erstellen können. Dabei wird intern jeweils ein „Anfragetyp“ einem Jira-Vorgangstyp zugewiesen. Möchte man z.B. ein Formular für das Erstellen von Dienstreiseanträgen bereitstellen, kann man einen Anfragetyp „Dienstreise“ erstellen und diesem dem Vorgangstyp „Interne Anfrage“ zuordnen (sofern es keinen eigenen Vorgangstyp „Dienstreiseantrag“ geben soll). Die Eingabemaske des Kundenportals ist flexibel konfigurierbar, verschiedene Anfragetypen können u.a. gruppiert und mit unterschiedlichen Pflichtfeldern versehen werden. Ebenso kann für jeden Anfragetyp definiert werden, welche Status des Arbeitsablaufes für den Kunden sichtbar sein sollen – auf diese Weise kann man zwischen internen und kundensichtbaren Status unterscheiden.

Besonders hervorzuheben ist die Möglichkeit, einen Confluence-Bereich als Knowledge Base an einen Service Desk anzubinden. Tut man dies, wird das Kundenportal um eine Vorschlagsfunktion bei der Eingabe der Support-Anfrage erweitert. Fängt ein Kunde an, etwas einzutippen, werden ihm sofort passende Inhalte aus der angebundenen Knowledge-Base angezeigt. Im besten Fall erhält der Kunde dadurch bereits die gewünschte Information und muss kein eigenes Ticket erstellen.

Eine weitere Möglichkeit, Tickets zu erstellen, ist die Anbindung eines Service Projekts an ein bestehendes POP- oder IMAP-Konto. Jira ruft die E-Mails aus diesem Postfach regelmäßig ab und erstellt daraus Tickets mit dem vorgegebenen Anfrage-Typ. Der Autor der E-Mail wird automatisch als „Kunde“ in diesen Service Desk aufgenommen und als Autor des Tickets eingetragen. Er erhält dadurch Benachrichtigungen über Änderungen oder Kommentare an seinem Ticket, kann auf diese Mails antworten und damit mit dem Support-Agenten kommunizieren.

Administrator-Sicht

Projektadministratoren können die SLA-Levels des Service Projektes bestimmen, die beteiligten Personen verwalten (Support-Agenten, Kunden, weitere Beteiligte) sowie das Kundenportal konfigurieren und die allgemeinen Einstellungen (Anbindung E-Mail Postfach usw.) vornehmen.

Das Einrichten von SLAs funktioniert intuitiv: für jedes SLA können Start- und Stopp-Ereignisse ausgewählt werden sowie Ereignisse, in denen die Zeitberechnung des SLAs pausieren soll (z.B. im Status „Warte auf Kundenantwort“). Per JQL-Abfrage wird vorgegeben, welche Vorgänge in welches SLA-Level fallen, sowie die für jedes Level vorgegebene Zeitspanne und der anzusetzende Kalender mit den Arbeitszeiten der Support-Agenten.

Der Projektadministrator legt weiterhin fest, welche Support-Agenten dieses Service Projekt verwenden können und ob es sich um eine offenes oder geschlossenes Portal handelt. In geschlossenen Service Portalen können nur registrierte Jira-Nutzer sowie Kunden, welche manuell zu einer Kundenliste hinzugefügt wurden, Tickets erstellen. In offenen Service Portalen können sich beliebige Personen als Kunde dieses Service Projektes registrieren und entsprechende Anfragen eröffnen – diese Einstellung ist z.B. für externe Supportsysteme mit beliebig vielen Endkunden geeignet.

Agenten und Lizenzplätze

Jira Service Management berechnet für jeden Support-Agenten einen Lizenzplatz; die Kunden sind kostenlos. Support-Agenten können in beliebig vielen Service Projekten tätig sein und müssen nur einmal lizensiert werden. Auch normale Jira-Nutzer können Service Management Projekte sowie die darin enthaltenen Vorgänge sehen (wenn man das möchte). Allerdings: nur Agenten können Tickets bearbeiten, Kundenkommentare erstellen sowie die Queues und SLAs sehen.

Automatisierungen

JIRA Service Management bietet sogenannte Automatisierungsregeln an, mit denen sich sehr elegante Automatismen einrichten lassen. Unter anderem können bestimmte Personen vor Erreichen einer SLA-Grenze benachrichtigt werden; Vorgänge können anhand der durch den Kunden ausgewählten Feldwerte automatisiert bearbeitet werden und vieles mehr.

Fazit

Jira Service Management ist eine leicht konfigurierbare Lösung für Supportprojekte, die sowohl von Support-Agenten wie auch von Kunden intuitiv bedient werden kann. Insbesondere, wenn Jira bereits für andere Anwendungsfälle im Unternehmen verwendet wird, macht die Ausweitung auf den Support durchaus Sinn, da auf diese Weise z.B. Support-Anfragen und Bugs miteinander verknüpft werden können.

Potential für Verbesserungen besteht aber durchaus. Obwohl in den letzten Jahren essentielle Funktionen wie mehrsprachige Benachrichtigungen, Textbausteine, Freigabeprozesse und Automatisierungen eingeführt wurden, bleiben viele Funktionen leider noch offen. Beispiele dafür sind: Vertretungs- und Abwesenheitsregelungen sowie gemeinsame Schemas für Anfragetypen. Da Atlassian allerdings weiterhin intensiv an der Funktionalität des Service Managements arbeitet, gehe ich von einer stetigen Verbesserung der genannten Funktionen aus.

4 Kommentare

  1. Guten Tag,

    Ich bin bei der Suche nach „JIRA Service Desk“ auf Ihren Beitrag gestoßen. Er gibt eine sehr schöne Übersicht über das neue Service Desk Plugin. Allerdings habe ich immer noch einen Punkt der mir etwas unklar ist und irgendwie nirgends wirklich erklärt wird. Das ist das Konzept der Agenten. Ist jeder interne Nutzer der in dem Projekt arbeitet, auf das der Service Desk aufsetzt, ein Agent? Oder ist ein Agent jemand, der die Tickets annimmt und an die richtigen Stellen leitet? Angenommen ich habe nur eine Person, die dafür zuständig ist die Tickets zu bewerten und zu verteilen, reicht mir dann rein theoretisch ein Agent? Kann ich das nach dem Prinzip der zwei Projekte, ServiceDesk und Interne Bearbeitung ablaufen lassen oder kann ein „Nicht-Agent“ auf die verlinkten Tickets des Service-Desk nicht zugreifen?

    Vielen Dank und Gruß,
    Steven

    • Hallo,

      da würde ein einzelner Agent ausreichen. Die Agenten sind diejenigen, die die Support-Ansicht des Projektes sehen (also die Queues, SLA-Levels etc.), Tickets bearbeiten können, sowie per Kommentar mit dem Autor des Tickets kommunizieren können. Die eingehenden Tickets werden also von den Agenten bewertet, ggf. gleich beantwortet, oder der Agent erstellt z.B. in einem anderen Projekt einen entsprechenden internen Vorgang (Bug, CR, Feature Request o.ä.) und verknüpft diesen mit dem offenen Ticket.

      Das Service-Desk Projekt (und die Vorgänge darin) sehen nur diejenigen Nutzer, die entweder in der Rolle „Administrator“, „Agent“ oder „Beteiligter“ eingetragen sind. Um also die ganz normalen Jira-Nutzer ebenfalls in das Service-Desk Projekt reinholen, muss man diese (z.B. per Gruppenzuweisung) zu „Beteiligten“ machen. Jeder in diese Rolle kann die Tickets sehen, Anhänge hochladen und interne Kommentare hinzufügen. Die Beteiligten können aber u.a. nicht: Tickets bearbeiten, als Bearbeiter eingetragen werden, den Status ändern, dem Kunden antworten. Das können nur die Agenten – am besten ist es also, wenn die Agenten eine Verteilfunktion haben. Wenn ein Agent ein Ticket nicht selbst klären kann, kann er entweder einen der „Beteiligten“ um Unterstützung bitten (Kommentar, darin per @username benachrichtigen) und der Beteiligte kann dann einen internen Kommentar als Antwort hinterlassen. Oder der Agent erstellt einen internen Vorgang in einem anderen Projekt und verküpft diesen mit dem Ticket.

      Eine gute Übersicht über die 4 Rollen und die entsprechenden Funktionen / Rechte gibt es auch unter https://confluence.atlassian.com/servicedesk/jira-service-desk-permissions-660967494.html.

      Beste Grüße,
      Sebastian

  2. Hallo zusammen, ich frage mich, ob jemand ein gutes Plugin (oder eine andere Möglichkeit) zur Anzeige von Links im JSM-Portal gefunden hat? Das scheint mir eine ziemlich grundlegende Funktion zu sein, aber ich habe bisher kein Plugin gefunden, das diese Funktion beinhaltet. Ich habe Issue Links von Deviniti ausprobiert, aber es zeigt verlinkte Probleme von anderen Kunden (Organisationen) an, auch wenn der Benutzer keinen Zugriff darauf haben sollte. Für jede Hilfe bin ich sehr dankbar!

    • Hallo Denise,
      das funktioniert mit der App Extension for Jira Service Management. Damit kann man für jeden Anfragetyp im Kundenportal auswählen, welche Arten von Verlinkungen für welche Jira-Gruppen angezeigt werden sollen. Ich benutze die App auch selbst in meinem Buchungsportal für offene Trainings.
      Viele Grüße,
      Sebastian

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.