Freitag.ch Order Workflow: Lessions Learned

Freitag hat die Gelegenheit zusammen mit uns genutzt, einige Lessions Learned aus den letzten 5 Jahren anzugehen. Damit investiert Freitag auch digital in die Nachhaltigkeit. Und gemeinsam investieren wir in eine langjährige Beziehung. Wichtiger Bestandteil des Relaunches war der Order Workflow, dazu nun mehr.

Freitag verkauft Taschen aus Lastwagenplane. Fast alle Produkte sind also Unikate. Die eine eigene “stock tracking unit” (SKU) benötigen und bei Freitag jeweils mit dem Bestand 1 im Lager sind. Ist ein Produkt verkauft, kann es nicht erneut produziert werden. Eine echte Herausforderung im Onlineshop. Diese Eigenheit erfordert nicht nur im Bereich User Experience (UX) oder der Technologie Lösungen abseits vom Best-Practice-Pfad, sondern auch eine äusserst geringe Fehlerquote beim Order Workflow. Corner Cases beim Checkout, Fulfillment oder Versand könnten dazu führen, dass ein Produkt von zwei Personen erworben wird, das macht bei einem Unikat zwangsläufig jemanden unglücklich.

Hintergrund: Systeme

Neben ein paar Micro Services sind vorwiegend zwei Systeme im Workflow involviert:

1. Drupal (Warenkorb, Checkout, Bestellaufgabe, Bestelländerung, Stornierung, Kundenkommunikation, Filial-Kommunikation, Promotions- und Gutschein Management)
2. Das ERP von Freitag (Lagerhaltung, Fulfillment, Versand, Controlling, Retouren).

Freitag möchte uneingeschränkte Einkaufsmöglichkeiten für ihre Kund*innen ermöglichen. Und das selbst wenn das ERP nicht verfügbar ist (z.B. aufgrund von Wartungen). Zudem bedient Drupal noch weitere Systeme und Use Cases und benötigt daher einen umfassenderen Datenstamm im Bereich der Order. Eine duale Lösung mit unterschiedlichen Systemen versprach eim Launch 2016 und beim Relaunch 2021 den besten “Return on in Investment” (ROI). Eine stärkere Teilung in Micro-Services hätte durch die speziellen Anforderungen bei wenigen Vorteilen deutlich mehr Investitionen verursacht.

1. Lessions Learned: Klare Aufgabenteilung ist wichtig

Durch den erwünschten unabhängigen Betrieb und die viele out-of-the-box Funktionen beider Systeme gab es Doppelspurigkeiten, die im Betrieb zu Corner Cases führen konnten. Gewisse Bestellstatus konnten von beiden Systemen vergeben werden. Berechnungen von Rabatten und Verteilschlüssel für Rückerstattungen mit mehreren Zahlungsmittel, fanden teilweise in beiden Systemen statt. Ein Update der ERP Schnittstelle ermöglicht nun die bidirektionale Kommunikation. Statt dem früheren regelmässigen Abfragen spricht nun das ERP Drupal direkt an. Dies war einer der Aspekte die es ermöglichten die Aufgaben klarer zu teilen.

Beispiel Bestellstatus: Nach wie vor gibt es zwei Repräsentationen der Bestellung, eine im ERP und eine im Drupal. Der Prozess beginnt im Drupal früher (Warenkorb und Checkout) und endet später (Omni-Channel, Abholung in Store etc.). Neu hat während der Verarbeitung im ERP (Fulfillment und Versand) ausschliesslich das ERP die Kontrolle über den Status. Da Änderungen und Stornierungen auch in dieser Phase anfallen, kann Drupal Änderungen und Stornierungen anfragen. Es ist aber immer das ERP welches die Status Transition bei Drupal auslöst.

Beispiel Rückerstattung: Für Kreditkarten, Gutscheine und Promotion Codes hat Drupal die Anbindung an die betreffenden Systeme. ei einer Rückerstattung mit mehreren Zahlungsmittel entschied Drupal welche Beträge auf welche Zahlungsmittel gutgeschrieben werden. Die Grundlage für die Buchhaltung war jedoch stets das ERP. Auch wenn vermeintlich gleiche Regeln angewendet wurden, konnte es zu Abweichungen kommen. Neu hat die Hoheit ausschliesslich das ERP und kann über eine Schnittstelle mit Drupal kommunizieren, welcher Betrag über welches Zahlungsmittel rückerstattet wird.

Wo immer mit einem verträglichen ROI möglich, wiesen wir weiteren Teilprozessen eine klare Hoheit zu. Nach wenigen Monaten lässt sich noch nicht genug über die langfristige Stabilität des Workflows aussagen. Die bisherigen Erfahrungen im Betrieb sind jedoch bereits positiv.

2.Lessions Learned: automatischer Lagerbestand

Da der Lagerbestand fast aller Produkte 1 oder 0 ist, und die Systeme unabhängig funktionieren müssen, verbirgt sich einiges an Komplexität in diesem Bereich. Wenn Bestellungen abseits vom Standardprozess verändert werden, oder in eine manuelle Bearbeitung wechseln, darf ein bestelltes Produkt nicht wieder online kaufbar sein. Auf der anderen Seite darf das “wieder online stellen” bei dem vorliegenden Transaktionsvolumen auch kein manueller Prozess sein. Denn, dies bindet zu viele Arbeitskräfte.

Bisher hatten wir einen physischen Lagerbestand (ERP Lagerbestand) und einen virtuellen. Der Letztere diente dazu, Phasen zu überbrücken, bei welchen das ERP nicht verfügbar oder einen veralteten Stand hatte. Diese Lösung hat in weit über 99% der Fälle funktioniert. In wenigen aber regelmässigen Fällen führte das allerdings zu “-1” oder “+2”. Die wenigen Unstimmigkeiten waren aufgrund der Komplexität schwer nachvollziehbar.

Beim Relaunch haben wir die doppelte Lagerführung beibehalten. Eine wichtiges Prinzip zur Vereinfachung wurde jedoch eingeführt: “das ERP hat immer Recht”. Andererseits jedoch auch komplexer gestaltet mit einem weiteren Layer: Den Reservationen. Weil das ERP eben nicht immer recht hat schützen Reservationen zusätzlich vor einem ungewollten Doppelverkauf. Durch die Vereinfachung der Stock-Logik und den nur Drupal-seitigen Reservationen ist bei einem Vorfall nun deutlich einfacher nachzuvollziehen welches System was gemacht hat. Das ist besonders jetzt in den ersten Monaten sehr hilfreich.

3. Lessions Learned: Tracking-Nummer

Ja, je nach Setup kann auch eine Tracking-Nummer herausfordernd sein. Freitag versendet global und mit unterschiedlichen Dienstleistern. Diese haben unterschiedliche Mechanismen ob und wann eine Tracking-Nummer generiert wird und ab wann diese abrufbar ist. Letzteres ist der gewünschte Zustand in einer Versandbestätigung. Die bisherige Logik wann das Versandmail generiert wird hat in komplexer Form die verschiedenen Szenarien abzubilden versucht. Mit Polling aufs ERP, Bestell-Typen, Versandmethoden, befüllten Feldern und abzuwartenden Zeiträumen. Trotzdem kam es zu oft vor, dass eine Versandbestätigung zu früh oder zu spät versendet wurde. Versuche das Regelwerk zu verbessern haben oft zu Folgeproblemen geführt. Das galt es zu lösen.

Beim Relaunch haben wir im Order Workflow einen neuen Status eingeführt “verpackt”. In diesem Zustand ist die Bestellung tatsächlich verpackt, vielleicht auch schon unterwegs, aber die Tracking-Nummer ist noch nicht bekannt oder aufrufbar. Tritt letzteres ein, meldet das ERP den Status “versendet”. Bei diesem Status generiert Drupal die Versandbestätigung, egal ob eine Tracking-Nummer da ist oder nicht. So sind die Aufgaben klar verteilt und können bei Problemen viel einfacher nachvollzogen und gelöst werden. Das ERP kann einfacher den Zustand der Tracking-Nummer einschätzen und Drupal braucht ein Regelwerk weniger. Diese Änderung ist bereits erpropt und hat sich als äusserst robust erwiesen.

Zusammenfassung: Vereinfachen durch Komplexität

Vereinfachen ist unser natürlicher Liip-Instinkt. Denn, unsere Erfahrung zeigt, dass die Herausforderungen bei der Umsetzung und im Betrieb, so minimiert werden. An den obigen Beispielen ist erkennbar, dass Vereinfachung auch über vermeintlich mehr Komplexität führen kann. Schliesslich haben wir ja weitere Schnittstellen, zusätzliche Layer und einen neuen Bestellstatus eingeführt. Alle drei Massnahmen machen das System jedoch deutlich robuster. Und ermöglichen , bei Zwischenfällen schneller Fehler zu erkennen. Im laufenden Betrieb ist das für die Investitionen in Weiterentwicklungen essenziell. Denn wir wollen mit unseren Kund*innen ihre Produkte/Lösungen weiterentwickeln und keine reine Systemerhaltung betreiben.