Ü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

Überblick

Das vorhandene ERP wies Schwächen im Bereich der Prozessierung von Aufträgen auf. So war es nicht möglich, konsistente Daten zu erzwingen und Triggeraktion für andere Abteilungen zu definieren. Die Übersichtlichkeit und auch die Reportfähigkeit war sehr marginal.

Key-Feature und Herausforderungen:

• Ergänzung des ERPs mit einem stabilen Prozess- und Workflow-Management
• Getriggerte Aktionen für andere Abteilung
• Synchronisierung der ERP-Daten nächtlich und nach Anforderung
• Bereitstellung von Übersichten über anstehende, fällige und überfällige Aufgaben
• Nahtlose Kommunikation vom Vertrieb in alle Abteilungen

Datenhaltung und Synchronisierung

Die erste Herausforderung war die Datenhaltung. Die bisherige Assets-App war nicht mächtig genug sodass InSight ins Spiel kam. Entstanden sind vier Schemata für Stammdaten, Produkte, interne und externe Assets. Neben Kunden und Kontaktdaten wurden Objekttypen für Aufträge, Bestellungen, Versand, Rechnung uvm. erstellt. Eine besondere Herausforderung hier war zudem, dass zwei Mandaten (Brands) getrennt und gemeinsam dargestellt werden mussten. So gibt es bei den meisten Objekttypen nun ein Hauptelement (schwarz) und zwei Children mit komplett vererbten Eigenschaften (grün und blau). So kann nicht zuletzt durch die Farbe Zugehörigkeit eindeutig erkannt werden.

Die Synchronisierung gestaltete sich etwas komplexer. Da das ERP eine doppelte Authentifizierung verlangt, konnten die Daten nicht direkt durch die InSight Importfunktion abgerufen werden. Die Datenabfrage erfolgt per Groovyscript, welches die Daten abholt, aufbereitet und als CSV-Importdatei im Filesystem ablegt. Dann wird aus dem Script heraus der Import von InSight getriggert. Dies geschieht regelmäßig durch mehrere zeitlich gestaffelte Scriptrunner Jobs.

Zusätzlich gibt es in den Tickets die Möglichkeit eine Direktsynchronisierung bestimmter Objekte. Dabei werden die Daten abgerufen, aufbereitet und per Script nach InSight geschrieben.

Fehlerquellen an dieser Stelle sind gleichzeitige Abrufe sowie die Laufzeit der Scripte und Importe.

Struktur des Prozesses

Da mehrere Abteilung teilweise parallel an einem Auftrag arbeiten war schnell klar, dass dies nicht nur mit einem einzigen Ticket funktioniert. Sequentielle Tickets sind aber zu verstreut. So viel die Wahl auf Subtasks. Ein Hauptticket, welches den Auftrag darstellt, hat diverse Untertickets mit verschiedenen IssueTypes wie z.B.

• Beschaffungsticket starten im Einkauf und werden von der Logistik/Technik weiter verarbeitet
• Versandtickets werden am Ende des Beschaffungstickets halbautomatisch erstellt und bilden den Versand an den Kunden ab
• Eingangsrechnungstickets werden automatisch bei der Bestätigung des korrekten Warenempfangs erstellt
• Ausgangsrechnungstickets werden nach Abschluss des Versandtickets automatisch werden
• Vertrags- und Lizenzmanagement-Tickets werden auf Knopfdruck durch den Einkauf erstellt und vom Servicemanagement bearbeitet
• Technikertickets für Consulting beim Kunden werden durch den Einkauf ebenfalls auf Knopfdruck erstellt
• Einige weitere Spezialtypen, die Teillieferungen, -rechnungen und Versendungen sowie Bestellungen fürs Lager und Retouren abbilden.

Die (halb-)automatische Erstellung der Tickets erfolgt dabei größtenteils per Groovyscript, da weder JSU noch Scriptrunner andere Subtasks unter dem gleichen Parent erstellen konnten und diese teilweise mit zusätzlichen Informationen aus InSight angereichert werden.

Übersichtlichkeit

Jedes Team/Abteilung hat ihr eigenes speziell angepasstes Kanbanboard. Darauf werden alle Tickets teilweise über Swimlanes gegliedert dargestellt. Dringende („Sameday“) Tickets können durchgängig über die Flag-Funktion gekennzeichnet werden. Diese Flag vererbt sich weiter.

Filter-Subscriptions für überfällige Anlieferungen, bevorstehende Versendungen sowie Dashboards und spezielle Teamleiter-Dashboards runden das Ganze ab. Ebenso eine individuell erstellte Übersicht der Subtasks im Hauptticket mit den jeweils pro Subtask sinnvollen Spalten.

Der Vertriebsmitarbeiter kann so jederzeit den Status sowie wichtige Details seines Auftrags einsehen und zur Not einschreiten. Das Hauptticket wird dabei bezogen auf das am weitesten „zurückliegende“ Unterticket automatisch im Status weitergeschoben. Nach der Bearbeitung durch den Einkauf ist das Hauptticket nicht mehr bearbeitbar, damit keine wichtigen Infos nachträglich dort erfasst werden, die Bearbeiter der Untertickets davon aber nichts mitbekommen. Um dennoch nachträglich Änderungen an wichtigen Feldern wie z.B: den Arbeitsanweisungen pro Abteilung ändern zu können, gibt es eine Spezialtransition, welche ausgewählte Felder editiert und diese Änderung an alle Untertickets weiterreicht. Teilweise wird dafür auch eine Slackbenachrichtigung ausgelöst.

Verwendete Apps

• InSight
• Scriptrunner
• BetterPdf
• JETI
• JSU