Überblick

Der Servicevertrag mit dem Kunden sah vor, dass defekte Hardware innerhalb von 4h beim Kunden ausgetauscht werden kann. Dazu können die Techniker des Kunden in einem Serviceportal rund um die Uhr Anfragen stellen und ein Express-Logistiker wird automatisch benachrichtigt.

Umgebung

Vorausgegangen war an dieser Stelle ein etabliertes Auftragsmanagement. Dabei konnten die entsprechenden Assets und deren Serviceverträge bereits in InSight (Assets) hinterlegt werden. Angereichert wurden diese noch um eine Standortzuordnung.

Jira Servicemanagement bildet die Plattform des Ganzen. Zur Identifizierung des richtigen Kunden und seiner Assets wurden Jira User dem entsprechenden Kontakt in InSight zugeordnet, welcher wiederum einer oder mehreren Firmen zugeordnet sein kann.

Die Optik von JSM wurde durch Refined verbessert, die E-Mail-Funktionen durch „Email This Issue“.

Da beim Kunden eine begrenzte Anzahl von Produkten eingesetzt wird, konnten basierend auf den Hauptkomponenten sogenannte Sets zusammengestellt werden. Diese beinhalten die Hauptkomponenten sowie andere im Zusammenhang stehende Komponenten, welche ebenfalls kaputt sein könnten oder den Fehler verursachen könnten. Es wurden mehrere Sets definiert, in Redundanz Boxen (Peli Cases oder Paletten) zusammengestellt und bei einem Express-Logistiker eingelagert.

Feinheiten

Da das ganze Portal quasi mandantenfähig ist und so Mehrfachaccounts vermieden werden, wird vom User zunächst die korrekte zugehörige Firma und darauf aufbauend der Standort ausgewählt. In einer Assets-Selectliste erscheinen dadurch nur noch Assets dieses Standorts, was recht performant funktioniert. Die Sichtbarkeit von anderen Firmen und Standorten ist komplett auf das notwendige Maß eingeschränkt. Kein User kann Daten anderer User oder Kunden sehen.

Dann geht alles recht schnell:

• Nach Auswahl des defekten Artikels ist automatisch das zugehörige Set klar
• Die Ticketerstellung wird über Slack benachrichtigt
• Im Ticketworkflow wird nach Erstellung des Tickets eine kleine Karenzzeit (ein eigener SLA) abgewartet, damit ein Agent falls notwendig in die automatische Verarbeitung eingreifen kann.
• Nach Ablauf des SLAs erfolgt eine automatische Transition in welcher das Expresslager per E-Mail informiert wird. In dieser ist lediglich der Set-Typ aufgeführt, so dass eines der redundanten Sets genommen und ausgeliefert wird. Die E-Mail beinhaltet ebenso die Adresse des Standorts sowie die Kontaktdaten eines Technikers, welcher ebenfalls bei der Ticketerstellung ausgewählt wurde.
• Durch Antwort auf die E-Mail wird der Empfang und der Beginn der Auslieferung im Ticketworkflow vermerkt.

Vor Ort wartet der Fahrer einige Zeit ab, ob das Problem durch einen schnellen Hardwaretausch behoben werden kann. Falls ja, wird der defekte Artikel markiert, in die Box gepackt und der Fahrer nimmt diese wird mit. Die Box wird dann an die Logistik des Hardwarelieferanten zur Überprüfung und Vervollständigung gesendet. Falls es länger dauert, übernimmt dies der Techniker.

Im Ticket wird automatisch ein Retoure-Ticket für die Logistik erstellt mit welcher die bald eingehende Box avisiert wird. Im Ticket wurde automatisch eine Checkliste für die Überprüfung angelegt. Weitere Tickets übernehmen

• die potentielle Nachbestellung der neuen Hardware
• die Entsorgung oder Aufbereitung der defekten Hardware
• Seriennummer, Service- und Lizenzumschreibungen
• den Wiederversand der aufbereiteten Box an den Express-Logistiker
• und weitere Randtätigkeiten

Fazit und verwendete Apps

Die Erfahrung der wenigen Austausche zeigt, dass der Ersatz oft in weniger als zwei Stunden beim Kunden und verbaut ist.

Folgende Apps sind involviert:

• Jira Service Management
• Refined for Jira
• InSight (Assets)
• JSM Automation
• Jira Email This Issue
• Checklist for Jira