Ü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