Zugestellt an der Pforte, gebraucht auf Station 4: Adressdaten in Automatisierungen

Zugestellt um 7:40 Uhr, angekommen ist es nie

Ein Sanitätshaus beliefert vierzehn Kliniken und rund achtzig Pflegeeinrichtungen. Die Bestellungen kommen per Mail, über ein Kundenportal und bei den drei größten Häusern direkt aus deren Warenwirtschaft über eine Schnittstelle. Dazwischen läuft seit zwei Jahren eine Automatisierung: Sie liest die Bestellung, legt den Auftrag im ERP an, erzeugt den Lieferschein und meldet die Sendung beim Paketdienstleister an.

Im Februar häuften sich die Nachfragen. Stationen meldeten fehlende Lieferungen, die Sendungsverfolgung zeigte "zugestellt", mit Uhrzeit und Empfängername. Die Pakete waren im Haus. Sie lagen im zentralen Wareneingang, einige seit elf Tagen, weil niemand wusste, wohin damit.

Der Grund stand in der ursprünglichen Bestellung. Dort hieß der Empfänger "Klinikum Nord, Station 4B, Frau Dr. Weiler, Haus C, Anlieferung Rampe 2". Im Auftrag stand nur noch "Klinikum Nord, Ostring 12, 44807 Bochum". Alles, was zwischen Firmenname und Straße stand, hatte den Weg durch die Automatisierung nicht überlebt. Das ERP hat ein Feld für einen Adresszusatz, vierzig Zeichen lang. Es war nie befüllt worden, weil die Quelle den Empfänger als einen einzigen Textblock lieferte und das Mapping sich die erste Zeile als Firma und die letzte als Ort gegriffen hatte. Der Rest fiel raus.

Fünfzig bis siebzig Sendungen pro Woche gingen so raus. Kein Lauf war rot, keine Fehlermeldung, kein Alarm. Der Paketdienstleister hatte auch nichts zu beanstanden, denn die Adresse war formal korrekt und zustellbar. Sie war nur nicht vollständig genug, um im Haus anzukommen.

Adressen sind aus unserer Erfahrung die Datenklasse, bei der der Abstand zwischen "technisch fehlerfrei" und "praktisch brauchbar" am größten ist. Bei Beträgen fällt ein Fehler beim Abschluss auf, bei Terminen spätestens beim Kunden. Bei Adressen fällt er auf, wenn jemand in der Logistik anfängt, Ausnahmen von Hand zu klären, und diese Handarbeit taucht in keiner Statistik auf. Sie wächst einfach mit.

Eine Adresse ist kein Textfeld

Der Ursprung fast aller Adressprobleme in Automatisierungen ist eine Entscheidung, die niemand bewusst getroffen hat: Die Adresse wandert als Fließtext durch die Kette.

Das passiert schneller, als man denkt. Ein Kontaktformular hat ein Textfeld "Anschrift" mit drei Zeilen. Ein Portal liefert `shipping_address` als String mit Zeilenumbrüchen. Eine PDF-Bestellung wird ausgelesen, und der Extraktor gibt einen Block Text zurück. In allen drei Fällen liegt am Anfang der Kette eine Adresse vor, die ein Mensch sofort versteht und eine Automatisierung nur raten kann.

Solange dieser Text nur weitergereicht und irgendwann von einem Menschen gelesen wird, geht das gut. Der Ärger beginnt an der ersten Stelle, an der ein System strukturierte Felder verlangt. Und dieses System kommt immer. Der Paketdienstleister will Straße und Hausnummer getrennt. Das ERP hat Feldlängen. Die Tourenplanung will Koordinaten und braucht dafür eine Adresse, die sich geokodieren lässt. Die Buchhaltung braucht ein Länderkennzeichen für die Umsatzsteuer.

An diesem Punkt baut jemand einen Parser. Meistens ist es ein Regex in einem Make-Modul oder eine Function Node in n8n, geschrieben an einem Nachmittag, getestet mit sechs Beispielen aus der eigenen Kundenliste. Er funktioniert, und deshalb bleibt er.

Der Parser, der Straße und Hausnummer trennt, rät

Die Aufgabe klingt harmlos: Nimm "Ostring 12" und mach daraus `street = "Ostring"` und `houseNumber = "12"`. Der naive Ansatz nimmt das letzte Wort als Hausnummer. Er scheitert an dieser Liste, und jeder Eintrag darin ist eine echte deutsche Adresse:

Hauptstraße 12a. Am Hasenberg 4-6. Berliner Allee 3 / 5. Zum Alten Sportplatz 17, 2. OG. Industriestraße 44b, Tor 3. Bahnhofsplatz 1. In der Rehwiese 9 1/2. Kirchweg 12, Hinterhaus. Auf der Höhe 3, Halle B. Postfach 12 04 60. Große Straße 4, c/o Meier. Sehr beliebt auch: Straße 17 (das gibt es in Wolfsburg wirklich, und die Hausnummer fehlt dort im Quelltext regelmäßig).

Jeder dieser Fälle bricht mindestens eine der üblichen Regeln. "12a" geht noch, "4-6" wird zu einer Hausnummer, die manche Zielsysteme nicht annehmen, "3 / 5" wird zu "5" und das Paket landet im falschen Haus. "2. OG" wird als Hausnummer interpretiert, weil es die letzte Zahl ist. Bei "Straße 17" verschwindet der Straßenname, weil der Parser das erste Wort als Straße und den Rest als Nummer nimmt und dann feststellt, dass gar nichts übrig bleibt.

Abfangen kann man diese Fälle alle, das ist nicht die Schwierigkeit. Die Schwierigkeit ist, dass ein Regex, der sie alle abfängt, nach zwei Wochen von niemandem mehr verstanden wird und trotzdem an dem Fall scheitert, den nächste Woche ein Kunde aus Belgien schickt.

Wir haben in einem Projekt gemessen, wie oft ein solcher Parser danebenliegt: bei rund 14.000 Bestandsadressen eines Großhändlers waren es 3,1 Prozent, also gut 430 Adressen. Davon waren etwa 120 kaputt genug, um eine Zustellung zu gefährden. Der Rest war schief, aber zustellbar, meistens weil der Paketdienstleister im Hintergrund korrigiert hat. Wer 3 Prozent Fehlerquote hört, denkt an eine Randnotiz. Bei zweihundert Sendungen am Tag sind das sechs Pakete, die jemand anfassen muss.

Die bessere Antwort ist fast immer, gar nicht zu parsen. Wenn die Quelle strukturierte Felder liefern kann, fordern Sie sie an. Ein Portalformular mit getrennten Feldern für Straße, Hausnummer, Zusatz, PLZ, Ort und Land kostet einen halben Tag Arbeit und erspart den Parser für immer. Bei einer fremden API, die nur einen String liefert, lohnt sich die Frage an den Anbieter, ob es strukturierte Felder gibt. Erstaunlich oft gibt es sie, sie sind nur nicht dokumentiert oder liegen in einem anderen Endpunkt.

Wenn es keinen Weg an einer Zerlegung vorbei gibt, dann verwenden Sie einen echten Adressdienst statt eigener Regeln, und speichern Sie beides: die zerlegten Felder und den Originaltext. Der Originaltext ist Ihre Versicherung. Wenn drei Monate später eine Reklamation kommt, wollen Sie wissen, was der Kunde tatsächlich geschrieben hat, nicht, was Ihr Parser daraus gemacht hat.

Die Zeile, die im Zielsystem nicht vorgesehen ist

Der zweite große Fehler betrifft nicht die Zerlegung, sondern die Kapazität. Die Quelle liefert mehr Adressbestandteile, als das Ziel aufnehmen kann, und die Automatisierung entscheidet still, was wegfällt.

Praktisch jedes deutsche ERP kennt eine Empfängeranschrift mit Name 1, Name 2, manchmal Name 3, dazu Straße, PLZ, Ort, Land und ein Feld für einen Zusatz. Paketdienstleister kennen ähnliche Strukturen, aber mit anderen Grenzen. Die Kundendaten aus einem Krankenhausportal enthalten dagegen gern fünf oder sechs Bestandteile: Träger, Klinik, Fachabteilung, Station, Ansprechpartner, Anlieferhinweis. Sechs Angaben, drei Felder. Irgendwer muss entscheiden, was zusammengefasst und was gestrichen wird.

Wenn diese Entscheidung nicht bewusst getroffen wird, trifft sie das Mapping, und zwar meist so: Feld 1 auf Name 1, Feld 2 auf Name 2, Rest ignoriert. Genau das war beim Sanitätshaus passiert.

Bewusst getroffen sieht die Entscheidung anders aus. Man legt fest, welche Bestandteile zustellrelevant sind, und die kommen nach oben. Für eine Klinik ist das die Station, nicht die Fachabteilung, und der Anlieferhinweis gehört in das dafür vorgesehene Feld des Versanddienstleisters, nicht in die Namenszeile. Für einen Handwerksbetrieb, der auf Baustellen liefern lässt, ist es die Bauvorhabenbezeichnung. Für einen Filialisten die Filialnummer, und zwar in der Form, die im Wareneingang tatsächlich an der Wand hängt.

Diese Zuordnung ist keine technische Frage. Sie gehört in ein Gespräch mit der Logistik und im Zweifel mit dem Kunden. Wir machen das inzwischen standardmäßig vor dem Bauen, weil das Nachrüsten teurer ist als die Stunde, die es kostet.

Und wenn doch etwas nicht passt, dann soll die Automatisierung das melden statt schweigen. Ein Datensatz, bei dem drei Adressbestandteile auf zwei Felder abgebildet werden müssen, kann in eine Prüfliste laufen. Das sind selten mehr als ein paar Fälle pro Woche, und sie sind in zwei Minuten geklärt. Was nicht funktioniert, ist die Variante, in der die Automatisierung die dritte Zeile lautlos verwirft und alle Beteiligten glauben, es liefe.

Rechnungsadresse, Lieferadresse, Anlieferstelle

Jeder weiß, dass Rechnungs- und Lieferadresse verschieden sein können. Trotzdem sehen wir regelmäßig Workflows, die genau ein Adressobjekt kennen, weil beim Bau alle Testkunden identische Adressen hatten.

Der Schaden ist beidseitig und unangenehm. Wird die Lieferadresse auf die Rechnung gedruckt, geht die Rechnung an eine Filiale oder eine Baustelle statt in die Buchhaltung, und die Zahlung verzögert sich um Wochen, weil das Dokument erst intern wandern muss. Wird umgekehrt die Rechnungsadresse zum Versand genommen, steht das Paket vor der Zentrale, während die Ware in der Filiale gebraucht wird.

Bei größeren Kunden reicht die Zweiteilung nicht. Ein Klinikverbund hat einen Rechnungsempfänger (die Trägergesellschaft, oft mit eigener Debitorennummer und abweichender Umsatzsteuer-Identifikationsnummer), ein lieferndes Haus, und innerhalb des Hauses eine Anlieferstelle, die je nach Warenart unterschiedlich sein kann. Kühlware geht an eine andere Rampe als Verbandsmaterial. Wenn Ihre Automatisierung nur "der Kunde hat eine Adresse" kennt, bilden Sie diesen Kunden nicht ab, und Sie merken es erst, wenn er groß genug ist, dass es weh tut.

Der Modellierungsfehler dahinter ist verbreitet: Adressen werden als Eigenschaft des Kunden gespeichert, nicht als eigene Objekte mit einem Typ. Die tragfähige Variante ist ein Satz von Adressen pro Kunde, jede mit einer Rolle (Rechnung, Lieferung, abweichende Anlieferstelle), einer Gültigkeit und einer Kennzeichnung, welche die Vorgabe ist. Der Auftrag verweist dann auf eine konkrete Adresse und nicht auf den Kunden.

Die Adresse ändert sich, der Beleg darf es nicht

Ein Kunde zieht um. Jemand pflegt die neue Anschrift im CRM. Was passiert mit den Aufträgen aus dem letzten Jahr?

Wenn Ihre Belege die Adresse per Verweis auf den Kundendatensatz ziehen, ändern sich rückwirkend alle. Die Rechnung vom März zeigt jetzt eine Anschrift, unter der der Kunde im März nicht erreichbar war. Solange niemand hinschaut, ist das egal. Bei einer Betriebsprüfung oder einer Reklamation ist es das nicht, und im Streitfall über eine nicht angekommene Sendung ist es das schon gar nicht, weil sich nicht mehr rekonstruieren lässt, wohin Sie eigentlich geliefert haben.

Die Regel dagegen ist die gleiche wie bei Preisen und Wechselkursen: Ein Beleg friert die Werte ein, die zum Zeitpunkt der Erstellung gültig waren. Die Lieferadresse gehört zum Lieferschein, die Rechnungsadresse zur Rechnung, jeweils als Kopie, nicht als Verweis. Das kostet ein paar Felder und ist die einzige Variante, die nach zwei Jahren noch eine Antwort liefert.

Interessant wird der umgekehrte Fall. Eine Automatisierung legt bei jeder Bestellung eine neue Adresse an, weil der Kunde im Portal die Anschrift leicht anders geschrieben hat. Nach achtzehn Monaten hat ein mittelgroßer Kunde vierzig Adressen im System, von denen sechs aktuell sind und vierunddreißig Tippvarianten. Wenn dann jemand im Vertrieb die Lieferadresse auswählt, greift er in eine Liste, in der die richtige Adresse nicht mehr auffindbar ist. Wir haben das Muster in fast jedem gewachsenen CRM gefunden, das wir uns angesehen haben.

Der Ausweg ist eine Normalisierung vor dem Vergleich: Kleinschreibung, Umlaute vereinheitlichen, "Str.", "Straße" und "Strasse" auf eine Form bringen, Leerzeichen und Satzzeichen entfernen, dann vergleichen. Wenn die normalisierte Form schon existiert, wird die vorhandene Adresse verwendet statt einer neuen. Das ist keine perfekte Duplikaterkennung, aber es fängt den Großteil ab.

Sobald das erste Paket über die Grenze geht

Die deutschen Annahmen halten genau bis zur ersten Auslandslieferung.

Die Postleitzahl ist das offensichtlichste Beispiel. In Deutschland fünf Ziffern, in Österreich und der Schweiz vier, in den Niederlanden vier Ziffern plus zwei Buchstaben, in Großbritannien eine alphanumerische Zeichenkette mit Leerzeichen, in Irland gab es lange gar keine, und der Eircode ist bis heute nicht überall gebräuchlich. Ein Pflichtfeld mit Validierung auf fünf Ziffern blockiert damit einen Teil Ihrer Kunden, und ein Feld ohne jede Validierung lässt jeden Tippfehler durch.

Die Reihenfolge im Adressblock unterscheidet sich ebenfalls. In den USA steht die Hausnummer vor dem Straßennamen, der Bundesstaat gehört als eigenes Feld dazu, und ohne ihn ist die Adresse nicht eindeutig. In Frankreich ist "cedex" hinter dem Ort kein Tippfehler, sondern ein Zustellhinweis, den man nicht wegkürzen darf.

Das Land selbst ist der Fall, den wir am häufigsten reparieren. In gewachsenen Datenbeständen steht dort alles Mögliche: "Deutschland", "deutschland", "DE", "GER", "D", "BRD", leer (weil Inland als Standard gilt), und bei Kunden, die einmal über ein englisches Portal angelegt wurden, "Germany". Sechs Schreibweisen für dasselbe Land bedeuten, dass jede Auswertung nach Land falsch ist, jede Zollentscheidung auf Zeichenketten-Vergleichen basiert und jede Versandkostenregel Ausnahmen braucht.

Dagegen hilft eine Festlegung, die jeder sofort einsieht und die trotzdem selten umgesetzt wird: Das Land ist ein ISO-Code mit zwei Buchstaben, in jedem System, ohne Ausnahme. Die Anzeige in der Oberfläche darf gern "Deutschland" heißen, gespeichert und übertragen wird `DE`. Wenn Sie in Ihrem Bestand aufräumen wollen, ist das der erste Schritt, weil er billig ist und sofort wirkt.

Bei Lieferungen in die Schweiz oder nach Norwegen kommt die Zollseite dazu, und dort schlägt eine unvollständige Adresse anders zu: Die Sendung wird nicht falsch zugestellt, sie bleibt liegen. Wer schon einmal eine Woche mit einem Verzollungsproblem verbracht hat, weil in der Empfängeradresse eine Telefonnummer fehlte, plant dieses Feld beim nächsten Mal ein.

Wenn die Automatisierung stillschweigend korrigiert

Adressvalidierung ist eine gute Idee mit einer gefährlichen Standardeinstellung.

Die meisten Dienste, ob vom Paketdienstleister oder von einem Anbieter für Adressprüfung, können nicht nur prüfen, sondern auch korrigieren. Aus "Bahnhofstr 12, 50126 Bergheim" wird "Bahnhofstraße 12, 50126 Bergheim". Das ist hilfreich. Aus "Ostring 12" in einem Ort, in dem es keinen Ostring gibt, wird aber unter Umständen "Ostring 12" in einem Nachbarort, weil der Dienst den nächstähnlichen Treffer nimmt. Und aus einer Hausnummer 112, die es nicht gibt, wird 12, weil das die plausibelste existierende Nummer ist.

Wenn diese Korrektur ohne Kennzeichnung in Ihren Datenbestand zurückgeschrieben wird, haben Sie ein Problem, das schlimmer ist als die ursprüngliche Falscheingabe: Die Adresse sieht jetzt sauber aus, ist validiert, und niemand hat einen Anlass, sie zu hinterfragen. Der Kunde, der tatsächlich in der 112 sitzt, bekommt seine Sendungen nie.

Wir arbeiten deshalb mit einer Trennung, die sich in mehreren Projekten bewährt hat. Der Dienst darf normalisieren, also Schreibweisen vereinheitlichen, Abkürzungen ausschreiben und Groß- und Kleinschreibung korrigieren. Er darf nicht raten. Sobald die Prüfung keinen exakten Treffer liefert, sondern einen Vorschlag mit einem Ähnlichkeitswert, geht der Datensatz in eine Prüfliste, und ein Mensch entscheidet. Bei den Beständen, mit denen wir gearbeitet haben, betrifft das zwischen einem und drei Prozent der Adressen. Das ist eine Aufgabe von zwanzig Minuten am Tag, und sie ersetzt eine Fehlerklasse, die sonst monatelang unbemerkt bleibt.

Dazu gehört, dass jede automatische Änderung protokolliert wird: welcher Wert vorher da war, welcher Dienst geändert hat, wann. Ohne dieses Protokoll lässt sich später nicht mehr feststellen, ob eine kaputte Adresse vom Kunden kam oder von Ihrer eigenen Automatisierung.

Was auf ein Versandlabel passt

Die härteste Grenze in der ganzen Kette steht am Ende, und sie ist selten dokumentiert, wo die Leute sie lesen.

Versandschnittstellen arbeiten mit festen Feldlängen. Je nach Dienstleister und Produkt sind das für Name und Zusatz Größenordnungen von dreißig bis fünfzig Zeichen pro Zeile, bei zwei oder drei verfügbaren Zeilen. "Klinikum Nord Gemeinnützige Krankenhausbetriebsgesellschaft mbH" hat 62 Zeichen. Was passiert, entscheidet die Schnittstelle: Manche lehnen den Aufruf mit einem Fehler ab, was das freundlichere Verhalten ist, weil es auffällt. Andere schneiden ab. Dann steht auf dem Label "Klinikum Nord Gemeinnützige Krankenhausbetriebsg", und alles, was in der nächsten Zeile hätte stehen sollen, ist weg.

Wenn Sie einen Zusteller mit Sonderzeichenbeschränkungen bedienen, kommt eine zweite Ebene dazu. Manche Systeme akzeptieren nur einen eingeschränkten Zeichensatz. Umlaute werden dann ersetzt oder, im schlechteren Fall, als Fragezeichen dargestellt. "Müller" wird zu "M?ller", und weil das Label trotzdem gedruckt wird, merkt es niemand in Ihrem Haus.

Die Konsequenz für den Bau ist einfach: Prüfen Sie Längen und Zeichensatz, bevor Sie den Versandauftrag absetzen, nicht danach. Eine Automatisierung, die feststellt, dass der Empfängername 62 Zeichen hat und das Ziel 40 erlaubt, kann eine sinnvolle Kürzung vorschlagen (zum Beispiel die Rechtsform weglassen, nicht die letzten 22 Zeichen abschneiden) und den Fall zur Bestätigung vorlegen. Was sie nicht tun sollte, ist blind abschneiden und hoffen.

Wenn die Tourenplanung die Adresse anders liest

Wer mit eigenem Fuhrpark ausliefert, hat eine weitere Station in der Kette, und die stellt eigene Ansprüche. Tourenplanung arbeitet mit Koordinaten, nicht mit Text. Irgendwo zwischen Auftrag und Ladeliste wird die Adresse deshalb geokodiert, meistens über einen Kartendienst.

Dieser Schritt scheitert leiser als alle anderen. Ein Geokodierer liefert praktisch immer ein Ergebnis, auch wenn er die Adresse nicht gefunden hat. Er nimmt dann den Ortsmittelpunkt, und der liegt in einer mittelgroßen Stadt schnell vier Kilometer vom Ziel entfernt. Die Tour sieht plausibel aus, die Reihenfolge ist optimiert, und der Fahrer steht vormittags an einem Kreisverkehr und ruft in der Disposition an.

Jedes brauchbare Geokodierungsergebnis kommt mit einer Angabe zur Genauigkeit: Hausnummer, Straße, Ort, Region. Diese Angabe wird in No-Code-Workflows fast nie ausgewertet, weil sie im Ergebnisobjekt weiter unten steht und man sie beim Bauen nicht sieht. Wir prüfen sie inzwischen immer und lassen alles, was schlechter als Straßengenauigkeit ist, in eine Prüfliste laufen statt in die Tour.

Der zweite Punkt betrifft Betriebsgelände. Bei einer Klinik, einem Logistikzentrum oder einem Werk ist die postalische Adresse nicht die Stelle, an der man abladen kann. Der Kartendienst zeigt die Hauptzufahrt, die Rampe liegt auf der anderen Seite, und zwischen beiden liegen zwei Kilometer Umweg und eine Schranke. Solche Anfahrtspunkte gehören als eigene Koordinate an die Adresse, einmal von jemandem gesetzt, der dort war. Ein Feld, das viele Systeme sogar mitbringen und das in kaum einem gepflegt ist.

Dazu kommt der Kostenaspekt, den man am Anfang unterschätzt. Geokodierung wird pro Aufruf abgerechnet. Eine Automatisierung, die bei jedem Statuswechsel eines Auftrags neu geokodiert, macht aus 200 Lieferungen am Tag schnell 1.200 Aufrufe. Die Koordinate gehört an die Adresse gespeichert und wird nur neu berechnet, wenn sich ein Adressfeld tatsächlich geändert hat.

Die Adresse als Schlüssel: das nächste Duplikat

In vielen Automatisierungen ist die Adresse nicht nur Nutzdatum, sondern Teil der Erkennungslogik. "Existiert dieser Kunde schon?" wird beantwortet über Name plus PLZ, manchmal plus Straße. Das ist verständlich, weil es oft keine bessere Kennung gibt, und es ist unzuverlässig aus allen Gründen, die weiter oben stehen.

Zwei Datensätze mit "Musterhandel GmbH, Bahnhofstr. 12" und "Musterhandel G.m.b.H., Bahnhofstraße 12" sind derselbe Kunde. Zwei Datensätze mit "Praxis Dr. Weber, Hauptstraße 4" in derselben PLZ können zwei verschiedene Praxen in einem Ärztehaus sein. Ein Vergleich auf Zeichenketten liefert im ersten Fall zwei Kunden und im zweiten Fall einen, also genau falsch herum.

Wenn Sie eine stabile Kennung haben, nehmen Sie sie: Kundennummer aus dem ERP, Debitorennummer, im B2B-Umfeld notfalls die Umsatzsteuer-Identifikationsnummer. Wenn Sie keine haben, ist die Adresse ein Hinweis für einen Abgleichvorschlag und keine Entscheidungsgrundlage für ein automatisches Zusammenführen. Zusammenführen ist eine Operation, die man nicht rückgängig macht.

Wie wir Adressfelder modellieren

Die Struktur, mit der wir in Projekten arbeiten, ist nicht originell, aber sie hält. Eine Adresse besteht aus:

Empfängername in bis zu drei Bestandteilen, getrennt gespeichert und nicht in einen String geworfen. Straße und Hausnummer als zwei Felder, wobei die Hausnummer ein Textfeld ist und keine Zahl, weil "4a" und "4-6" existieren. Ein Feld für den Adresszusatz mit klarer Definition, was hineingehört. PLZ als Text (führende Nullen gehen sonst verloren, und in einigen Ländern stehen Buchstaben darin). Ort. Region oder Bundesstaat, optional, aber vorhanden, weil man es sonst für die USA nachrüsten muss. Land als ISO-Code mit zwei Buchstaben. Dazu eine Rolle, ein Gültigkeitszeitraum und der Originaltext, so wie er hereinkam.

Der Originaltext ist der Teil, den die meisten weglassen und den wir für den wichtigsten halten. Er kostet ein Textfeld und beantwortet später jede Frage nach dem "Woher kam das?".

Dazu gehört die Festlegung, welches System die Adresse führt. In der Regel ist das genau eines, meistens das ERP oder das CRM, und alle anderen bekommen Kopien. Wenn zwei Systeme beide schreiben dürfen, brauchen Sie eine Regel für den Konfliktfall, und die haben Sie nicht, wenn Sie nicht bewusst eine gebaut haben.

Der Import, mit dem alles anfängt

Fast jeder kaputte Adressbestand, den wir gesehen haben, geht auf einen Import zurück. Meistens eine Excel-Datei aus einem Altsystem, einmalig übernommen, nie überprüft.

Die typischen Muster: Spalten sind verschoben, weil ein Datensatz ein Semikolon im Firmennamen hatte. Die PLZ ist eine Zahl geworden und hat ihre führende Null verloren, also steht in Dresden 1067 statt 01067. Umlaute sind zerschossen, weil die Datei als Windows-1252 gespeichert und als UTF-8 gelesen wurde. Leere Zellen sind zu dem Text "NULL" geworden, und dieser Text steht seitdem als Adresszusatz auf Lieferscheinen.

Der unangenehmste Fall ist der Import, der nicht einmalig läuft, sondern jede Nacht. Dann korrigiert der Innendienst tagsüber eine Adresse, und der nächtliche Lauf schreibt den alten Wert aus der Quelle zurück. Wir haben das bei einem Kunden erlebt, bei dem dieselbe Anschrift über vier Monate hinweg elf Mal von Hand korrigiert und elf Mal überschrieben wurde. Niemand hat den Zusammenhang gesehen, weil beide Vorgänge in verschiedenen Systemen protokolliert waren. Wenn ein Import bestehende Datensätze aktualisiert, muss geklärt sein, welche Felder er überhaupt anfassen darf.

Diese Fehler sind einzeln banal und in Summe teuer, weil sie sich über Jahre in jeden nachgelagerten Prozess kopieren. Ein Import ohne Stichprobe ist eine Wette. Wir nehmen bei jeder Übernahme dreißig zufällige Datensätze und vergleichen sie von Hand mit der Quelle, dazu gezielt die Extremfälle: der längste Firmenname, die Adresse mit den meisten Zeilen, die ausländischen Kunden, die Datensätze mit Sonderzeichen. Das dauert eine Stunde und findet in etwa der Hälfte der Fälle mindestens ein Problem.

Symptome, an denen Sie es früh erkennen

Adressprobleme melden sich nicht als Fehler, sondern als Alltagsreibung. Diese Anzeichen sehen wir immer wieder, und sie stehen fast nie im Ticketsystem:

Jemand in der Logistik hat eine eigene Liste, in der steht, wohin bestimmte Kunden wirklich beliefert werden. Der Innendienst korrigiert Adressen nach dem Import routinemäßig von Hand. Es gibt einen Ordner mit Sendungen, die zurückgekommen sind, und niemand hat den Prozess dahinter je gemessen. Kunden schreiben in das Bemerkungsfeld der Bestellung, wohin die Lieferung soll, weil das Adressfeld ihre Angaben nicht aufnimmt. Und der klassische Fall: Ein Mitarbeiter sagt, man müsse bei diesem Kunden "immer aufpassen".

Jeder dieser Sätze beschreibt eine Lücke im Datenmodell, die ein Mensch mit Erfahrung ausgleicht. Solange dieser Mensch da ist, funktioniert es. Er ist der Grund, warum das Problem nie eskaliert und deshalb auch nie behoben wird.

Die Testfälle, die wir jedem Adress-Workflow mitgeben

Bevor eine Automatisierung mit Adressen live geht, läuft sie bei uns gegen einen festen Satz von Fällen. Der ist über die Jahre gewachsen, und jeder Eintrag darin stammt aus einem echten Vorfall:

Ein Firmenname mit 70 Zeichen. Ein Empfänger mit Station und Ansprechpartner, also drei Namensbestandteilen. Die Hausnummer 4a, die Hausnummer 4-6 und die Adresse ohne Hausnummer. Ein Postfach. Eine c/o-Adresse. Eine Adresse in Österreich mit vierstelliger PLZ, eine in den Niederlanden mit "1012 AB", eine in den USA mit Bundesstaat. Eine PLZ mit führender Null. Ein Name mit Umlaut und einer mit französischem Akzent. Eine abweichende Lieferadresse bei identischem Rechnungsempfänger. Ein Kunde, der zwischen Auftrag und Rechnung umgezogen ist. Und eine Adresse, die absichtlich nicht existiert, um zu sehen, was die Validierung damit macht.

Zwanzig Fälle, einmal aufgesetzt, in jedem weiteren Projekt wiederverwendbar. Der Durchlauf dauert eine halbe Stunde und ersetzt die drei Monate, in denen man die gleichen Fälle sonst einzeln in der Produktion entdeckt.

Was vor dem Bauen entschieden sein muss

Es gibt eine kurze Liste von Fragen, die geklärt sein sollten, bevor jemand das erste Modul konfiguriert. Nicht weil sie schwierig wären, sondern weil sie hinterher teuer sind.

Welches System führt die Adresse, und wer darf schreiben? Welche Bestandteile sind zustellrelevant, und in welcher Reihenfolge landen sie in den verfügbaren Feldern? Was passiert, wenn die Quelle mehr Bestandteile liefert, als das Ziel aufnimmt? Wird validiert, und wenn ja: darf der Dienst korrigieren oder nur vorschlagen? Wie werden Adressen auf Belegen behandelt, als Kopie oder als Verweis? Und wie erkennt die Automatisierung, ob eine Adresse schon existiert?

Sechs Fragen. In einem Gespräch von einer Stunde zu klären, wenn die richtigen Leute im Raum sind, und das sind nicht nur die aus der IT. Die Logistik weiß Dinge über Ihre Adressen, die in keinem System stehen.

Ein Nachmittag, der sich lohnt

Wenn Sie wissen wollen, wie es bei Ihnen aussieht, brauchen Sie keine Analyse und kein Werkzeug. Nehmen Sie zehn Bestellungen aus der letzten Woche, am besten von Ihren größten Kunden, und verfolgen Sie die Empfängeradresse durch jede Station: wie sie hereinkam, was im ERP steht, was auf dem Lieferschein gedruckt wurde, was an den Versanddienstleister übergeben wurde, was auf dem Label steht.

Wenn an einer dieser Stationen etwas fehlt, das an der vorherigen noch da war, haben Sie die Stelle gefunden. Meistens ist es eine einzige, und meistens ist es ein Mapping, das jemand vor zwei Jahren an einem Freitagnachmittag gebaut hat.

Danach lohnt sich eine zweite Frage: Wie viele Sendungen pro Monat werden in Ihrem Haus von Hand korrigiert, bevor sie rausgehen? Fragen Sie in der Logistik, nicht im Controlling. Die Antwort steht in keinem Bericht, aber jemand kennt sie auf zehn Sendungen genau.