Optimierung der Prozesse im Retoureneingang: E-Commerce Case Study für den B2C-Bereich

Viele Menschen kaufen heutzutage ihre Waren sowohl im stationären Handel als auch in Online-Shops (vgl. Asdecker et al. 2021, S. 606). Der Online-Einkauf beschränkt sich dabei nicht nur auf Produkte wie Kleidung oder Lebensmittel, sondern beinhaltet auch die Bestellung von Möbeln, z. B. Sofas, Wandschränke oder Tische (vgl. Statista 2021). Im Jahr 2020 lag das Wachstum des E‑Commerce weltweit bei einem Spitzenwert von 25,7 %. Dieser Spitzenwert lässt sich u. a. auf die Schließung des stationären Handels durch die Corona-Pandemie zurückführen (vgl. eMarketer 2021). Zudem wird prognostiziert, dass der Wachstum weiter anhält und der Umsatz insbesondere im Online-Möbelhandel in Deutschland von 14,55 Mrd. € im Jahr 2020 auf 27,54 Mrd. € im Jahr 2025 steigen wird (vgl. Statista 2022). Ein solch starkes Wachstum kann dazu führen, dass die logistischen Prozesse eines Unternehmens im B2C-Bereich mit erheblichen Herausforderungen konfrontiert werden. Vor allem kleine und mittelständische Unternehmen, die noch nicht ausreichend digital arbeiten, können ihre Logistikprozesse nicht datenbasiert auswerten bzw. automatisieren (vgl. Statista 2022).

Die vorliegende E‑Commerce Case Study wird durch einen deutschen Kooperationspartner mit internationalem Kundenstamm unterstützt, welcher den Hauptsitz in Deutschland hat. Das Unternehmen vertreibt als Versandhändler für Möbel und Wohnaccessoires seine Waren ausschließlich online und weltweit über mehrere internationale Online-Shops. Während die Anzahl der Bestellungen im Vergleich zum Vorjahr in 2019 bei + 39,4 % lag, war diese im Jahr 2020 bei + 84,4 % und 2021 wiederum bei + 60,4 %. Der Anstieg belastet laut eigenen Aussagen die logistischen Prozesse im Wareneingang, Warenausgang und im Retourenlager spürbar. Zudem sind die Prozesse im Retourenlager, im Gegensatz zu anderen Bereichen, wenig digitalisiert. Somit wird versucht, das vermehrte Retourenaufkommen durch den Einsatz von mehr Personal zu kompensieren. Ziel dieses Artikels ist es, diese eher kurzsichtige Vorgehensweise zu vermeiden und im Bereich des kurativen und des reaktiven Retourenmanagements (Asdecker 2014, S. 22 ff.; Deges 2017, S. 29 ff.) eine Methode bzw. einen Prototypen zur Unterstützung der Bearbeitung der Retouren zu entwickeln. Hierzu stellt das Unternehmen einen Datensatz bereit und ermöglicht es, den erstellten Prototyp zur Optimierung der Prozesse im Retoureneingang vor Ort zu erproben.

Bei Retouren handelt es sich um Rücksendungen von Produkten, die der Kunde innerhalb des gesetzlich gewährten Widerrufsrechts (100 Tage) initiiert. Retouren können z. B. vorkommen, wenn die Waren dem Kunden nicht gefallen. Es kann auch sein, dass Retouren von vornherein geplant sind, wenn der Kunde z. B. eine Auswahl bestellt (vgl. Asdecker und Sucky 2018, S. 294 ff.). Retouren im Möbelhandel sind durch extrem hohe Transport- und Bearbeitungskosten sowie Wertverluste gekennzeichnet. Somit kommt dem Retourenmanagement, da es eine starke Hebelwirkung auf den Unternehmenserfolg besitzt, eine maßgebliche Bedeutung zu (vgl. Asdecker 2015, S. 1 ff.; vgl. Deges 2017, S. 33).

In Meißner et al. (2022) wurde ein Data-Mining-Framework zur Identifizierung von interessanten und nicht-intuitiven Beziehungen in Retourendaten vorgestellt. Das im Framework integrierte Frequent Itemset Mining (FIM) konnte für die vorliegende Untersuchung adaptiert werden. Hierbei wurde FIM eingesetzt, um häufig vorkommende Retouren-Charakteristika zu erkennen (vgl. Lezcano und Arias 2020). Dabei wurden die Itemsets mit nur einem Item betrachtet und nach dem Support (d. h. der Anzahl des Auftretens) sortiert. Das Resultat war eine Liste mit eindeutig nachvollziehbaren Retouren-Charakteristika und deren Häufigkeiten. Es ergab sich aus dieser Analyse bei unserem Kooperationspartner bspw., dass Retouren fast ausschließlich in Form von Paketsendungen (LogisticType = Parcel) zurückkommen (Support von 0,97), die Retouren oftmals Artikel nur eines Herstellers beinhalteten (0,88) und häufig von einem bestimmten Versanddienstleister zurückgeliefert wurden (0,81). Im Datensatz, der für das FIM genutzt wurde, wurden die Retourendaten mit Flags (Kennzeichnung bestimmter Zustände) versehen. Die Flag „ReturnQuantity“ kennzeichnete die Unterscheidung der Retoure in Single Return (= 1 Artikel) oder Multiple Return (> 1 Artikel). Der Support der Single Returns lag bei 0,78. Eine detaillierte Analyse der Items ReturnQuantity = {Single Return, Multiple Return} ist somit sinnvoll, um Optimierungspotentiale in der Retourenbearbeitung aufzudecken.

Bei Betrachtung der Abb. 1 und der darin enthaltenen Bearbeitungszeiten von Retouren wird ersichtlich, dass die geringste Bearbeitungszeit bei den Retouren mit nur einem Artikel auftritt. Die Bearbeitungszeit steigt mit jedem weiteren Artikel an. Des Weiteren ist ein ansteigender Trend der Bearbeitungszeiten der Retouren ausgehend vom Jahr 2019 bis zum Jahr 2022 für alle Artikelanzahlen sichtbar. Somit wird immer mehr Zeit benötigt, um die Retouren im Lager abzufertigen. Als Beispiel lag die durchschnittliche Bearbeitungszeit in 2019 für eine Retoure mit einem Artikel bei 121,8 s, in 2020 bei 129,5 s, 2021 bei 147,6 s und 2022 (Q1 und Q2) bei 161,7 s. Dabei hat sich in diesen Jahren das Sortiment des Kooperationspartners nicht so stark verändert, als das sich hierdurch die steigenden Zeiten erklären lassen könnten, z. B. durch ein neues Sortiment an Artikeln, die schwerer zu retournieren wären.

Die durch das FIM und die Analyse der Transaktionsdaten gewonnene Erkenntnis, dass 97,0 % der Retouren in Form eines Pakets zurückgesendet und 81,0 % der Retouren von einem bestimmten Versanddienstleiter des Kooperationspartners zurückgeliefert werden, bildeten den Grundstein der vorliegenden Case Study. Dabei erfolgt eine Fokussierung auf Retouren, die erstens als Paket und zweitens von dem besagten Versanddienstleister zurückkommen. Im Juli 2022 wurden vom Versanddienstleister bspw. mindestens 159 Retouren-Pakete, maximal 372 und im Durchschnitt 241 pro Tag angeliefert.

Der Prozess des Retoureneingangs lässt sich wie folgt beschreiben: An jedem Werktag kommt mindestens ein LKW des Versanddienstleisters mit Paket-Retouren an. Diese Retouren sind per Zufallsprinzip auf Transporthilfsmittel (THM) geladen. Die THM werden aus dem LKW entnommen und dann zufällig Lagermitarbeitenden zugewiesen, welche die darauf liegenden Pakete einzeln retournieren. Der Retourenprozess arbeitet nach dem FIFO-Verfahren. Das Abarbeiten jedes einzelnen THM passiert iterativ, bis alle leer sind. Jedes Retouren-Paket des Dienstleisters verfügt über ein Rücksendeetikett mit der Rechnungsnummer der entsprechenden Kundenbestellung sowie mit zwei Barcodes (Sendungsverfolgung und Auftragsnummer). Diese drei Nummern bzw. Attribute sind im ERP-System des Kooperationspartners gespeichert.

Zur Bewältigung der steigenden Anzahl an Retouren und der resultierenden Arbeitslast wurden in den vergangenen Jahren zunehmend mehr Personen eingesetzt. Maximal arbeiteten im Retourenlager im Jahr 2019 6 Personen an Retouren-Paketen, 2020 waren es 11 Personen, 2021 15 und 2022 (Q1 und Q2) 17 Personen. Werden die Anzahl der Retouren-Pakete in Relation gesetzt zu der Anzahl der Lagermitarbeitenden der einzelnen Jahre, so wird ein absteigender Trend in der Menge an verarbeiteten Retouren-Paketen ersichtlich. Im Jahr 2019 wurden maximal 137 Pakete pro Person und Tag retourniert. 2020 waren es noch 123, 2021 maximal 80 Retouren.

Auf der Grundlage der Bearbeitung im FIFO-Verfahren und der zunehmend geringer werdenden Anzahl an Paketen, die Lagermitarbeitende im Durchschnitt bearbeiten, wird in vorliegender Case Study ein Lösungsansatz zur Prozessoptimierung vorgestellt. Es gilt festzustellen, ob die datenbasierte Vorsortierung von Retouren sowie die gezielte Zuordnung der Retouren zu den Fähigkeiten der Lagermitarbeitenden die durchschnittliche Retourenbearbeitungszeit verringert bzw. die Anzahl der Retouren pro Person erhöht. Wir formulieren also die Hypothese, dass eine Vorsortierung der Retouren zu einer Verringerung der Bearbeitungszeiten pro Retoure führt.

Da eine datenbasierte Auswertung von eintreffenden, noch geschlossenen Retour-Paketen nicht möglich ist, jede Retoure allerdings auf einer Rechnung basiert und sämtliche Rechnungsdaten aller Kundenbestellungen vorliegen, werden zum Vorsortieren die Rechnungsdaten der Kundenbestellungen verwendet. Bei der Einteilung der Retouren in Klassen, können die Erkenntnisse des FIM und aus der Abb. 1 bzgl. der Bearbeitungszeiten ausgenutzt werden. Daher werden zunächst zwei Gruppen gebildet: Kundenbestellungen mit einem Artikel und Kundenbestellungen mit mehreren Artikeln. Insbesondere in Paketen der ersten Gruppe ist nur ein zu retournierender Artikel enthalten. In der zweiten Gruppe können ein oder mehrere Artikel vorhanden sein. Durch die Einteilung können aufwändige und arbeitsintensive Retouren den erfahreneren Mitarbeitenden zugewiesen werden (zweite Gruppe). Es wird dabei davon ausgegangen, dass erfahrenere Lagermitarbeitende schneller retournieren können als Unerfahrene. In Abstimmung mit dem Retourenlager werden die beiden gebildeten Gruppen weiter verfeinert. Eintreffende Retouren können somit vier Klassen zugeordnet werden. Die erste (und zweite) Klasse umfasst sämtliche Retouren mit einem Artikel und einem Gesamtgewicht von weniger als 10 kg (bzw. gleich oder mehr als 10 kg). Die Klassen 1 und 2 sind somit beide eher für Unerfahrenere vorbehalten. Die Unterscheidung nach Gewicht ist nützlich, um Retouren den körperlichen Voraussetzungen der Personen im Lager zuzuordnen. Die dritte Klasse gilt den Erfahreneren, die Retouren mit mehreren, unterschiedlichen Artikeln und Bearbeitungsschritten abfertigen können. Die vierte Klasse, die sogenannten Klärfälle, umfasst Retouren, die weitere Abstimmung benötigen und eventuell von Fachkräften bearbeitet werden müssen. Es handelt sich um Retouren aus dem Ausland, Retouren mit nicht lesbaren Etiketten, Retouren mit fehlenden Teilen und Retouren ohne Widerrufsrecht. Die Bearbeitungszeit der Retouren aus Klasse 4 ist laut Kooperationspartner als besonders lang anzusehen.

Das ERP-System besitzt bei Eintreffen einer Retoure keinerlei Informationen darüber, welche Artikel einer Kundenbestellung retourniert wurden. Um dies festzustellen, müssen die Retouren von den Lagermitarbeitenden ausgepackt und überprüft werden. Bei einer Vorsortierung der Retouren kann daher grundsätzlich nur auf die Angaben auf dem Retourenpaket (Rechnungsnummer, Sendungsverfolgung und Auftragsnummer) zurückgegriffen werden. Für die Entwicklung des Prototyps wurde somit ein Datensatz bestehend aus Rechnungsdaten erstellt. Der Datensatz wurde mittels MySQL aus dem ERP-System abgefragt, als CSV exportiert und in eine Excel Datei konvertiert. Die vorliegenden Daten erstrecken sich über den Zeitraum der vergangenen 100 Tage gemäß der Widerrufsfrist des Unternehmens. Alle Bestellungen, die nach 100 Tagen retourniert werden, sind von der Widerrufsfrist befreit und werden somit nicht vom Prototyp gefunden (Klärfall). Jede relevante Kundenbestellung (insg. über 170.000 Bestellungen) ist mit entsprechenden Attributen im Datensatz aufgeführt. Als Attribut gilt z. B. die Anzahl der versendeten Pakete einer Sendung oder auch die Kombination aus Sendungsverfolgung mit Auftrags- und Rechnungsnummer (Feld zum Suchen und Finden im Prototyp). Tab. 1 zeigt exemplarisch alle exportierten Attribute einer Kundenbestellung (Zeile im Datensatz) mit datenschutzkonformen Beispielwerten.

Der Prototyp zur Vorsortierung eintreffender Retouren wurde in Excel entwickelt. Die Maske des Prototyps ist in Abb. 2 zu sehen, wobei bestimmte Informationen geschwärzt sind. Es wurde also keine direkte Einbettung des SQL in das ERP-System vorgesehen, da das ERP-System wegen der IT-Infrastruktur im Lager zur Verarbeitung der eingescannten Daten wesentlich mehr Zeit benötigt als ein lokal gespeicherter Prototyp entwickelt in Excel. Die langsame Verarbeitung ergibt sich, weil Tabellen und Subqueries im SQL eine sehr große Datenmenge abfragen und dann das Ausgeben der gewünschten Information pro Scanvorgang bis zu 20 s dauern kann. In der Excel Datei sind die Informationen, aufgrund des im Vorfeld exportierten Datensatzes und der Suchfunktion innerhalb derselben Datei, wesentlich schneller verfügbar (max. 3 s). Der Prototyp beinhaltet auf dem Tabellenblatt „Datenbank“ die über 170.000 Bestellungen mit Attributen. Des Weiteren existiert das Tabellenblatt „Maske“, welches die Ein- und Ausgabemaske des Prototyps bildet und von den Lagermitarbeitenden verwendet wird. In der Maske ist die Zelle für die „Suche“ farblich in gelb hinterlegt (Eingabefeld). Das Eingabefeld ist dabei mit keinerlei Funktion versehen und nimmt die eingegebenen oder gescannten Werte lediglich entgegen. Unterhalb des Eingabefeldes befinden sich die Bezeichnungen der Attribute (erste Spalte von Tab. 1) mit entsprechenden und daneben liegenden Ausgabefeldern. Die Werte der Attribute werden nach dem Scan gefüllt. Hier ist jede Zelle mit einer separaten Sverweis-Funktion versehen, die in der Datenbank die Zeichenkette aus dem Eingabefeld sucht.

Rechts neben den Ausgabefeldern befinden sich fünf weitere Zellen, die untereinander sortiert jeweils mit einer Wenn-Funktion versehen sind. Die Logik der fünf Zellen ist dabei zusammenhängend; nur die Bedingungen einer der fünf Zellen können pro Retoure wahr sein. Sind die Bedingungen nicht erfüllt, steht eine „0“ in der entsprechenden Zelle. Die fünf Zellen visualisieren durch farbliche Hervorhebung, in welche Klasse die soeben gescannte Retoure eingeordnet werden soll. Das erste Feld (hellgrün) repräsentiert die erste Klasse und umfasst alle Retouren mit einem Artikel und einem Gewicht von weniger als 10 kg. Das zweite Feld (orange) gilt der zweiten Klasse und verfügt über die gleichen Bedingungen, wobei ein Gewicht größer oder gleich 10 kg angegeben ist. Das dritte Feld (pink) umfasst die dritte Klasse und fragt ab, ob in der ursprünglichen Kundenbestellung mehr als ein Artikel versendet wurde. Das Gewicht ist hier nicht entscheidend. Das vierte und fünfte Feld repräsentiert zusammengefasst die vierte Klasse. Das vierte Feld (rot) leuchtet auf, wenn zwar nur ein Artikel verschickt, dieser aber auf mehrere Pakete aufgeteilt wurde. Das fünfte Feld (schwarz) wird markiert, wenn keine Daten gefunden werden, die Retoure also die Widerrufsfrist überschritten hat. Eine Retoure wird nun nach einem Scan im Rahmen der Vorsortierung und gemäß der angegebenen Farbe einer Klasse zugeordnet. Im Anschluss kann dann eine Zuordnung zu einem Lagermitarbeitenden erfolgen, z. B. könnte eine orange Retoure von einem unerfahrenen und kräftigen Lagermitarbeitenden übernommen werden.

Die Hypothese der Case Study, dass eine Vorsortierung und gezielte Zuweisung eintreffender Retouren die Bearbeitungszeiten verringern kann, wurde im Rahmen eines Versuchs im Retourenlager des Kooperationspartners geprüft. Hierzu wurde an unterschiedlichen Werktagen (02.–, 17.–, 18.– 19.08.2022) der Eingang des Retourenlagers freigeräumt und zu Schichtbeginn 10 leere THM (d. h. Corletten) in zwei Reihen aufgestellt. 8 Corletten wurden vorgesehen, die Klassen 1 und 2 (fünf Corletten) sowie 3 (drei Corletten) abzudecken. Die restlichen zwei Corletten dienten zum Sammeln der Klärfälle. Die Anzahl der Corletten richtete sich nach der durchschnittlichen Tageszufuhr an Retouren-Paketen von 261 Stück. Weitere THM sind bei Bedarf zugriffbereit.

Die Abarbeitung der Corletten erfolgte so, dass mit dem vorhandenen Personal zuerst die bearbeitungsintensiven und dann die weniger zeitaufwendigen Klassen behandelt werden. Die Koordination wurde von Vorgesetzten übernommen, welche die Fähigkeiten der Mitarbeitenden kennen. Diese Abarbeitungsweise dient u. a. auch der Motivation, weil zum Tagesende hin die abzuarbeitenden Retouren stetig weniger bearbeitungsintensiv werden.

Retouren entstehen meist nicht planmäßig sondern oft durch Einflussfaktoren wie z. B. Transportschäden. Solch zufällige Ereignisse sorgen dafür, dass die Anzahl von eintreffenden Retouren nicht immer konstant ist und täglich voneinander abweicht. Um eine Optimierung der Bearbeitung an den Evaluierungstagen auswerten zu können, mussten Tage mit ähnlichen Bedingungen gefunden werden. Diese Tage sollten durch die gleiche Anzahl an Mitarbeitenden sowie eine vergleichbare Anzahl an Retouren gekennzeichnet sein, nach Möglichkeit auch am gleichen Werktag stattgefunden haben. Die Auswertung wurde dann hinsichtlich der drei Aspekte durchgeführt: (1) durchschnittliche Retouren pro Person, (2) die gesamte Bearbeitungsdauer an diesem Tag (unabhängig von Schichten) und (3) die durchschnittliche Bearbeitungszeit pro Retoure. Eine Gegenüberstellung der Evaluierungstage und der Vergleichstage, die ähnliche Bedingungen hatten, ist in Tab. 2 ablesbar.

Während unsere Evaluierungstage im August durchgeführt wurden, fanden die Vergleichstage im Mai, Juni oder August statt. Laut Kooperationspartner besitzen diese Monate keine signifikanten, saisonalen Schwankungen und sind daher miteinander vergleichbar. Eine Vergleichbarkeit wird durch die gleiche Anzahl an Mitarbeitenden und eine ähnliche Anzahl an zu bearbeitenden Retouren zusätzlich unterstützt. Dabei sei anzumerken, dass die Ausprägungen der Pakete, z. B. Größe und Gewicht, nicht bei der Auswahl des Vergleichstages beachtet wurden.

Werden in der Spalte „Retouren pro Mitarbeitenden“ in Tab. 2 die Werte der vergleichenden Tage betrachtet, so wurden an allen Vergleichstagen durchschnittlich mehr Retouren pro Person retourniert im Gegensatz zum Evaluierungstag. Hinsichtlich unseres ersten Aspekts ist eine Verschlechterung durch den Prototyp erkennbar. Betrachten wir allerdings die weiteren Aspekte, wird eine Verbesserung durch die Vorsortierung der Retouren mittels des Prototyps deutlich. Die gesamte Bearbeitungsdauer (von der ersten bis zur letzten Retoure) aller Tage hat sich im Schnitt um 1:35 h verringert. Die Pakete wurden im Schnitt 49 s schneller retourniert. Die geringere Anzahl der Retouren pro Person begründet sich dadurch, dass generell die Anzahl der Retouren an den Evaluierungstagen geringer war als an den Vergleichstagen (bei gleicher Anzahl an Mitarbeitenden). An den Evaluierungstagen wurden in der eingesparten Zeit sonstige Aufgaben wie z. B. fegen, Verpackungsmüll entsorgen, usw. erledigt, so dass diese Aufgaben nicht an weitere Schichten übergeben werden mussten.

Die Ergebnisse weisen darauf hin, dass eine Optimierung der Retourenbearbeitung durch das beschriebene Vorgehen möglich ist. Auf Wunsch des Kollegiums wird der Prototyp weiterhin eingesetzt und täglich mit neuen Daten gefüllt. Die Vorsortierung soll mittels einer Webapplikation Bestandteil der Retourenbearbeitung werden.

Darüber hinaus kann eine Weiterentwicklung des Prototyps auf unterschiedliche Weise vorgenommen werden. Beispielsweise ist die Integration einer Vorhersage denkbar, ob eine Retoure der Klasse 3 (Rechnung mit mehr als einem Artikel) doch als Single Return zu behandeln ist. Aus Abb. 3 wird ersichtlich, dass bei Käufen mit mehr Artikeln, z. B. 2, 5 oder 7, doch sehr häufig nur ein Artikel retourniert wird. Die Visualisierung zeigt die Artikelanzahl einer Rechnung in Relation zu der retournierten Artikelanzahl und der absoulten Häufigkeit am Beispiel des Juli 2022. Zur Umsetzung könnte die in Toktay et al. (2004, S. 4) beschriebene naive estimation angewendet werden. Hierzu würden u. a. die Retourenquoten der einzelnen Artikel im Datensatz ergänzt und hierauf basierend Berechnungen zur Ermittlung der Wahrscheinlichkeit der retournierten Artikelanzahl angewendet werden. Die naive estimation Methode wurde mit anderen Data-Mining-Techniken verglichen und erzielte im Vergleich gute Ergebnisse (vgl. Karl 2016, S. 210).

Auch denkbar wäre es den Retourenprozess in einer Simulation abzubilden, um ausgewählte Indikatoren, wie bspw. Bearbeitungszeiten oder Größe und Gewicht von Paketen, unter Berücksichtigung von verschiedenen Gegebenheiten im Lager auszuwerten. Eine Simulation ist z. B. mittels des Java-basierten Simulationstools AnyLogic möglich (vgl. Trott et al. 2019, S. 329). Zudem besteht die Möglichkeit weitere Optimierungspotentiale (z. B. hinsichtlich des Layouts) vorab digital zu sichten und zu prüfen (vgl. Muravev et al. 2021).