Postalische Validierung im CRM

Dies ist ein Best Practice Ansatz zur Realisierung einer postalischen Validierung im CRM auf Basis Omikron Data Quality Server

Ablauf einer Postalischen Prüfung

Nach der Eingabe der Adresse wird die Adresse einer postalischen Validierung unterzogen. Die Adresse wird dabei an einen Workflow auf dem DQ-Server per Webservice Call übertragen (Webservice-Funktion „DoWorkflowExtended“).

Dieser Workflow kapselt den kompletten postalischen Validierungsprozess von technischer Seite. Der Workflow liefert entweder einen Datensatz (Original oder korrigierte Variante zusammen mit einem Statusfeld, das weitere Informationen zu der Validierung enthält sowie einen Status zur Steuerung der folgenden Darstellung der Ergebnisse enthält) oder mehrere Vorschläge zur Korrektur.

Rückgaben der postalischen Korrektur

a) Der Datensatz ist OK und benötigt keine Änderungen oder er wurde nur schwach geändert

In diesem Fall wird der Datensatz ohne Rückfrage übernommen und im Bestellprozess fortgefahren.

Die schwache Änderung (Definition: an der Adresse wurden nur optische und keine inhaltlichen Änderungen vorgenommen – Ergänzen / Entfernen von Trennzeichen, Leerzeichen oder Änderung der Groß-Kleinschreibweise) wird ebenfalls übernommen.

Das Kennzeichen „schwache Änderung“ ist zum aktuellen Stand nur über die Omikron-eigene Technologie zur postalischen Validierung Deutschland verfügbar.

b) Der Datensatz wurde korrigiert

Hier existiert genau ein Korrekturvorschlag. Es sollte in eine Rückmeldoberfläche verzweigt werden, die die ursprüngliche Eingabe der Korrektur gegenüberstellt und dem Beatbeiter die Möglichkeit gibt, auch „seine“ Eingabe weiter zu verwenden.

Beispiel:

c) Es gibt mehrere Vorschläge für die Korrektur

Es sollte in eine Rückmeldoberfläche verzweigt werden, die die ursprüngliche Eingabe der Liste den möglichen Korrekturen gegenüberstellt und dem Bearbeiter die Möglichkeit gibt, auch „seine“ Eingabe weiter zu verwenden.

Beispiel:

Auch hier muss die Möglichkeit gegeben sein, die ursprüngliche Eingabe weiter zu verwenden.

d) Es gibt keinen validen Vorschlag

In diesem Fall kann ein kurzer Hinweis gegeben werden und der Nutzer noch einmal in die Adresseigabe zurückfallen mit dem Hinweis:

„Die Eingabe konnte nicht verifiziert werden, bitte prüfen Sie noch einmal die Angabe in den Adressfeldern“.

Nach der Änderung der Adresse muss diese automatisch übernommen werden, der Eingabeprozess darf hier nicht unterbrochen werden oder der Bearbeiter gezwungen werden, eine korrekte Adresse einzugeben.

Der Bearbeiter sollte dabei maximal ein mal durch die postalischen Prüfroutinen aufgehalten werden, Dialogschleifen müssen vermieden werden.

Folgende Gründe sprechen für diese Vorgehensweise:

• Postalische Referenz-Datenbanken benötigen einige Monate, um neue Adressen in Neubaugebieten oder neuen Industriegebieten aufzunehmen. Diese sollen in keinem Fall von der Bestellung abgehalten werden, nur weil die Referenzdatenbank die Adresse noch nicht enthält.
• Im Falle von Prüfungen im internationalen Umfeld wird o.g. Aspekt noch einmal wichtiger, da die Abdeckung der Datenbanken für andere Länder stark differerent ausfallen kann und bestimmte ländliche Gebiete eine schlechte Abdeckung haben können.
• Ziel ist es stets, den Kunden nicht von einer Bestellung abzuhalten. Unter Umständen möchte der Kunde seine Adresse exakt wie von ihm geschrieben übermitteln. Ist dies nicht möglich oder sehr umständlich wird er unter Umständen den Bestellvorgang abbrechen.

Die Postalische Prüfung des Data Quality Servers

Das postalische Korrekturmodul des DQ Servers prüft eine übergebene Adresse auf postalische Korrektheit.

Die einzelnen Elemente einer Adresse werden wie folgt behandelt:

Der Workflow liefert stets einen korrigierten / geprüften Datensatz oder den Originaldatensatz mit aus, in Abhängigkeit von Prüfstatus des Datensatzes.

Länderweiche

DQ-Server enthält als spezielles Korrekturmodul der postalischen Prüfung eine Länderweiche. Diese wird über die einheitliche Schnittstelle der postalischen Bereinigung aufgerufen und bestimmt, welche Länderkonfiguration für welche Länderangabe verwendet wird.

Der Workflow zur postalischen Korrektur spricht diese Weiche an, es sind keine zusätzlichen Konfigurationen im Workflow mehr nötig.

Online vs. Offline Datenbeständen

Unser Datenlieferant Adress Doctor bietet postalische Referenzdaten für nahezu alle Länder als Online- oder Offlinedatenbank an. Die Onlinedatenbank wird über eine Webservice Schnittstelle auf dem Server des Anbieters angesprochen. Der Omikron Data Quality Server kann diese Schnittstelle ansprechen.  Für Länder, für die viele Korrekturen anfallen kann der Kauf einer Offline Datenbank sinnvoll sein. Diese wird dann direkt auf dem DQ Server gehalten, es ist kein Online Zugriff via Webservice mehr nötig.

Über die Konfiguration der integrierten Weiche wird entschieden welche Adresse in welches Korrekturmodul (Online, Offline) fließt.

Wird zu einem späteren Zeitpunkt festgestellt, dass eine Offline-Verarbeitung weiterer Länder wirtschaftlich ist, die aktuell per Online-Anfrage bearbeitet werden, kann diese Einstellung zu jeder Zeit durch eine Oberfläche innerhalb des Data Quality Server Management Studios konfiguriert werden. Es ist keine Anpassung in den implementierenden Programmteilen notwendig.

Vorverarbeitung

Für die Verarbeitung der Daten wird ein Vorverarbeitungsschritt eingesetzt. Dieser kümmert sich um generelle strukturelle Anpassungen vor der postalischen Prüfung, um den Erfolg eines automatischen Korrekturvorschlages zu erhöhen. Dieser kann z.B. folgende Szenarien umfassen:

• Bereinigung des Länderkennzeichens, setzen eines Defaults wenn z.B. Leer = DE
• Extraktion von Hausnummern aus dem Straßennamen, wenn diese in einem gemeinsamen Feld gepflegt werden

Hier ist auch ein länderindividueller Vorverarbeitungsschritt möglich, so dass systematische Fehleingaben oder ungültige Formate vor der eigentlichen postalischen Prüfung behoben werden können.

Technische Implementierung

Die Prüfung wird über die Webservice-Schnittstelle des DQ-Servers abgewickelt. Dieser wird vom Application Server des CRMs angesprochen.

Wir empfehlen die Integration auf Basis eines Workflows, der bereits die gängigen Vor- und Nachbereitungsschritte für die Adressaufbereitung abdeckt und so die Integration sehr einfach macht.

Der Workflow wird über die Funktion „DoWorkflowExtended“ aufgerufen und liefert je nach Korrekturergebnis einen oder mehrere Adressen an den Aufrufer zurück.

Beim Aufruf der Webservice-Funktion empfehlen wir, diesen mit einem Timeout von ca. 5 Sekunden zu versehen, und bei Ablauf dieser Zeit den Vorgang ohne eine Adresskorrektur oder auf Basis bestehender anderer Mechanismen fortzusetzen.

Dies stellt sicher, dass der Eingabeprozess auch bei unterbrochener Netzwerk-Verbindung zum Dienst nicht abgebrochen wird. Er wird lediglich langsamer.

Wenn möglich und bereits im CRM vorhanden implementieren Sie an dieser Stelle eine kleine Animation, die ein Wartesymbol anzeigt.