Team KickAss: Arbeit da, wo es weh tut

Wenn Daniel Gnägi auf die Matte im Brazilian Jiu Jitsu Dojo in Zürich tritt, dann ist das nicht der einzige Kampf, den der 24-Jährige austrägt. Denn eigentlich war Daniel mal Amateur-Boxer mit viel Potenzial. Bis seine Schulter so verletzt war, dass er die Handschuhe an den Nagel hängen musste. Für immer.

Doch nicht nur das: Daniel hat seiner Heimat in der Ostschweiz nach dem Studium den Rücken gekehrt, denn in Zürich erwartet den Junior Software Engineer als erste Aufgabe nach dem abgeschlossenen Studium ein Kampf, den er nicht gewinnen kann: Retouren.

Daniel ist ein Mitglied des Teams KickAss.

«Glorreich ist das nicht, aber wir machen das mit Stolz», sagt Daniel. Er sitzt in einem Sessel, bequem zurückgelehnt, spricht weder laut noch unbedacht. Wenn er nicht gerade Interviews gibt, dann tippt er auf einer Tastatur herum. Seine Sprache ist nicht die Deutsche, sondern C#.

Das Sorgenkind eines jeden Online Retailers

Wenn Daniel über seine Arbeit spricht, dann sind ihm zwei Dinge wichtig: Er ist nicht der Chef des Teams. Und du musst verstehen, dass Retouren eines der grössten Probleme eines Online Retailers sind. «Backend-Abwicklung von Retouren und Garantiefällen» oder «After Sales» heisst das im Fachjargon. Ein Thema, wo Retailer den Ball möglichst flach zu halten versuchen. In einer idealen Welt sollen ja alle zufrieden mit der bestellten Ware sein.

«Denk das mal aus digitec-Sicht durch», sagt er und beginnt.

Du als Kunde kaufst etwas auf Galaxus. Dann ist das kaputt. Aus irgendwelchen Gründen. Also muss das zurück. Du gehst entweder in eine der neun Filialen oder schickst das Paket wieder zurück. Bereits da muss ein Prozess zwei Variablen abfangen, wenn du den Schadensfall mal pauschal als «Schadensfall» und nicht als gesplittete Sache wie «Handy: Bildschirm kaputt» und «Handy: Kamera kaputt» ansiehst. Denn dann müssten zwei Variablen auf zwei Variablen reagieren können.

Von da an wird es kurz einfacher: Das Retouren-Gerät geht ans After Sales Handling zurück. Aus dem Shop mit Lastwagen, sonst von der Post. Dann wird es wieder komplexer. Der Schaden muss begutachtet werden. Ist das Gerät noch zu retten? Dann an einen der über 2000 Lieferanten, mit denen Digitec Galaxus zusammenarbeitet. Postwege, Lieferfristen, Lieferkonditionen, Anforderungen an den Papierkrieg einer Retourenlieferung und so weiter bestimmen den Alltag der After-Sales-Abteilung.

Irgendwo muss das alles im System abgefangen, berücksichtigt und verarbeitet werden. Nachverfolgbar, effizient und so weit wie möglich automatisiert.

«Wir liefern immer mehr Waren aus, da kommt auch immer mehr zurück», sagt Daniel.

Darum scheint der Kampf wie einer, den er und KickAss nicht gewinnen können. Denn egal, wie einfach der Prozess wird, wie viel effizienter und schneller: Weniger Arbeit fällt in den Büros und Lagern der Firma nicht an. Und glücklich ist keiner mit irgendwas.

KickAss nimmt die Arbeit auf

«Vieles war noch manuell gelöst», sagt Daniel und seufzt, wenn er an die Anfänge seines Teams denkt, die auch gleichzeitig die Anfänge seines Berufslebens und seiner Arbeit bei Digitec Galaxus waren.

Daniel meldet sich als Solution Architect. Freiwillig. Und bekommt den Job. Oder besser: Die Rolle. Daniel Gnägi nimmt seine Arbeit auf. Es ist Kickass' erste Initiative.

«Working Class Hero» steht auf dem Shirt des Mannes. In einem Team von sieben Software Engineers und einem Product Owner versucht er, die Retourenabwicklung so schmerzfrei wie möglich zu machen.

Der Kampf beginnt in der Analyse der bereits vorhandenen Prozesse. Arbeitsplätze abbauen, daran glaubt KickAss nicht. Denn wenn Galaxus weiter wachsen soll, werden auch Retouren zunehmen. Da werden alle Köpfe gebraucht.

«Die Menge Handarbeit, die in den Retourenprozessen gesteckt hat, war doch schockierend hoch», sagt Daniel.

Daniel und KickAss gehen über die Bücher. Denn Prozesse optimieren anhand einiger kleiner Missgeschicke funktioniert nicht. Das Problem muss systemisch sein, damit eine Prozessoptimierung Sinn ergibt. Es bedarf einer eingehenden Analyse. Ist ein Issue anekdotisch – passiert also nur einmal, dafür aber spektakulär – oder ist es systemisch und passiert bei jedem Durchlauf des Prozesses?

«Noch genereller: Zuerst mussten wir erarbeiten, was genau welche Stelle im Prozess will.»

Es kommen Fragen. Und Fragen. Und Fragen.

Die Anforderungsanalysen müssen sitzen. Genau wie die Evaluation neuer Technologien. Einfach hier ein Script einbinden oder da ein paar Zeilen reinwurschteln, weil es gerade lustig scheint, zieht nicht. Denn am Ende hängt die Zufriedenheit aller an der Arbeit des Teams. Kunden sollten so kurz wie möglich mit Retouren zu tun haben. Die Mitarbeiter der Firma auch. Die Lieferanten und Reparaturstellen sollen alle Daten erhalten, die sie brauchen, und mehr nicht. Das ganze in einem Format, das ihnen passt, und am Ende muss das alles noch mit den Backends sowohl von Digitec Galaxus wie auch Dritter kompatibel sein.

Dazwischen müssen überflüssige Prozessschritte und -elemente abgeschafft werden. Je weniger Busywork da ist, also sinnlose Prozessschritte, desto besser.

Aus all dem entsteht ein Entwurf einer Architektur. Diese geht dann durch ein Review. Funktioniert alles? Wo sind Stolpersteine? Was könnte später zum Verhängnis werden? Braucht's das alles? Braucht's mehr?

Durchatmen.

Praktische Umsetzung. Neue Technologien? Vielleicht? Bringen die, was sie versprechen? Sind sie kompatibel mit uns? Mit anderen?

Fragen häufen sich. Daniel und KickAss ackern sie Story für Story, Sprint für Sprint, ab. Eine nach der anderen.

«So lahm das auch klingt, das war eigentlich hochspannend und hat Spass gemacht.»

Die Recherche, das Graben und Suchen, die Diskussion um Lösungen und der Gedanke, dass KickAss die Ersten und Einzigen sind, die sich allein diesem Thema widmen: das sind die Elemente, die Daniel anspricht, wenn er vom Spass spricht.

An die Arbeit. Code hier, eine Maske im firmeneigenen Backend da, Daniel und KickAss automatisieren, was sie nur können. Der Prozess wird stromlinienförmiger, schneller und schlagkräftiger. KickAss entwickelt die hauseigene Workflow Engine in .NET weiter. Passt sie an, wo nötig, integriert sie in den Retourenprozess, den sie dann dominiert. Busywork werden nach und nach abgeschafft. Das alles wird getestet. Events werden bei jedem Prozessschritt an den Azure Service Bus gesendet, um später die Daten auswerten zu können. Getestet wird jeder einzelne Schritt automatisch mittels Unit-Tests auf Basis NUnit. Dokumentiert sind die ganzen Prozesse und Diagramme in LucidChart.

Am Ende kann sich KickAss zurücklehnen. Oder eine Runde mit dem abteilungseigenen Drift-Go-Kart im Büro drehen. Denn der Prozess steht, ist geprüft, skalierbar und bereit für das Rollout.

Irgendetwas gibt es immer zu optimieren. KickAss kämpft weiter.