Jeder Anrufer willkommen

von Sandro Lucifora

Um Anwendern bei IT-Problemen schnell zu helfen, setzen große Unternehmen auf Help Desks und ITSM-Software wie Jira Service Management. Dessen Hersteller Atlassian empfand sein Produkt als ausgreift genug, um es auch als Supportwerkzeug für andere Abteilungen oder Branchen aufzubohren. Ob die Hilfestellung so gelingt, untersucht unser Test.

Atlassian beschreibt sein Angebot als IT-Service-Management (ITSM) mit Fokus auf IT-Teams und die Bereitstellung von IT-Services für Anwender. Im Detail liefert die Software dazu Werkzeuge, die alle Prozesse und Aktivitäten rund um die Planung, Zusammenstellung, Lieferung und den Support von IT-Services ermöglichen. Grundsätzlich lässt sich feststellen, dass ITSM-Teams sich um den Service in Bezug auf Hard- und Software kümmern, aber nicht auf reinen IT-Support beschränkt sind. Die Arbeiten können auch die Planung, Vorbereitung und Auslieferung von IT beinhalten. Diese Differenzierung ist sehr wichtig, um einzuordnen, unter welchen Gesichtspunkten wir Jira Service Management testen und bewerten.

Eigene Domain nur in Data-Center-Lizenz

Bevor wir uns die einzelnen Managementsektionen ansahen, richteten wir unseren Account ein. Die Registrierung erfolgte über ein Formular, in dem wir auch unsere Management-Domain einrichteten. Diese besteht aus einem frei wählbaren und noch nicht verwendeten Begriff, gefolgt von der Hersteller-Domain, in unserem Fall "itadmin.atlassian.net".

Eine eigenständige Domain erlaubt Jira Service Management in der Cloudversion nicht. Den Verkauf der bis vor kurzem verfügbaren Serverlizenz hat Atlassian eingestellt und bietet als selbstverwaltete Variante nur noch die Data-Center-Lizenz an. Diese ist für das AWS- oder Azure-Deployment optimiert und erlaubt eine vollständige Kontrolle der Umgebung wie auch das Verwenden einer eigenen Domain. Der Hersteller richtet sich mit dem Angebot jedoch an größere Unternehmen, da Jira Service Management Data Center mindestens 50 Agenten inkludiert.

Einfacher Einstieg dank Projektvorlagen

Wir konzentrierten uns auf die Cloudversion und erreichten nach Einrichten unseres Kontos und dem Aufruf unserer zugewiesenen URL die Konfiguration für unser Team. Teams können Aufgaben empfangen, verwalten und daran zusammenarbeiten, wobei ein Mitarbeiter verschiedenen Teams angehören kann. Jedes Team hat ein eigenes Projekt für seine Aufgaben. Daher begannen wir mit dem Erstellen unseres ersten Projekts.

Zum leichteren Erstellen des Projekts hatten wir die Auswahl aus sechs Vorlagen. Die klassische Vorlage ist "IT Service Management", die dazu dient, im IT-Support Anfragen zu erfassen und zu bearbeiten. Die Vorlage "Allgemeines Serviceprojekt" steht zum Verwalten von allerlei Serviceanfragen bereit. Diese müssen auch nicht aus dem IT-Bereich kommen, sondern können auch Buchhaltung, Personalwesen oder Nicht-IT-Kundendienst betreffen. Hilfreich für Teams, die externe Kundenanfragen beantworten sollen, ist die Vorlage "Externes Serviceprojekt". Hier liegt der Fokus darauf, ein eigenes Portal zu führen, über das Kunden Anfragen stellen und Lösungen erhalten. Eine weitere Vorlage ist optimiert für das Management von On- und Offboarding von Personal, eine andere für das Gebäudemanagement sowie eine für rechtliche Fragen bezogen auf die Vertragsverwaltung.

Für unser erstes Projekt wählten wir die Vorlage "IT Service Management" und vergaben einen Name als auch einen Schlüssel. Der Schlüssel ist das Präfix einer später automatisch erstellten Vorgangsnummer und dient der eindeutigen Zuordnung zum Projekt. Ein Agent (also der Mitarbeiter) lässt sich mehreren Teams und somit mehreren Projekten zuordnen. Wer bereits Jira Software benutzt, findet sich gut zurecht, da die Anordnung und Struktur von Jira Service Management weiterer Jira-Software sehr ähnelt und die Bedienung identisch ist.

Um uns die Vielfalt des Systems anzusehen, richteten wir noch ein Projekt mit der Vorlage "Externes Serviceprojekt" ein, um ein Kundenportal abzubilden, und eines mit der Vorlage "Serviceprojekt für Gebäudemanagement". Eine Vorlage lässt sich im Nachhinein nicht mehr ändern. Daher ist es wichtig, sich vorab mit den Vorlagen zu befassen und die richtige für die eigenen Anforderungen an ein Projekt auszuwählen.

Registrierung durch Anwender spart Zeit

Im übersichtlichen Dashboard sahen wir alle Projekte, auf die wir jeweils Zugriff hatten. An dieser Stelle finden die Agenten auch die wichtigsten Informationen darüber, wie viele Tickets offen und wie viele bereits zugewiesen sind.

Für den Test der Zuordnungen legten wir uns verschiedene Agenten an. Dazu wechselten wir von unserem Account in die Benutzerverwaltung. Diese Option sowie andere Systemzugriffe stehen Administratoren der Anwendung zur Verfügung. Bei Atlassian benötigt jeder Benutzer ein Konto für den Zugriff auf alle Atlassian-Produkte. Benutzt das Unternehmen zum Beispiel schon Jira-Software oder Confluence, reicht es, den jeweiligen Anwendern zusätzlich Zugriff auf Jira Service Management zu geben. Neue User erhalten eine Einladung, um ihren Atlassian-Account einzurichten. Dabei lassen sich neben den Produkten auch die Gruppen direkt zuordnen.

Gut gefallen hat uns dabei, dass wir auch zulassen konnten, dass sich Kollegen selbst registrieren durften, wobei wir die E-Mail-Adressen auf die Domain it-administrator.de beschränkten. Somit hat ein Administrator entsprechend weniger Aufwand und Anwender mit der erlaubten E-Mail-Adresse direkten Zugriff, ohne zusätzlichen Eingriff eines Administrators. Jedoch ist dabei zu berücksichtigen, dass das Unternehmen jeden neuen Benutzer für Jira Service Management bezahlen muss.

Verschiedene Portale steuern Support

Wir wandten uns wieder den Projekten zu und wollten uns ansehen, wie sich ein Ticket erstellen lässt. Wo Jira Service Desk in unserem Test Anfang 2015 den klaren Fokus auf reinen IT-Helpdesk legte, haben die Entwickler Jira Service Management an dieser Stelle wesentlich weiterentwickelt. Zuvor basierten Projekte auf unterschiedlichen Vorlagen, die wiederum für die Unterstützung verschiedener Aufgabenbereiche wie den Helpdesk konzipiert sind. Aber auch ein Kundenportal oder das Gebäudemanagement finden so Unterstützung. Dennoch sind die Wege, über die Anwender im System ein Ticket erstellen, identisch. Bei Jira Service Management werden sie Kanal genannt und teilen sich in E-Mail, Hilfscenter und Widget auf.

Das System generiert für jedes Projekt eine eigene E-Mail-Adresse, die auf die anfangs registrierte Management-Domain endet. Das erste Projekt bekam in unserem Fall "support@itadmin.atlassian.net", alle anderen erhielten eine E-Mail-Adresse mit dem Projektschlüssel. Über die E-Mail-Konfiguration konnten wir aber die E-Mail ändern. Ebenso war es uns möglich, das Projekt mit einem Google-, Microsoft- oder IMAP-Konto zu verbinden, um so die E-Mail-Adresse unserer eigenen Domain zu verwenden. Empfingen wir dann über die E-Mail-Adresse eine Anfrage, legte das System automatisch ein neues Ticket an. Ebenso versendet es an den Absender eine Empfangsbestätigung mit der Ticketnummer sowie einem Link zum selbigen.

Eine weitere Einstellung für das Erstellen eines Tickets per E-Mail bezieht sich darauf, ob jede E-Mail-Adresse eine Anfrage per E-Mail stellen darf oder nur solche, die vorher explizit ein Mitarbeiter hinzugefügt hat. Damit lassen sich Tickets durch Spam verhindern und auch sicherstellen, dass nur berechtigte Absender Tickets eröffnen.

Das Kundenportal dient nicht nur zum Erstellen von Anfragen, sondern stellt auch eine Wissensdatenbank bereit. Das ist jedoch nur zusammen mit Confluence möglich, einem weiteren Produkt aus dem Hause Atlassian, das hinzugebucht werden muss. Ansonsten gibt es eine Vielzahl an Einstellungen, um das Portal an die eigenen Bedürfnisse anzupassen. Neben einem Logo und der primären Farbe konnten wir auch festlegen, ob das Portal nur mit einem zuvor angelegten Login oder öffentlich zugänglich ist.

Die Anwendung des ersten Falls erfolgt, wenn so ein Zugang nur für die interne Verwendung dient. Öffentlich zugänglich muss es sein, wenn meist Endkunden Zugriff darauf haben sollen. In beiden Fällen erreichen die Anwender das Portal direkt über einen Link. Jedoch ist uns im Test aufgefallen, dass Anwender auch auf eine Übersicht navigieren und dort alle verfügbaren Portale einsehen können. In den Projekteinstellungen war es uns jedoch möglich, zwischen einem öffentlichen Zugang und einem nur für angemeldete Anwender zu unterscheiden. Damit haben wir die Interfaces für Kunden, IT-Support und für interne Belange getrennt, etwa das Personalwesen oder Gebäudemanagement. Uns gelang es jedoch nicht, ein Projekt komplett im Portal auszublenden.

Infrastruktur der Ticketerstellung mit Schwächen

Beim Erstellen einer neuen Anfrage wählen die Benutzer zunächst aus einer Gruppe und dann das Thema selber. Eine Gruppe ist eine Sammlung verschiedener Themen. So hatten wir zum Beispiel im Projekt für interne IT-Anfragen eine Gruppe "Logins und Accounts", in der sich dann zum Beispiel Anfragen wie "Abrechnungsprobleme lösen" oder "Neues Konto anfordern" oder "VPN zum Büro einrichten" befanden. In der Gruppe "Server und Infrastruktur" sammelten wir wiederum Themen wie "Änderung anfordern" oder "Melden fehlerhafter Hardware".

Gruppen sind nicht zwingend notwendig, erleichtern es Hilfesuchenden aber sich zurechtzufinden. In Gruppen lassen sich zum Beispiel auch Produkte oder Produktgruppen wiedergeben, unter denen sich dann spezifische Themen finden. Eine solche Struktur konnten wir leider nur über zwei Ebenen einrichten. Eine Gruppe in einer Gruppe ist nicht möglich. Dafür war es uns aber möglich, eine Anfrage in mehreren Gruppen zu platzieren. Das Anfrageformular bauten wir uns aus verschiedenen Optionen zusammen und bestimmten damit, welche Felder in der Agenten-Ansicht zu sehen und welche Felder im Anfrageformular vom Benutzer auszufüllen waren.

Im Test stellten wir leider fest, dass sich die Unterstützung mehrerer Sprachen nur auf das Userinterface beschränkt. So konnten Anwender zwar die Sprache ändern, aber die von uns selbst angelegten Texte wie Gruppen, Themen und Formularfelder blieben einsprachig. Aus unserer Sicht ist es damit nicht möglich, ein gut anwendbares, mehrsprachiges Kundenportal zu erstellen.

Die dritte Option, ein Ticket zu eröffnen, ist das Einbinden eines Widgets auf der eigenen Webseite. Damit sollte es möglich sein, eine Supportanfrage ohne Umwege über das Jira-Kundenportal zu erfassen. Wir schreiben hier im Konjunktiv, da es uns während der mehrwöchigen Testphase nicht gelang, ein solches Widget anzulegen. Entweder erhielten wir auf der Konfigurationsseite nur eine weiße Seite oder das System zeigte die Meldung "Das Widget kann nicht installiert werden. Bitte versuchen Sie es in Kürze noch einmal". Leider war Atlassian auch nach mehrfacher Rückfrage nicht in der Lage, die Ursache zu finden und zu beseitigen.

Als vierte Option, eine Anfrage zu erfassen, können Agenten im jeweiligen Projekt ein Ticket manuell anlegen. Das ergibt Sinn, wenn zum Beispiel telefonische Anfragen möglich sind. Dazu öffnete sich ein Dialogfenster, in das wir, genau wie im Portal der Kunde, den Anfragetyp festlegten, einen Titel und eine Beschreibung erfassten sowie den Auftraggeber hinzufügten. Das Hinterlegen möglicher Abhängigkeiten von anderen Tickets und der Priorität rundeten den Vorgang ab.

Schnelle Übersicht dank Warteschlange

Nachdem wir einen Einblick hatten, wie ein Ticket ins System kommt, interessierte uns die Arbeitsweise für einen Agenten. Das Wichtigste aus dessen Sicht ist zu erfahren, welche Tickets Aufmerksamkeit benötigen. Der erste Einstieg ist dabei die Warteschlage in einem Projekt. Hier bekommen Agenten schnell eine Übersicht abzuarbeitender Anfragen.

Die Filter halfen uns, spezifische Anfragen mit einem Blick zu erfassen. Die Standardfilter "alle offenen Tickets" und "alle meine Tickets" sowie "alle meine offenen Tickets" bieten schon eine erste Sicht auf die notwendigen Aufgaben. Gibt es im Team zum Beispiel Kollegen, die sich um ein bestimmtes Thema kümmern sollen, lässt sich für diese eine eigene Warteschlange anlegen, die alle Aufgaben dieses Themas zeigt. Filter konnten wir aber auch individuell erzeugen, etwas für Mitarbeiter, die Kundenanfragen für einzelne Produkte spezialisiert bearbeiten, oder für Kollegen, die hauptsächlich neue Benutzer auf einem Server anlegen. Damit diese Agenten die für sie wichtigen Aufgaben direkt im Blick haben, konnten wir entsprechende Warteschlangen anlegen, die dann die passenden Tickets zeigten.

Flexible Ticketbearbeitung

Wir schauten uns nun genauer an, wie ein Agent ein Ticket bearbeitet. Das Aufrufen des Tickets zeigt die Beschreibung und erlaubt das Erfassen verschiedener Aktivitäten. Neben Kommentaren hält der Agent hier auch die aufgewendete Zeit im Arbeitsprotokoll fest. Einen Kommentar fügten wir entweder als internen Hinweis hinzu oder trugen diesen als Antwort für den Kunden ein. Die Antwort versendete das System per E-Mail. Dabei ist es wichtig, interne Notizen und solche, die für den Kunden bestimmt sind, zu trennen.

Auf der rechten Seite hatten wir Zugang zu einigen Metadaten. Sehr prägnant prangerte direkt oben ein Hinweis zum SLA (Service Level Agreement). Hierbei handelt es sich um eine zuvor festgelegte Reaktionszeit, unterteilt in die Zeit bis zur ersten Antwort und die Zeit bis zur Lösung. SLAs ließen wir, basierend auf verschiedenen Kriterien, automatisch einem Vorgang zuweisen. Welcher Vorgang welches SLA erhält, haben wir per JQL (Jira Query Language) gefiltert.

Unter dem SLA finden wir die Angaben des zugewiesenen Agenten, des Autors, um welchen Anfragetyp es sich handelt, die Priorität und noch einiges mehr. Je nach Bedarf lassen sich auch individuelle Felder erstellen und beim Erstellen des Tickets, ob über das Portal oder von Agenten, eintragen. Das können die Seriennummer eines Geräts, die Version einer Hard- oder Software oder benötigte Zugangsdaten sein. Zu jedem Ticket lässt sich auch ein Sub-Task erstellen. Damit konnten wir Teilaufgaben an Kollegen delegieren oder abrechenbare von nicht abrechenbaren Aufgaben bei der Erfassung trennen.

Licht und Schatten im Changemanagement

Im Kalender für Änderungen sammelt ein Team geplante Änderungsanforderungen für die Serviceprojekte. Dabei handelt es sich um ein Ticket, das ein Agent anlegt und zusätzlich um Angaben der geplanten Ausführung ergänzt. Das ist eine großartige Lösung, um zukünftige Aufgaben im Blick zu behalten. Leider haben wir jedoch keine Möglichkeit gefunden, ein zum Beispiel vom Anwender bereits angelegtes Ticket nachträglich in den Kalender einzutragen.

Nur mit Opsgenie, einem weiteren Service von Atlassian, lassen sich Dienste, Warnungen und Bereitschaften über Jira Service Management verwalten. Bei Opsgenie handelt es sich um ein Bereitschafts- und Warnmeldungsmanagement, über das Teams Ausfälle und Services planen oder die Bereitschaft für Notfälle abwickeln. Muss ein Administrator zum Beispiel einen Server neu starten oder ein Update durchführen, kann an dieser Stelle ein Eintrag erfolgen, auf den die Agenten im Service entsprechend reagieren können. Wir hätten uns gewünscht, dass diese Funktion Bestandteil von Jira Service Management ist und nicht separat gebucht werden muss.

Fazit

Jira Service Management fokussiert sich vorrangig auf die Unterstützung im IT-Bereich. Da sich nahezu alles individuell konfigurieren lässt, öffnet sich das Help-Center aber auch für andere Branchen und Service-Fälle. Mit etwas Kreativität und Konfiguration wird aus dem reinen IT-Support-Produkt ein Service-Portal für alle Branchen. Die Aufteilung in Projekte und die Gruppierung einzelner Mitarbeiter zu einem Projektteam ist eine gute Lösung, um strukturierte Hilfestellung zu geben. So konzentriert sich jeder Agent auf seine Kernkompetenzen. Die Warteliste ist dabei ein gutes Hilfsmittel, um die eingehenden Anfragen direkt gefiltert zu bearbeiten.

Die Flexibilität, wie Tickets ins System kommen, ist gut. Nach unserer Auffassung deckt der Hersteller alle Wege ab. So erstellt Jira Service Management automatisch ein Ticket aus einer eingehenden E-Mail und bietet auch ein Portal, über das die Hilfesuchenden selbst eine Anfrage eröffnen können. Leider ist es uns im Test nicht gelungen einzelne Projekte aus dem Portal auszublenden. Jedoch war es uns möglich über das Portal gezielt den Zugriff auf Projekte auch für nicht eingeloggte Anwender zu erlauben.

Die Bearbeitung eines Tickets ist sehr gut und intuitiv gelöst. E-Mails kann der Kunde an eine von Atlassian definierte E-Mail senden oder der Administrator richtet eine dedizierte E-Mail-Adresse der eigenen Domain ein. Sub-Tasks zur Delegierung von Teilaufgaben machen die Bearbeitung sehr flexibel.

Insgesamt hat uns Jira Service Management strukturell, von der Bedienung als auch der Flexibilität gut gefallen. Dass wir kein Widget anlegen konnten, wirft nach unserer Meinung einen größeren Schatten auf das sonst gute Angebot. Auch die Tatsache, dass wir für den Aufbau einer Wissensdatenbank noch ein Confluence-Abo benötigen, finden wir bei der vorliegenden Preisgestaltung sehr schade. Denn genau so eine Funktion ist für einen guten Service, sowohl für die Agenten als auch den Anwender, unerlässlich.

Produkt	ITSM-Software, die auch außerhalb des IT-Supports für Kundenportale zum Einsatz kommen kann.
Hersteller	Atlassian https://www.atlassian.com/de/software/jira/service-management
Preis	Ab 20 US-Dollar pro Agent und Monat. Auf Jahreslizenzen gibt es Rabatte.
Systemanforderungen	Webbrowser mit HTML5.
Technische Daten	https://www.it-administrator.de/downloads/datenblaetter/