Freitag.ch Order Workflow: Lessions Learned

  • Tonio Zemp

Seit Februar 2021 ist der Relaunch von Freitag.ch online. Im Zentrum stand ein umfangreiches Versionsupgrade von Drupal. Das brachte viele Änderungen im Unterbau mit sich.

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.


Sag uns was du denkst