Fachbeitrag · Prozessautomation

Warum Fulfillment-Automatisierung an Stammdaten scheitert

Wenn ein Automatisierungsprojekt im Fulfillment schiefgeht, sucht man den Fehler zuerst in der Schnittstelle. Dort liegt er fast nie. Er liegt in dem, was durch sie hindurchfließt.

Die Ausgangslage ist meistens dieselbe. Ein Unternehmen versendet Marketingmaterial an mehrere hundert Standorte, das läuft über Excel-Listen und Zuruf, und irgendwann ist klar: So skaliert das nicht. Also wird ein System angeschafft, eine Schnittstelle gebaut, ein Workflow definiert. Nach drei Monaten läuft die Technik einwandfrei – und die Fehlerquote ist höher als vorher.

Der Grund ist unspektakulär: Ein manueller Prozess verzeiht schlechte Daten, ein automatischer nicht. Solange ein Mensch die Versandliste anfasst, korrigiert er unbewusst hunderte Kleinigkeiten. Er weiß, dass Filiale 0815 seit dem Umbau eine andere Rampe hat. Er sieht, dass zwei Zeilen dieselbe Adresse meinen. Er merkt, dass eine Bestellmenge nicht stimmen kann. Diese Korrekturen tauchen in keinem Prozessdiagramm auf, weil sie niemand aufgeschrieben hat.

Automatisiert man den Prozess, entfällt dieser stille Filter. Was vorher unsichtbar repariert wurde, wird jetzt sichtbar – als Fehllieferung.

Die vier Stellen, an denen es reißt

1. Adressen ohne Zustellwirklichkeit

Adressdatensätze sind fast immer formal korrekt und praktisch unbrauchbar. Sie enthalten die Rechnungsanschrift, nicht die Zustelladresse. Sie kennen keine Anlieferzeiten. Sie wissen nichts über Rampe, Hintereingang oder den Hausmeister, der nur dienstags da ist. Für einen Brief reicht das; für eine Palette nicht.

2. Artikelstammdaten ohne physische Eigenschaften

Im ERP steht Artikelnummer, Bezeichnung, Preis. Für Fulfillment braucht man Maße, Gewicht, Verpackungseinheit, Stapelbarkeit und Gefahrguteinstufung. Fehlt das, kann kein System Versandkosten berechnen oder Kartongrößen wählen – und der Automatismus fällt auf eine Pauschale zurück, die entweder Geld kostet oder Pakete platzen lässt.

3. Dubletten, die keine sind

Zwei Datensätze mit derselben Adresse sind nicht zwingend eine Dublette – es können zwei Abteilungen im selben Gebäude sein, die getrennt beliefert werden wollen. Automatische Dublettenerkennung führt hier zuverlässig zu genau der Sorte Fehler, die beim Empfänger ankommt und nicht im Log.

4. Zustände, die nur im Kopf existieren

„Die Filiale ist im Umbau, die bekommt erst ab Mai wieder etwas.“ Solche Informationen leben in E-Mails und Telefonaten. Ein automatisierter Prozess kennt sie nicht und liefert. Deshalb braucht jeder Empfänger ein Statusfeld – aktiv, pausiert, geschlossen – und jemanden, der es pflegt.

Was vor dem Projektstart zu prüfen ist

Bevor über Systeme gesprochen wird, lohnt eine Stichprobe. Fünfzig zufällige Empfänger aus dem Bestand ziehen und gegen die Realität prüfen:

• Ist die hinterlegte Adresse die, an die tatsächlich geliefert wird?
• Gibt es einen Ansprechpartner mit erreichbarer Telefonnummer?
• Sind Anlieferbeschränkungen dokumentiert – oder weiß sie nur die Spedition?
• Haben alle Artikel Maße und Gewichte, und stimmen sie?
• Wer darf einen Empfänger auf „inaktiv“ setzen, und wie erfährt er davon?

Liegt die Trefferquote unter neunzig Prozent, ist das Automatisierungsprojekt noch kein Automatisierungsprojekt, sondern ein Datenprojekt. Diese Reihenfolge umzudrehen kostet erfahrungsgemäß mehr als die Datenbereinigung selbst.

Die unbequeme Konsequenz

Datenpflege lässt sich nicht auslagern und nicht einmalig erledigen. Sie braucht einen Verantwortlichen, ein Feld für den Zustand und einen Anlass, bei dem sie passiert – idealerweise gekoppelt an einen Vorgang, der ohnehin stattfindet. Wer die Adressprüfung an den Versandprozess hängt, statt sie einmal im Jahr als Projekt zu fahren, hält sie dauerhaft sauber.

Das ist der wenig glamouröse Teil der Automatisierung. Er entscheidet aber darüber, ob am Ende ein System läuft oder nur eine Schnittstelle.

Verwandter Beitrag: E-Rechnungspflicht – das Problem ist der Bestandsprozess. Dieselbe Mechanik, anderes Thema: Was im PDF unsichtbar blieb, fällt auf, sobald eine Maschine mitliest.