Kunden- und Lieferantendaten abgleichen, ohne zu raten, welche Datensätze passen

Jeder andere Use Case dieser Familie beginnt mit einem Beleg. Dieser beginnt mit einer Identitätsfrage, und sie ist der Grund, warum der Kontaktabgleich meist die erste Anbindung ist, die ein Team baut, und die, zu der es am längsten zurückkehrt. Eine Rechnung verweist auf einen Kunden. Eine Ausgabe verweist auf einen Lieferanten. Sind sich die beiden Seiten uneinig, welche Firma das ist, ist alles Nachgelagerte falsch, und zwar auf leise statt auf laute Weise.

Der dokumentierte Ablauf nennt drei Felder zum Abgleich, und sie sind nicht gleichwertig. Eine Umsatzsteuer-Identifikationsnummer ist registriert, zwei Firmen können sich also keine teilen, und ein Abgleich darauf ist ein Nachschlagen. Eine E-Mail-Adresse ist oft ein gemeinsames Postfach, und eine Firma kann mehrere haben. Ein Firmenname ist eine Zeichenfolge, die jemand getippt hat, und eine ausgeschriebene Rechtsform und dieselbe abgekürzt sind für einen Menschen dieselbe Firma und für einen Vergleich zwei verschiedene Werte. Die Identifikationsnummer wäre die, die es entscheidet, und sie steht in der dokumentierten Feldliste kaum eines angebundenen Systems.

Auf fast jedem System ist das deshalb ein Abgleichproblem mit einer Toleranz und kein Nachschlagen über einen Schlüssel, und die Toleranz ist eine Produktentscheidung. Gleicht man zu locker ab, verschmelzen zwei Kunden zu einem. Gleicht man zu streng ab, bekommen Ihre Nutzer eine zweite Kopie einer Firma, die sie schon haben, in einem System, in dem die nächste Rechnung dann auf die falsche verweist. Keiner der beiden Fehler meldet sich.

HubSpot ist dieser Use Case in der Größenordnung, in der die Frage der Zuordnung aufhört, theoretisch zu sein: Kundendaten, Rechnungen und Zahlungserinnerungen, die zwischen einem CRM und den Buchhaltungssystemen hin- und herlaufen, die ihre DACH-Kunden tatsächlich fahren, für Hunderte dieser Kunden. Die Systeme, die ihre Case Study nennt, sind sevdesk, Lexware Office und DATEV, und sie sind sich über fast alles uneinig, außer darüber, dass ein Kundendatensatz einen Namen und eine Anschrift hat. Diese Uneinigkeit nimmt ein gemeinsames Modell auf, und deshalb bleibt die interessante Arbeit bei den Regeln und nicht bei der Infrastruktur.

Alles links ist die Anbindung: zwei dokumentierte Wege in eine Kontaktliste, dieselbe Satzform, auf welchem System der Kunde auch läuft, Schreibvorgänge und Korrekturen in die Gegenrichtung, soweit dieses System es zulässt, und ein günstiger Weg, nach dem Geänderten zu fragen. Das ist der Teil, der sonst eine Anbindung je Buchhaltungsplattform wäre, jede mit einer eigenen Vorstellung davon, was ein Kunde ist.

Alles rechts ist Ihr Produkt, und in diesem Use Case ist es die Substanz und nicht die Verzierung. Ob zwei Datensätze eine Firma sind, wie nah eine Übereinstimmung sein muss, bevor Sie darauf handeln, welche Seite gewinnt, wenn sich beide geändert haben, und wie oft das alles läuft, sind Entscheidungen, die von Ihren Daten und den Erwartungen Ihrer Nutzer abhängen. Die Dokumentation nennt das Auflösen widersprüchlicher Informationen und lässt es bei Ihnen, und dort gehört es hin.

Eines gehört hierher, weil die Seite, die diese ersetzt, es in eine Überschrift gestellt hat. Maesn sagt nicht zu, dass ein Datensatz nie zweimal geschrieben werden kann. Was ein Duplikat verhindert, ist der Abgleichsschritt, den Ihr Produkt vor dem Schreiben leistet, und der lastModified-Filter hält die Kopie, gegen die Sie abgleichen, aktuell genug, damit diese Entscheidung eine gute ist.

Eine Gegenpartei vor dem Schreiben zuzuordnen ist Infrastrukturarbeit, und zwar die Art, die Produkt- und Entwicklungsteams gehört und nicht dem Buchhaltungssystem an einem der beiden Enden.