Selbständiger IT-Berater und Trainer. 14 Jahre Erfahrung in der Beratung, Einführung und Schulung von Jira als Supportsystem verwenden
Inhalt
Eines der häufigsten Einsatzgebiete von Jira sind Supportprojekte. Egal ob intern, für ausgewählte Kunden oder öffentlichen Support – Jira deckt viele der daraus resultierenden Anforderungen bereits von Haus aus ab und kann mit ein wenig Know-How zu einem leistungsfähigen Supportwerkzeug entwickelt werden. In diesem Artikel möchte ich einige Tipps und Erfahrungen weitergeben, mit denen einfache Supportszenarien in Jira umgesetzt werden können.
Anforderungen
Als Grundlage wähle ich ein Szenario, das mir in der Praxis immer wieder begegnet: eine Firma möchte den internen Support mit Jira abwickeln und ggf. noch ein paar externe Kunden mit auf das System lassen. Der Einfachheit halber betrachten wir im Folgenden sowohl Mitarbeiter als auch Externe als gleichberechtigte „Kunden“ des Supports. Die Anforderungen an ein solches Projekt können natürlich je nach Infrastruktur, Firmenphilosophie, Firmengröße etc. vollkommen unterschiedlich ausfallen. Häufig begegnen mir jedoch Varianten folgender Anforderungen:
- Kunden können nur Supporttickets erstellen, keine Bugs und Aufgaben
- Kunden haben keinen Zugriff auf interne Fehlermeldungen
- Kunden sehen nur eigene Tickets
- Supportmitarbeiter werden über neue Tickets informiert
- Supportmitarbeiter haben eine gemeinsame Übersicht offener Tickets
- Supporttickets können eskalieren
Konzept
Wie bei der Einrichtung jedes neuen Projektes müssen zunächst einige grundlegende fachliche Fragen geklärt werden. Dazu gehört u.a.:
- Welche Vorgangstypen sollen verwendet werden
- Welche Felder (Metainformationen) benötigen diese Vorgangstypen
- Welche Rechte sollen Kunden und Supportmitarbeiter haben
- Wie sehen die Arbeitsabläufe für Supporttickets aus, müssen ggf. Prozesse beachtet werden
- Welche Benachrichtigungen sollen versendet werden
Eine der ersten Entscheidungen dieses Szenarios besteht darin, die Supportabwicklung innerhalb eines oder mehrerer Projekte stattfinden zu lassen. Diese Entscheidung hängt davon ab, wie offen das Supportprojekt für Kunden sein wird. Bei internen Supportprojekten oder kleineren Unternehmen bietet es sich durchaus ein, nur ein einzelnes Supportprojekt zu verwenden und den Kunden lesenden Zugriff auf alle Vorgänge – also auch auf Fehlermeldungen – zu ermöglichen. Die Vorteile: Kunden können vor dem Erstellen eines Tickets recherchieren, ob bereits eine Fehlermeldung für ihr Problem vorliegt und sich ohne eine zusätzliche Supportanfrage über deren Bearbeitungsstatus informieren. Das schafft Transparenz und spart Arbeit, setzt allerdings einen offenem Umgang mit Fehlern voraus.
In unserem Szenario gehen wir von dem – in meiner beruflichen Praxis – häufigsten Fall aus: Kunden können nur Supporttickets erstellen und haben keinen Zugriff auf das interne Fehlermanagement. Aus diesem Grund entscheiden wir uns dafür, den Support in zwei Projekte aufzuteilen:
- Projekt „Support“: hier erstellen die Kunden Tickets und kommunizieren mit den Mitarbeitern des Supports. Kunden sehen nur die von ihnen selbst erstellten Vorgänge.
- Projekt „Fehlermanagement“: hier findet die interne Fehlerabwicklung statt. Das Projekt ist nur für berechtigte Personen lesbar, Kunden haben keinen Zugriff. Fehler und Aufgaben werden per Link mit den auslösenden Supporttickets verknüpft.
Vorgangstypen und Berechtigungen
Im Projekt „Support“ lassen wir ausschließlich den Vorgangstyp „Supportticket“ zu, den wir ggf. vorher erstellen und mit geeigneten benutzerdefinierten Feldern (Name des Kunden, Telefonnummer etc.) ausstatten.
Für die Anforderung „Kunden sehen nur eigene Tickets“ müssen wir das Berechtigungsschema verwenden: Kunden dürfen hier nicht durch Gruppen- oder Rollenzugehörigkeit die Berechtigung „Projekte durchsuchen“ erhalten. Stattdessen erteilen wir der vorgangsbezogenen Rolle „Autor“ diese Berechtigung. Das führt dazu, dass alle Nutzer dieses Projekt sehen – wer jedoch nicht durch Gruppen- oder Rollenzugehörigkeit eine Leseberechtigung besitzt, sieht nur die von ihm selbst erstellten Vorgänge, da er hier die Vorgangsrolle „Autor“ besitzt. Alle anderen Berechtigungen für Supportmitarbeiter etc. können entsprechend ihrer Rollen vergeben werden.
Workflows
Für die Einrichtung geeigneter Workflows verweise ich auf die Artikel Jira FAQ: Workflows und Jira Workflows: Best Practices und typische Fehler. Generell empfehle ich meinen Kunden, einfache und übersichtliche Workflows zu verwenden, die nur die wirklich notwendige Schritte als Status abbilden.
Beispiel für einen einfachen Supportworkflow in Jira
Benachrichtigungen
Prinzipiell kann man in Jira bei jeder Vorgangsänderung (Erstellt, Bearbeitet, Kommentiert, Statuswechsel etc.) eine Mail-Benachrichtigung an beliebige Nutzer (Rollen, Gruppen…) versenden. Ich rate jedoch dazu, Benachrichtigungen sparsam einzusetzen, da schnell ein Überfluss an Mails versendet und damit ein gegenteiliger Effekt erzeugt wird: Mails werden nicht mehr gelesen. Für Supportfälle empfehle ich, den Mitarbeitern des Supports nur wichtige Änderungen per Mail zu schicken, z.B. wenn ein neues Ticket erstellt wird oder ein Ticket eskaliert. Ansonsten empfehle ich den Einsatz von gemeinsamen Filtern und Dashboards, mit denen sich alle Mitarbeiter des Supports gemeinsame Sichten auf die offenen Supporttickets anlegen können.
Dashboard
Jira bietet die Möglichkeit, eigene Dashboards zu erstellen und diese für bestimmte Nutzergruppen freizugeben. Für die Supportabwicklung bietet es sich also an, ein gemeinsames Dashboard für alle Supportmitarbeiter zu erstellen, auf dem alle wichtigen Informationen zu finden sind. Wichtige Gadgets können z.B. sein:
- Mir zugewiesene Supporttickets
- Filter: Nicht zugewiesene Supporttickets
- Filter: Eskalierte Supporttickets
- z.B. letzter Kommentar länger als 48h her
- z.B. nicht zugewiesen und Erstellung länger als 24h her
Eskalation
Je nach Anforderungen bietet Jira verschiedene Möglichkeiten, mit Eskalationsstufen umzugehen. Die einfachste Möglichkeit besteht darin, per Filter eine individuelle Ansicht auf eskalierte Vorgänge zu erstellen (siehe Punkt „Dashboard“). Auch einfache SLA-Level können damit abgebildet werden. Zusätzlich kann ein eigener Status „Eskaliert“ in den Workflow eingebaut und Vorgänge per Jelly Script automatisch nach einer gewissen Zeit in dieses Status verschoben werden.
Für komplexere Anforderungen bezüglich SLA-Levels bietet sich das kostenpflichtige Plugin VertygoSLA an.
Weitere Anforderungen
Damit sind die Möglichkeiten von Jira natürlich keineswegs erschöpft. Für Supportprojekte in geschlossenen Systemen besteht z.B. die Möglichkeit, Support-Mailadressen einzurichten, mit denen Tickets per Mail erstellt und direkt aus dem System heraus beantwortet werden können. Die dafür notwendige Konfiguration würde allerdings den Rahmen dieses Artikels übersteigen – bei Fragen zur Einrichtung von Jira als Supportsystem freue ich mich auf Ihre Kontaktaufnahme oder einen Kommentar.
Hallo Sebastian,
Ich bin gerade dabei unser Jira ein wenig aufzubessern. Wir nutzen es, wie in deinem Artikel beschrieben, als Supportinstrument für unsere Mitarbeiter (Jira Kunden) und IT Mitarbeiter (Jira Agents). Was ich mich nun frage ist, ob es eine Möglichkeit gibt, Agenten an gewisse Vorgangstypen oder Vorgangsgruppen anzuhängen (bzw. zu zuweisen)? Beispielsweise wäre der Agent A für den Vorgangstyp A im Projekt A zuständig und der Agent B für den Vorgangstyp B im selben Projekt A. Dadurch würde bei der Erstellung eines Vorgangs vom Typ A direkt der Agent A zugewiesen.
Vielen Dank für dein Feedback.
Beste Grüsse
Dominique
Hallo Dominique,
die Funktion gibt es meines Wissens nach nicht, aber es gibt einige Alternativen:
die einfachste wäre, in Service Desk eine eigene Queue für jeden Agenten anzulegen, die jeweils nur bestimmte Vorgangstypen umfasst. Dann sieht jeder Agent nur „seine“ Vorgangstypen (https://confluence.atlassian.com/display/SERVICEDESK/Make+queues+for+your+service+desk+teams). Falls ihr kein Service Desk nutzt, könnt ihr alternativ auch ein Dashboard für jeden Agenten anlegen (bzw. der Agent für sich selbst), und darin dann per Filterergebnis nur die Vorgänge eines bestimmten Typs o.ä. anzeigen lassen, damit jeder Agent sein persönliches Support-Dashboard hat.
Die zweite Möglichkeit wäre, mit Komponenten zu arbeiten: ihr legt für Vorgangstyp A eine eigene „Pseudo“-Komponente an, für B ebenfalls. Danach tragt ihr den jeweiligen Agenten als Komponentenleiter ein (siehe https://confluence.atlassian.com/display/JIRA/Defining+a+Component). Wenn dann ein Vorgang erstellt und dabei eine Komponente mit einem Komponentenleiter ausgewählt wird, bekommt derjenige den Vorgang automatisch zugewiesen.
Die dritte Möglichkeit wäre, das Ganze mit dem Script Runner zu lösen. In diesem Fall könntet ihr als Folgefunktion des Erstellen-Übergangs ein Script einbauen „If Vorgangstyp = X then Assignee = Y“ usw. Das würde genau eure Anforderung umsetzen, wäre aber auch sehr unflexibel.
Ich persönlich würde zu der Variante mit den Queues/Dashboards tendieren, da diese am einfachsten umzusetzen und von der Funktionalität her auch dafür vorgesehen ist.
Grüße,
Sebastian
Hallo Herr Höhne,
ich habe eine Frage zu den Queues.
Ich möchte, dass wenn ein Kunde eine Supportanfrage per Mail oder ServiceDesk stellt der Vorgang in einer bestimmten Queue angezeigt wird. Also Beispielsweise Kunde A von der Firma X stellt eine Anfrage, da möchte ich eine Queue X haben in die alle Anfragen aller Kunden der Firma X rein laufen. Vielleicht gibt es die Möglichkeit einen Filter zu setzen in dem ich sage alle Mails mit der Adresse *@X.com sollen in die Queue X rein laufen.
Vielen Dank im Voraus für Ihre Antwort.
Beste Grüße
P. Gniech
Hallo Frau Gniech,
eine elegante Lösung fällt mir dafür leider nicht ein – das Problem dabei ist, dass in dem „Autor“ bzw. „Reporter“ Feld keine Suche mit Platzhaltern möglich ist (siehe https://jira.atlassian.com/browse/JRA-23571), dadurch kann man keine Queue mit „*@x.com“ erstellen. Als Workaround könnten Sie ein neues benutzerdefiniertes Feld mit einer Auswahlliste hinzufügen. In diesem Feld wird eine Firmenliste gepflegt und der Supporter kann dann die entsprechende Firma in jedem Ticket auswählen. Wie gesagt, muss aber sowohl die Liste manuell gepflegt werden als auch die Zuordnung der Tickets manuell passieren (sofern man nicht anfangen möchte, mit Skripten zu arbeiten).
Mit einem solchen Feld könnten Sie aber zumindest für jede Firma eine Queue anlegen und dort jeweils den entsprechenden Wert der Auswahlliste in die Queue aufnehmen. Ein Freitextfeld für die Firmen ist in dem Fall leider nicht möglich, da bei der Suche kein Platzhalter als erstes Symbol erlaubt ist, damit könnte man dieses Feld in der Queue also wieder nicht auswerten.
Eine bessere / einfachere Lösung ist mir derzeit leider nicht bekannt.
Dennoch beste Grüße aus Dresden,
Sebastian Höhne
P.S. Evtl. wäre dieses Plugin: https://marketplace.atlassian.com/plugins/com.intenso.jira.plugins.jsd-extender noch einen Blick für Sie wert – ich habe mich selbst noch nicht damit beschäftigt, aber ggf. ist ja dort eine entsprechende Funktion enthalten.