Zurück im Lager, offen im System: Retouren in automatisierten Prozessen

Zwei Paletten am Tor und eine Gutschrift, die schon draußen war

Retouren sind in den meisten Automatisierungen die Stelle, an der ein sauber gebauter Prozess aufhört und eine Excel anfängt. Der Weg zum Kunden läuft durchgehend über Schnittstellen, der Weg zurück über ein Mailpostfach, einen Bereich im Lager, den alle "Klärung" nennen, und eine Person, die weiß, welche Palette zu welchem Kunden gehört.

Ein Großhändler für Labor- und Praxisbedarf, rund sechstausend Artikel, neunhundert Kunden, darunter zweiunddreißig Kliniken und ein Dutzend Pflegeeinrichtungen. Bestellungen kommen über ein Kundenportal, per Mail und bei den drei größten Häusern direkt aus deren Warenwirtschaft. Eine Automatisierung liest die Bestellung, legt den Auftrag im ERP an, erzeugt Lieferschein und Rechnung und meldet die Sendung beim Dienstleister an. Sie läuft seit drei Jahren.

Für Retouren hatte jemand den gleichen Weg gebaut, nur rückwärts. Der Kunde meldet die Rücksendung über ein Formular, das Lager scannt beim Wareneingang den Beleg, die Automatisierung erzeugt die Gutschrift und bucht die Menge zurück in den Bestand. Zwei Schritte, beide technisch unauffällig.

An einem Dienstag im März kamen vierzehn Kartons Reagenzien von einer Klinik zurück. Auf dem Formular stand "falsch bestellt". Die Automatisierung erzeugte eine Gutschrift über 4.180 Euro und buchte 336 Einheiten in den verfügbaren Bestand. Drei Tage später gingen 90 davon an ein anderes Haus raus.

Die Kartons hatten zwei Wochen auf einer Station gestanden, neben einem Fenster, im März bei zwölf Grad Außentemperatur und ungeklärter Raumtemperatur. Kühlpflichtig, laut Etikett zwischen zwei und acht Grad. Niemand hatte in die Kartons geschaut, bevor die Gutschrift raus war, und niemand hatte den Bestand gesperrt, bevor er wieder verkauft wurde. Der Fehler fiel auf, als das empfangende Labor bei einer Kontrolle nachfragte, warum die Chargennummer auf dem Lieferschein zu einer Lieferung gehörte, die drei Wochen älter war als das Lieferdatum.

Das Nachspiel dauerte elf Tage: Rückholung, Ersatzlieferung, ein Gespräch mit der Qualitätssicherung der Klinik, eine Notiz in der Lieferantenbewertung. Der Warenwert war das kleinere Problem.

Wir sehen dieses Muster in fast jedem Projekt. Beim Auftrag denken alle nach, weil dort Umsatz entsteht. Bei der Retoure denkt niemand nach, weil dort nur Aufwand entsteht, und weil sie in den Zahlen als kleine Prozentzahl auftaucht. Drei bis fünf Prozent der Positionen, so hört man es oft. In der Bearbeitung sind es dann fünfzehn bis zwanzig Prozent der Arbeitszeit im Innendienst.

Eine Retoure ist keine Lieferung rückwärts

Der Denkfehler, aus dem fast alle anderen folgen, steckt schon im Datenmodell: Die Retoure wird als negativer Auftrag oder als umgekehrte Lieferung abgebildet. Menge mal minus eins, gleicher Artikel, gleicher Kunde, fertig.

Eine Lieferung hat zwei Zustände, die zählen: unterwegs und angekommen. Eine Retoure hat mindestens fünf, und jeder davon kann Tage dauern.

Sie wird angekündigt, oder eben nicht. Sie trifft ein. Sie wird geprüft, und zwar körperlich, von jemandem, der den Karton öffnet. Es wird entschieden, was mit der Ware passiert und was der Kunde bekommt. Und erst dann wird gebucht, im Bestand und in der Buchhaltung.

Wenn eine Automatisierung diese fünf Zustände auf einen einzigen Schritt zusammenzieht, verschwinden sie nicht. Sie wandern nur aus dem System heraus in die Köpfe der Leute im Lager. Dort funktionieren sie erstaunlich lange, bis jemand krank wird, das Volumen steigt oder eine Klinik nachfragt, wo ihre Gutschrift bleibt.

Der zweite Unterschied ist die Richtung der Information. Bei einer Lieferung weiß Ihr System alles: was drin ist, was es gekostet hat, wann es rausgeht. Bei einer Retoure kommt die Information von außen, unvollständig, oft falsch, manchmal gar nicht. Ein Karton am Tor ist erst einmal nur ein Karton.

Der Wareneingang, den niemand angekündigt hat

Die saubere Variante beginnt mit einer Ankündigung: Der Kunde meldet die Rücksendung, bekommt eine Retourennummer, klebt sie auf den Karton. Der Wareneingang scannt, und das System weiß sofort, um welche Lieferung es geht.

Das funktioniert im Handel mit Endkunden gut, weil es dort ohne Label keine Rücksendung gibt. Im B2B funktioniert es weniger gut, aus einem Grund, der nichts mit Technik zu tun hat: Der Fahrer nimmt die Palette einfach mit. Die Station hat aussortiert, der Hol- und Bringdienst steht ohnehin auf dem Hof, und niemand ruft vorher im Einkauf an. Bei Kliniken kommt dazu, dass die Station gar nicht die Stelle ist, die bestellt hat. Die Station kennt weder Bestellnummer noch Lieferschein, sie kennt den Karton.

Für die Automatisierung heißt das: Ein Teil der Retouren wird nie angekündigt, und dieser Teil ist bei manchen Kunden die Mehrheit. Ein Prozess, der eine Retourennummer voraussetzt, verarbeitet dann nur die Hälfte der Fälle. Die andere Hälfte landet in dem Bereich, den alle "Klärung" nennen, und die Automatisierung meldet trotzdem "keine Fehler".

Dagegen hilft nur, die Annahme umzudrehen. Der Prozess sollte damit rechnen, dass Ware ohne Papier ankommt, und dafür einen eigenen Weg haben: einen Retourenvorgang, der im Lager beginnt, mit Foto, Artikel, Menge, Kundenzuordnung, soweit erkennbar. Ein Vorgang mit Lücken ist besser als kein Vorgang, weil er zumindest existiert, ein Datum hat und in einer Liste auftaucht.

Woran die Zuordnung scheitert

Der häufigste Auslöser für Handarbeit ist die Zuordnung zur Ursprungslieferung. Sie klingt trivial und ist es nicht.

Kunden nennen die Nummer, die sie sehen. Das ist mal die Rechnungsnummer, mal die Lieferscheinnummer, mal ihre eigene Bestellnummer aus ihrem System, und in Kliniken oft eine interne Anforderungsnummer, die in Ihrem Haus nirgends existiert. Eine Automatisierung, die stur nach der Auftragsnummer sucht, findet nichts und legt den Fall zur Seite.

Dann gibt es den gleichen Artikel aus mehreren Lieferungen. Die Klinik hat den Handschuh in Größe M im Quartal viermal bestellt, zu drei verschiedenen Preisen, aus zwei verschiedenen Chargen. Zurück kommen achtzig Stück. Welche Lieferung ist das? Ohne Chargennummer auf der Umverpackung ist die Antwort kaufmännisch, nicht technisch. Sie brauchen also eine Regel, die im System steht, und nicht eine Gewohnheit, die im Kopf der Sachbearbeiterin steht.

Nachfolgeartikel kippen den Vorgang an einer anderen Stelle. Der Kunde schickt einen Artikel zurück, den es unter dieser Nummer nicht mehr gibt, weil der Hersteller im Frühjahr umgestellt hat. Ihr Artikelstamm kennt nur den Nachfolger, der Karton trägt den Vorgänger. Wenn die Automatisierung Artikelnummern gegen den aktiven Stamm prüft, kippt der Vorgang genau hier.

Und dann gibt es die Teillieferungen. Eine Bestellung, drei Sendungen, verteilt über zwei Wochen. Zurück kommt eine Position aus der zweiten Sendung, aber der Kunde nennt die Nummer der ersten, weil die auf der Rechnung stand.

Keiner dieser Fälle ist exotisch. Zusammen sind sie in den Projekten, die wir gesehen haben, der Grund für die Mehrzahl aller Klärfälle.

Reklamation, Retoure, Ersatzlieferung: drei Vorgänge, ein Formular

In fast jedem Haus, in dem wir uns diesen Prozess angesehen haben, laufen drei verschiedene Sachverhalte über dasselbe Formular und dieselbe Mailadresse.

Bei der Retoure im engeren Sinn schickt der Kunde Ware zurück und will sein Geld. Bei der Reklamation kommt nichts zurück: Eine Position fehlte in der Lieferung, ein Karton war beschädigt und wurde vor Ort entsorgt, ein Gerät funktioniert nicht. Trotzdem muss etwas passieren. Und beim Austausch geht Ersatz raus, während das alte Teil zurückkommen soll, manchmal in dieser Reihenfolge, manchmal umgekehrt.

Im Posteingang sehen diese Fälle gleich aus, im Ablauf haben sie kaum etwas gemeinsam. Bei der Reklamation ohne Rücksendung gibt es keinen Wareneingang, auf den man eine Buchung hängen könnte. Eine Automatisierung, die auf den Scan im Wareneingang wartet, wartet hier für immer. Beim Austausch entstehen zwei Vorgänge, die aneinander hängen: ein Auftrag, der raus muss, und eine Rücknahme, die vielleicht nie ankommt, weil der Kunde das alte Teil behält.

Daran scheitern Automatisierungen, die den Sachverhalt über ein einziges Formularfeld erkennen wollen. Der Kunde kreuzt "Retoure" an, weil das das einzige Wort ist, das er kennt, und meint eine Nachlieferung.

Auseinanderhalten muss man die drei deshalb am Anfang, mit zwei Fragen im Formular: Kommt Ware zurück, ja oder nein? Wollen Sie Ersatz oder Geld? Das kann jeder Kunde beantworten, und der Rest des Prozesses weiß danach, womit er es zu tun hat.

Bei der Ersatzlieferung braucht die Rücknahme zusätzlich eine Frist mit Konsequenz. Wenn das alte Teil nach vierzehn Tagen nicht da ist, wird berechnet. Ohne diese Regel sammelt sich über Jahre eine Liste offener Austauschvorgänge an, die niemand mehr aufräumt, weil der Aufwand pro Fall größer ist als der Warenwert.

Der Zustand der Ware ist eine Entscheidung, kein Feld

Wenn die Ware da ist und zugeordnet, kommt die Frage, die keine Schnittstelle beantworten kann: Was ist das jetzt noch wert?

In der Praxis gibt es selten mehr als vier Antworten. Wieder verkäuflich, ohne Einschränkung. Wieder verkäuflich nach Nacharbeit, also neu etikettieren, umpacken, reinigen. Nicht mehr verkäuflich, aber verwertbar, etwa als Muster oder Spende. Und Vernichtung.

Diese Entscheidung braucht einen Menschen, der den Karton aufmacht. Das ist keine Schwäche des Prozesses, das ist der Prozess. Problematisch wird es erst dadurch, dass die Entscheidung nirgends landet außer auf einem Zettel, der an der Palette hängt.

Bei bestimmten Warengruppen ist die Antwort ohnehin vorgegeben. Sterile Medizinprodukte, deren Verpackung geöffnet oder beschädigt wurde, sind draußen. Kühlpflichtige Ware, deren Kühlkette nicht lückenlos dokumentiert ist, ist draußen, auch wenn sie aussieht wie neu. Arzneimittel unterliegen eigenen Regeln, und die Frage, ob eine Rücknahme überhaupt zulässig ist, wird nicht im Lager entschieden.

Genau deshalb gehört die Warengruppe in die Retourenlogik. Ein Prozess, der für Schreibwaren und für Reagenzien den gleichen Weg vorsieht, ist für eines von beiden falsch. In den Systemen, die wir bauen, hängt an der Artikelgruppe eine Rücknahmeregel: automatisch möglich, Prüfung erforderlich, Rücknahme ausgeschlossen. Das ist ein Feld im Artikelstamm und spart im Betrieb mehr Zeit als jede Optimierung an der Schnittstelle.

Sperrbestand: der Bestand, der zu früh wieder verkäuflich wird

Die Buchung beim Wareneingang direkt in den verfügbaren Bestand ist der teuerste einzelne Fehler in diesem ganzen Prozess, und er ist in fast jeder selbst gebauten Automatisierung drin.

Der Grund ist verständlich. Das ERP bietet an der Schnittstelle eine Zugangsbuchung an, und die schreibt eben in den Bestand. Ein Sperrlager kennen viele Systeme zwar, aber es ist über die Schnittstelle nicht so bequem erreichbar wie das Hauptlager, und in der Testphase fällt der Unterschied nicht auf, weil im Test niemand die Ware nach zwei Tagen wieder verkauft.

Im Betrieb passiert genau das. Die Ware steht ungeprüft im Regal, das System hält sie für verfügbar, der nächste Auftrag greift zu. Ab diesem Moment haben Sie zwei Probleme statt einem: Sie haben möglicherweise defekte Ware ausgeliefert, und Sie wissen nicht mehr, welche Einheiten aus der Retoure stammen.

Der Sperrbestand ist die einzige saubere Lösung. Retournierte Ware geht in einen eigenen Lagerort, der in der Verfügbarkeitsrechnung nicht mitzählt, und wandert erst nach der Prüfung ins Hauptlager. Wenn Ihr ERP das über die Schnittstelle nicht hergibt, ist ein physisch getrenntes Regal mit einer eigenen Lagerortnummer die pragmatische Variante. Was nicht funktioniert, ist ein Statusfeld, das zwar gesetzt wird, aber in keiner Verfügbarkeitsabfrage vorkommt.

Bei chargenpflichtiger Ware kommt hinzu: Die zurückkommende Charge muss beim Zugang erfasst werden, sonst ist die Rückverfolgbarkeit an dieser Stelle unterbrochen. Ein Rückruf, der auf eine Charge zielt, findet die retournierten und wieder verkauften Einheiten dann nicht.

Die Gutschrift gehört ans Ende

Der Auslöser für die Gutschrift ist die wichtigste Einzelentscheidung im ganzen Prozess. In den meisten selbst gebauten Abläufen hängt sie am Wareneingang, weil das der Moment ist, in dem die Automatisierung ohnehin schon läuft.

Damit zahlen Sie, bevor Sie wissen, wofür. Bei einer Retourenquote von drei Prozent und einem Anteil von zehn Prozent nicht verkäuflicher Rückläufer ist das eine Summe, die niemand als Position sieht, weil sie über hunderte Gutschriften verteilt ist.

Der Gegendruck kommt aus dem Vertrieb, und er ist berechtigt. Kunden mahnen Gutschriften an, und "wir prüfen noch" ist nach drei Wochen keine Antwort mehr. Dagegen hilft eine schnellere Rückmeldung, und die kostet nichts. Eine Eingangsbestätigung mit Vorgangsnummer am Tag des Wareneingangs nimmt fast den ganzen Druck raus, ohne dass ein Cent gebucht wird. Die Nachfragen im Innendienst gehen danach spürbar zurück, weil der Kunde sieht, dass sein Vorgang existiert.

Wenn die Prüfung länger dauert, braucht sie eine Frist und eine Eskalation. Eine Retoure, die nach zehn Tagen keine Entscheidung hat, gehört auf eine Liste, die jemand morgens sieht. Ohne diese Liste bleibt die Ware im Sperrlager stehen, und der Sperrbestand wird zu dem, was er in vielen Häusern ist: ein Regal mit Ware, die niemand mehr zuordnen kann.

Welcher Preis auf der Gutschrift steht

Eine Gutschrift bezieht sich auf eine Rechnung, nicht auf einen Artikel. Der Preis muss also aus dem Ursprungsbeleg kommen, und zwar aus der Position, nicht aus dem Artikelstamm.

Automatisierungen, die den aktuellen Verkaufspreis ziehen, sind häufiger, als man denkt. Im Test fällt es nicht auf, weil dort der Preis von gestern und der von heute derselbe ist. Im Betrieb fällt es auf, wenn ein Rahmenvertrag ausgelaufen ist, eine Preisliste zum Jahreswechsel gewechselt hat oder ein Aktionspreis gegolten hat. Dann erstatten Sie zu viel oder zu wenig, und beides kostet: das eine Geld, das andere eine Reklamation.

Der unangenehmere Fall sind Staffelpreise. Ein Kunde bestellt hundert Einheiten und bekommt den Preis der Hunderterstaffel. Er gibt sechzig zurück. Für die verbleibenden vierzig hätte er nie den Staffelpreis bekommen. Rechnen Sie jetzt nach?

Das ist eine kaufmännische Entscheidung. Sie gehört zwischen Vertrieb und Buchhaltung geklärt, bevor jemand etwas konfiguriert, weil die Automatisierung sonst eine Variante wählt und niemand weiß welche. In der Mehrzahl der Häuser, die wir kennen, wird zugunsten des Kunden nicht nachberechnet, außer bei Rücksendungen über einer bestimmten Größenordnung. Das ist eine legitime Regel. Sie muss nur aufgeschrieben sein.

Dazu kommen die Nebenkosten. Fracht, Mindermengenzuschlag, Verpackungspauschale. Werden die anteilig erstattet, gar nicht, oder nur wenn der Fehler bei Ihnen lag? Auch das ist eine Entscheidung, keine Einstellung.

Teilretouren und die Zahl, die nicht passt

Mengeneinheiten sind bei Retouren gefährlicher als bei Bestellungen, weil auf dem Rückweg niemand die Mengen prüft.

Der Kunde schreibt "3 Kartons". Ihr System rechnet in Stück. Ein Karton ist sechsunddreißig Stück, außer bei diesem Artikel, wo der Hersteller im Sommer auf vierundzwanzig umgestellt hat, und außer bei diesem Kunden, der eine eigene Verpackungseinheit bekommt. Wenn die Automatisierung die Zahl aus dem Formular ungeprüft als Stückzahl bucht, stimmen Bestand und Gutschrift beide nicht.

Dann gibt es Retourenmengen, die über der gelieferten Menge liegen. Das klingt nach einem Fehler und ist manchmal keiner, weil der Kunde aus zwei Lieferungen zusammengepackt hat. Eine Automatisierung sollte das erkennen und nicht einfach buchen. Eine Menge, die die Ursprungsposition übersteigt, ist ein Klärfall, immer.

Sets und Bundles bringen ein eigenes Problem mit. Verkauft wurde ein Set aus fünf Komponenten unter einer Artikelnummer, zurück kommen drei davon. Das System kennt das Set, nicht die Teile. Wer hier keine Regel hat, hat einen Klärfall, der eine halbe Stunde dauert.

Die Uhr, die niemand startet

Retouren haben Fristen, und Fristen brauchen ein Startdatum in einem Feld, nicht auf einem Zettel.

Nach außen: Rücksendefristen aus Ihren Verkaufsbedingungen, Gewährleistungsfristen, bei Verbrauchergeschäften das Widerrufsrecht mit eigenen Regeln. Nach innen: die Frist, in der Sie selbst die Ware beim Lieferanten reklamieren können. Genau diese wird am häufigsten versäumt.

Der Ablauf sieht dann so aus. Ein Kunde reklamiert eine beschädigte Charge, Sie schreiben ihm gut, die Ware steht im Sperrlager. Der Vorgang gegenüber dem Lieferanten braucht eine eigene Retourennummer, ein eigenes Papier und läuft in dessen Frist, oft dreißig Tage ab Rechnungsdatum. Bis Ihre interne Prüfung durch ist, sind zwei Wochen weg, und die restlichen sechzehn Tage verbringt der Vorgang in einem Mailpostfach.

Die Information fehlt dabei selten. Es fehlt der Zeitpunkt, an dem jemand daran erinnert wird. Eine Retoure ohne Fälligkeitsdatum ist eine Aufgabe ohne Termin, und die gewinnt gegen keine andere Aufgabe des Tages.

Wenn die Rechnung schon bezahlt oder gemahnt ist

Die Gutschrift ist der Punkt, an dem der Retourenprozess auf die Buchhaltung trifft, und dort gelten andere Regeln als im Lager.

Solange die Rechnung offen ist, verrechnet sich die Gutschrift mit dem offenen Posten und der Zahlbetrag sinkt. Solange beide Belege im selben System liegen, funktioniert das ohne Zutun.

Ist die Rechnung bereits bezahlt, entsteht ein Guthaben, und jemand muss entscheiden, was damit geschieht. Auszahlung, Verrechnung mit der nächsten Lieferung, oder ein Posten, der stehen bleibt. Kliniken und größere Häuser haben dazu meist eine Vorgabe, und die steht nicht in Ihrem System, sondern in deren Einkaufsbedingungen. Eine Automatisierung, die immer auszahlt, produziert bei diesen Kunden Rückfragen. Eine, die immer verrechnet, produziert bei kleinen Kunden Ärger.

Unangenehm wird es, wenn die Rechnung offen, überfällig und bereits gemahnt ist und der Grund für die Nichtzahlung genau die Position ist, die zurückgeschickt wurde. Wenn Mahnlauf und Retourenprozess nichts voneinander wissen, geht am selben Tag die zweite Mahnung raus, während die Ware bei Ihnen im Sperrlager steht. Dieser Fall kostet Kunden, und er lässt sich mit wenig Aufwand verhindern: Eine offene Retoure setzt die betroffene Rechnung im Mahnwesen aus, bis der Vorgang entschieden ist. Ein Feld, eine Prüfung im Mahnlauf.

Bei Sammelrechnungen kommt eine Anforderung dazu. Wenn eine Rechnung dreißig Lieferungen aus einem Monat bündelt, bezieht sich die Gutschrift auf eine Position darin, und die Zuordnung muss bis auf diese Position gehen. Eine Gutschrift, die nur die Rechnungsnummer kennt, kann die Buchhaltung des Kunden nicht zuordnen, und sie kommt als Rückfrage zurück.

Der Weg zum Lieferanten ist ein zweiter Vorgang

Bei Ware, die Sie selbst nicht verschulden, endet Ihr Prozess nicht mit der Gutschrift an den Kunden. Ein Transportschaden, ein Qualitätsmangel oder eine falsch gelieferte Charge geht weiter an den Hersteller oder Vorlieferanten, und dieser zweite Weg ist in kaum einer Automatisierung abgebildet.

Er hat eigene Regeln. Der Lieferant vergibt eine eigene Rücksendenummer, ohne die er nichts annimmt. Er verlangt oft Fotos innerhalb einer bestimmten Frist, bei Transportschäden manchmal innerhalb von 48 Stunden. Er hat eine eigene Frist für die Reklamation, häufig dreißig Tage ab Rechnungsdatum, und die läuft ab dem Datum seiner Rechnung, nicht ab dem Tag, an dem Ihr Kunde reklamiert.

Die Rechnung dahinter ist einfach. Wenn Sie dem Kunden gutschreiben und die Frist beim Lieferanten verpassen, tragen Sie den Warenwert selbst. Bei einem Haus mit ein paar hundert Lieferantenreklamationen im Jahr summiert sich das auf einen Betrag, der jede Investition in den Prozess bezahlt, und er taucht in keiner Auswertung auf, weil er als normaler Bestandsabgang gebucht wird.

Was der Vorgang braucht, ist wenig: einen Bezug auf die Kundenretoure, die Lieferantennummer, das Datum der Lieferantenrechnung, eine Frist, die daraus berechnet wird, und einen Status. Der Rest ist eine Liste, die morgens jemand ansieht.

Was der Kunde sieht, während nichts passiert

Zwischen Rücksendung und Gutschrift liegen in vielen Häusern drei bis sechs Wochen. In dieser Zeit erfährt der Kunde nichts, außer er ruft an, und dann erfährt er, dass "geprüft wird".

Drei Nachrichten genügen, um den größten Teil dieser Anrufe zu vermeiden. Eine bei der Anmeldung mit der Retourennummer. Eine beim Wareneingang, damit der Kunde weiß, dass die Palette angekommen ist. Eine bei der Entscheidung, mit dem Ergebnis und dem Betrag.

Der Nebeneffekt ist wichtiger als die Kundenzufriedenheit: Sobald diese Nachrichten aus dem System kommen, muss das System die Zustände tatsächlich kennen. Man kann keine Statusmail zum Zustand "geprüft" verschicken, wenn es diesen Zustand nur im Kopf des Lageristen gibt. Die Kommunikation zwingt den Prozess dazu, ehrlich zu sein.

Was wir stattdessen bauen

Der Kern ist ein eigenes Objekt. Die Retoure bekommt eine eigene Nummer, einen Bezug auf Lieferung, Position und, wo vorhanden, Charge, dazu einen Zustand, ein Anlagedatum und ein Fälligkeitsdatum. Sie hat damit eine eigene Lebensdauer, unabhängig davon, was mit dem ursprünglichen Auftrag passiert ist.

Die Zustände sind explizit und wenige: angemeldet, eingetroffen, geprüft, entschieden, abgeschlossen. Jeder Übergang hat einen Auslöser, und die Buchungen hängen an den Übergängen, nicht am Wareneingang. Bestandsbuchung ins Sperrlager beim Eintreffen, Umbuchung ins Hauptlager bei "verkäuflich", Gutschrift bei "entschieden".

Für alles, was nicht eindeutig ist, gibt es eine Warteschlange statt eines Fehlers. Keine Zuordnung gefunden, Menge übersteigt die Lieferung, Artikel nicht im Stamm, Warengruppe mit Rücknahmeausschluss: Diese Fälle gehen in eine Liste mit Kontext, nicht in ein Fehlerprotokoll. Die Automatisierung erledigt danach die siebzig bis achtzig Prozent, die eindeutig sind, und die restlichen Fälle liegen sortiert an einer Stelle, statt verteilt über drei Postfächer.

Der Retourengrund wird erfasst, aus einer kurzen Liste, nicht als Freitext. Fünf bis acht Gründe reichen: falsch bestellt, falsch geliefert, Transportschaden, Qualitätsmangel, zu spät geliefert, Überbestellung, Sonstiges mit Pflichtkommentar. Freitext liest niemand aus, eine Liste kann man auswerten.

Und die Automatisierung schreibt mit. Retourenquote pro Kunde, pro Artikel, pro Grund, dazu die Durchlaufzeit von Wareneingang bis Entscheidung. Diese vier Zahlen hat kaum ein Haus, und sie sind der eigentliche Ertrag des Umbaus.

Retourengründe sind die einzigen Daten hier, die Geld sparen

Der Prozess selbst spart Zeit. Die Gründe sparen Geld, weil sie auf Ursachen zeigen, die außerhalb des Lagers liegen.

Ein Beispiel aus einem Projekt: Vierzig Prozent der Retouren eines bestimmten Artikels liefen unter "falsch bestellt". Beim Nachsehen war klar, warum. Der Artikel wurde im Katalog in Stück angezeigt, geliefert wurde in Zehnerpackungen, und die Kunden bestellten zehnmal zu viel. Der Fehler saß im Katalog, nicht im Lager, und er kostete pro Monat rund zwei Arbeitstage in der Retourenbearbeitung plus Fracht in beide Richtungen.

Ein zweites Muster, das oft auftaucht: Ein einzelner Kunde produziert überproportional viele Retouren mit dem Grund "zu spät geliefert". Dahinter steckt ein Lieferzeitversprechen, das nicht stimmt, und es wird in der Retourenstatistik sichtbar, weil es sonst nirgends sichtbar wird.

Ohne strukturierte Gründe sieht man beides nicht. Man sieht nur eine Quote, die konstant bleibt, und hält sie für normal.

Zwanzig Fälle vor dem Livegang

Bevor so ein Prozess produktiv geht, sollte er mit echten Fällen laufen, nicht mit Testdaten aus dem Musterkunden.

Eine Retoure ohne Ankündigung. Eine mit dem falschen Nummerntyp, also Rechnungsnummer statt Auftragsnummer. Eine mit einer Nummer aus dem System des Kunden, die bei Ihnen nirgends steht. Eine zu einem Artikel, den es unter dieser Nummer nicht mehr gibt. Eine über mehrere Lieferungen. Eine mit einer Menge über der gelieferten. Eine in Kartons statt Stück. Eine zu einem Set, von dem nur ein Teil zurückkommt. Eine mit chargenpflichtiger Ware. Eine mit abgelaufenem Verfallsdatum. Eine mit einer Warengruppe, bei der die Rücknahme ausgeschlossen ist. Eine, bei der die Prüfung "Vernichtung" ergibt. Eine mit Staffelpreis und Teilrückgabe. Eine zu einer Rechnung, die bereits bezahlt ist. Eine zu einer Rechnung, die bereits gemahnt wurde. Eine zu einem Kunden, dessen Preisliste seit der Lieferung gewechselt hat. Eine Reklamation ohne Rücksendung. Eine Ersatzlieferung, bei der das alte Teil nie eintrifft. Eine, die nach der Entscheidung storniert wird, weil der Kunde die Ware doch behält. Und eine, bei der zwei Kunden am selben Tag denselben Artikel aus derselben Charge zurückschicken.

Zwanzig Fälle, ein Nachmittag, und danach wissen Sie, an welchen drei Stellen Ihr Prozess ausfällt. Der Aufwand liegt beim ersten Mal bei einem halben Tag, weil die Testdaten aufgebaut werden müssen. Danach ist die Liste ein Regressionstest, der nach jeder Änderung an der Schnittstelle wieder läuft, und das ist der Punkt, an dem sie sich bezahlt macht. Schnittstellen ändern sich, und die Fälle, die zuerst brechen, sind immer die aus dieser Liste.

Was vorher entschieden sein muss

Eine kurze Liste, die vor der ersten Konfiguration geklärt sein sollte, weil sie hinterher teuer wird.

Wer entscheidet über den Zustand der Ware, und wo wird die Entscheidung erfasst? Wann wird die Gutschrift ausgelöst, beim Eintreffen oder nach der Prüfung? Welcher Preis gilt, und was passiert mit Staffeln und Nebenkosten? Geht retournierte Ware in ein Sperrlager, und kann Ihr ERP das über die Schnittstelle? Welche Warengruppen sind von der automatischen Rücknahme ausgeschlossen? Wie lange darf ein Vorgang offen bleiben, bevor jemand erinnert wird? Und wer bekommt die Fälle, die nicht eindeutig sind?

Sieben Fragen. Sie brauchen eine Stunde, wenn Vertrieb, Buchhaltung und Lager im selben Raum sitzen. Ohne diese Stunde trifft die Automatisierung die Entscheidungen selbst, und zwar zufällig.

Woran Sie es in Ihrem Setup erkennen

Sie brauchen keine Analyse, um zu sehen, wo Sie stehen. Zwei Fragen reichen.

Erstens: Gehen Sie ins Lager und schauen Sie sich den Bereich an, in dem retournierte Ware steht. Nehmen Sie die fünf Paletten, die am längsten dort stehen, und fragen Sie, seit wann. Wenn die Antwort in Monaten kommt, haben Sie keinen Prozess, sondern eine Ablage.

Zweitens: Lassen Sie sich die letzten zwanzig Gutschriften zeigen und prüfen Sie, an welchem Punkt sie erzeugt wurden. Wenn das Datum der Gutschrift mit dem Wareneingangsdatum übereinstimmt, zahlen Sie ungeprüft. Wenn zwischen beiden mehr als drei Wochen liegen, haben Sie ein Kommunikationsproblem mit Ihren Kunden, von dem Sie vermutlich schon wissen.

Und eine dritte, falls Sie es genau wissen wollen: Fragen Sie im Innendienst, wie viele Stunden pro Woche für Retouren draufgehen. Die Antwort steht in keinem Bericht, aber jemand kennt sie auf eine halbe Stunde genau, und sie ist in aller Regel höher als die Zahl, die im Controlling angenommen wird.