EAM#4: Datenschuld - Wenn der Kunde in fünf Systemen existiert

Architektur entscheidet über Komplexität, über Kosten, über Steuerbarkeit. Ich bin David Hohl und heiße dich herzlich willkommen bei Enterprise Architektur wirkt, der Podcast zu EAM. Servus, grüß dich und herzlich willkommen bei einer neuen Folge. Letztens ging es ja um Integration schuld, also um die Situation, in der Daten durch deine Systeme fließen und immer größer werden und niemals kleiner. Und das vor allem durch mehr Schnittstellen, durch mehr Mittelvers und das ganze Getrieben von Transformationen. Bis irgendwann echt niemand mehr genau sagen kann, was eigentlich das Problem war. Oder woran es liegt. Heute schauen wir eine Ebene tiefer. Denn sehr oft liegt das eigentliche Ursache gar nicht in der Integration. Sie liegt im Datenmodell selbst oder genauer gesagt in einer strukturellen Schuld im Datenmodell. Bevor wir anfangen, mal kurz klarstellen, was ich unter Datenmodell verstehe. Wenn ich hier von Datenmodell spreche, meine ich übrigens nicht nur irgendwelche Tabellen oder komischen Datenbanken jeglicher Art. Ich meine die fachliche Struktur eines Geschäftsobjektes. Also die Frage, was ist ein Kunde im Unternehmen eigentlich? Welche Eigenschaften gehören dazu, passen dazu? Welche Beziehungen hat er? Und wie wird er eigentlich wirklich identifiziert? Das Datenmodell beschreibt also nicht die Daten dahinter. Es beschreibt, wie ein Unternehmen, also in deinem Unternehmen, seine Realität strukturiert. Und genau dort entstehen in vielen Organisationen eine strukturelle Schuld. Die gehen mir nebenbei sehr häufig bewusst ein. Besonders deutlich wird es aber bei Kundendaten, finde ich. Und das schauen wir uns heute mal genauer an. Fangen wir mit einer typischen Ausgangssituation an. Viele Unternehmen glauben zunächst, dass sie eigentlich ein relativ klares Bild ihrer Kunden haben. Was ja auch verständlich ist. Ich weiß mein Vornamen, ich weiß mein Nachnamen, ich weiß ca. wo die Dinge liegen. Es gibt aber dazu ein CM, das sind Kundendaten, es gibt ein ERP und vielleicht gibt es auch noch ein Commerce-System. Nebenbei habe ich natürlich auch Tickets, also brauche ich ein Customer Support System oder an der Stelle ein Service Management Desk. Und auch natürlich wichtig ist, gerade wenn ich ein Commerce System habe, brauche ich ein Loyalty System oder ein Bonusprogramm, damit alle recht glücklich sind. Alle arbeiten am Schluss, also auf diesen Systemen, mit Kunddaten, unabhängig von der Spezifikation. Und auf den ersten Blick scheint das auch logisch. Klar, das System hat sich jetzt aufgelöst, aber wahrscheinlich sind es oft halt, wie sehe ich, auch mehr davon. Jede System hat schließlich eine Aufgabe. Das ist auch okay. Das CM verwaltet Kontakte und Betriebsthemen, das ERP, Geschäftspartner und so weiter. Die Onlineshop, die klassischen Kunddaten und so. Muss ich jetzt glaube ich nicht genau näher erklären. Doch architektonisch bedeutet das oft etwas komplett anderes. Denn wenn mehrere Systeme Kundendaten nicht nur nutzen, sondern selbst speichern und verändern, also Storage und Modification, entsteht eine dezentrale Kundendatenbasis. Was eigentlich jetzt nicht unbedingt gleich schlecht ist. Dennoch, der Kunde existiert dann nicht einmal im Unternehmen, er existiert mehrfach. Und in unterschiedlichen Strukturen, mit unterschiedlichen Identifikationen und oft auch verschiedenen, natürlich die IDs, es gibt dann auch unterschiedliche Kundennummern, vielleicht sogar auch noch, und oft in unterschiedlicher fachlicher Bedeutung. Und hier ist der große Hund begraben. Und den wollen wir heute heben. In vielen Organisationen gibt es deshalb nicht nur ein Kundenmodell, sondern mehrere. Und jetzt wird es lustig. Gerade im CM reden wir von Kontakten, im ERP von Geschäftspartnern, in Commerce von Shop-Kunden oder ein bisschen klassischer, der normale Ende-zu-Ende-Kunde. Im diversen Ticket-System ist das Service-Kontakt und bei den Loyalty-Systemen von Teilnehmern. Und alle beziehen sich von den bescheidenen Systemen auf den selben Menschen oder dasselbe Unternehmen. Aber sie sind strukturell unterschiedlich modelliert. Da ist nämlich genau der Punkt. Sie haben unterschiedliche Attribute, unterschiedliche Identifikationen und vor allem, das ist ganz, ganz wichtig, unterschiedliche Lebenszyklen und oft auch unterschiedliche Bedeutungen dahinter. Und das ist halt etwas, wo man dann relativ schnell in Verwirrung kommt. Gerade wenn man Gespräche führt über Systemarchitekturen, wo halt genau diese Systeme auf einmal miteinander kommunizieren müssen. Da redet der eine vom Kunde, der andere vom Kunde und alle reden vom Gleichen, aber die Inhalte dahinter sind anders oder beziehungsweise anders aufbereitet und stehen auch komplett anders in der Beziehung. Und plötzlich merkt man, das Unternehmen spricht ständig über den Kunden, aber eigentlich meint jeder nur das Anderes. So, wie entsteht so eine strukturelle Schuld? Diese Situation entsteht selten bewusst nebenbei. Sie entsteht genauso wie bei Integrationsschulden über die Zeit. Und was auch sehr häufig ist, nicht nur über Zeit, sondern über Entscheidungen hinweg, weil die Bereiche natürlich nicht darüber sprechen können. Dafür braucht es halt die Enterprise-Architektur oder halt eine Domain-Architektur, die sich halt da wirklich sehr stark damit auch auseinandersetzt. Ein System wird halt eingeführt und dann ein zweites und ein drittes und ja, wie soll ich sagen, jeder System bringt halt sein eigenes Datenmodell mit. Und jedes Projekt löst seine Probleme lokal. Und dann sind wir halt wieder bei unserem eigentlichen Punkt, die Silos. Und wenn man jetzt diese einzelnen Systeme verändert, dann funktionieren sie natürlich, weil sie isoliert sind. Und das ist okay. Auf der einen Seite. Doch irgendwann müssen die natürlich zusammenarbeiten. Und dann beginnen halt genau diese Integrationen, von denen ich vorher gesprochen habe. Und diese Integrationsschulden von der letzten Folge, die kommen hier danach eigentlich zur Geltung. Weil diese Unterstichmodelle, die müssen jetzt miteinander verbunden werden. Und das ist recht spaßig für jeden Integrationsarchitekten. Die Rolle der Integration. An dieser Stelle entstehen nämlich oft die Missverständnisse. Wenn Daten nicht zusammenpassen, denkt man zuerst, die Integration ist das Problem, die Schnittstelle funktioniert nicht oder die Transformation als solches wurde einfach falsch geplant oder durchgeführt. Und dann das nächste natürlich, der Datenfluss als solches, ist halt zu langsam. Doch sehr oft ist die Integration nur der Ort, also die Location, an der das Ganze stattfindet, an der er sichtbar wird. Das, was im Datenmodell vielleicht bereits schon hin ist oder nicht funktioniert. Die Integration versucht dann etwas zu tun. Wenn ich von Integration, dann würde ich das Team und das alles rum, was eigentlich architektonisch vorher hätte entschieden werden müssen. Die versucht, unterschiedliche Definitionen des Kunden miteinander zu verbinden. Das ist nämlich ganz wichtig. Unterschiedliche Definitionen des Kunden miteinander verbinden. Und das ist eine Aufgabe, die Integration eigentlich gar nicht lösen sollte, machen sollte. Das ist nämlich genau das, wo die Schuld entsteht. Genau der Punkt. Wenn danach die Technik entscheidet oder bzw. das Integrationsteam entscheidet, wie diese Dinge zusammengeführt werden müssen. Der wirtschaftliche Effekt dahinter. Warum ist das überhaupt ein Problem? Frag dich das einmal selbst. Warum ist das ein Problem? Weil diese strukturelle Datenschuld kosten verursacht und zwar an sehr sehr vielen Stellen. Das ist aber nicht sichtbar. Das kommt wirklich über die Zeit und das ist so ein Ballast, den man einfach mit sich schleppt und der wird immer größer. Zum Beispiel in Projekten. Also jedes neue Projekt muss sich zuerst verstehen, was im Unternehmen überhaupt ein Kunde ist. Also das Projekt muss es verstehen. Nicht ich, aber ich auch wahrscheinlich. Welche Systeme ihn verwalten, welche Daten sind da wirklich relevant und vor allem, welche Identifikatoren gehören da wirklich zusammen. Allein diese Analyse kann echt Wochen oder Monate dauern. Und speziell, und das sieht man auch sehr häufig, es gibt oft kein wirkliches Datenmodell über Systeme hinweg. Also auf ein System ja, gute Architekten machen das. Ich habe das in der Vergangenheit gerade im Salesforce-Umfeld sehr häufig gesehen, dass man sich zuerst über das Datenmodell Gedanken macht und dann über die Funktionität. Das hilft gerade bei Transformationen. Wie auch immer, wenn man das nicht macht, dann entstehen Kosten in der Integration selbst. Also Transformationen werden notwendig, klarerweise, und dann fängt man an, irgendwelche komischen Mapping-Tabellen zu finden. Das eine Feld ist das andere und so weiter. Und dann braucht man einen Identifikator bei beiden, um das Ganze dann irgendwie zusammenzumappen. Und von Tubletten mag ich jetzt gar nicht reden. Und jeder einzelne oder jeder zusätzliche Schritt dahinter erhöht, eine andere gewisse Schuld, die vielleicht noch kommen wird, ist halt die Komplexität. Und natürlich beim Reporting entstehen diverseste Probleme, was das Thema angeht. Wenn unterschiedliche Systeme unterschiedliche Kundendefinitionen verwenden, dann entstehen natürlich automatisch unterschiedliche Zahlen. Und gerade der Vertrieb berichtet vielleicht eine andere Zahl als das Finance-System. Marketing zählt Kontakte und Commerce zählt halt Accounts oder halt diese Kunden dahinter. Und wie auch immer, plötzlich entstehen halt einfach Kennzahlen, die einfach nicht zusammenpassen. Lassen Sie uns mal über den Schaden reden, der daraus entsteht. Der eigentliche Schaden entsteht oft im Betrieb selbst. Denn wenn Datenmodelle nicht sauber strukturiert sind, entstehen Fehler. Kunden werden doppelt oder mehrfach einfach angelegt. Die Adressen sind unterschiedlich. Accounts können nicht eindeutig zugeordnet werden. Das sehe ich leider auch sehr häufig. Gerade wenn es um Adressdaten geht. Die sind dann in so vielen verschiedenen Systemen verteilt und das aktuell zu halten, ist dann auch ein Horror. Dann beginnt die manuelle Arbeit. Kennst du wahrscheinlich auch, dann zuckt man das Excel, importiert alles da rein und probiert das bei Störungen, Replays zu ersetzen oder zusammenzuführen. Dann werden die Daten korrigiert, Datensätze zusammengeführt und dann die weiteren Fehler gesucht. Und diese Arbeit taucht selten in Architekturdiagrammen auf. Also in keinem Assets findest du das. Aber der Student wird sich freuen, weil er einen Job hat. Oder heutzutage die EID, was vielleicht das eine oder andere hier natürlich übernehmen kann. Aber es hilft halt keinen. Und weil sie kostet eigentlich jeden Tag Zeit und Geld. Egal, ob das jetzt maschinell durchgeführt wird oder manuell. Nebenbei, Anekdote, er hat einmal einen Job oder ein Projekt halt laufend, da sagt ein technischer Architekt, beziehungsweise das Vorhaben, wie man das jetzt umsetzt, sagt er, das macht er nachher, der Mr. Manuel. Und ich habe mir gedacht, das ist in Spanier in dem Moment und habe das einfach so hingenommen und dann habe ich noch gefragt, wer macht das jetzt nochmal? Ja, Mr. Manuel. Aha, wer ist das? Naja, wir machen es manuell. Die eigentliche architektonische Frage, die wir uns eigentlich nicht stellen sollen, ist, wie integrieren wir unsere Kundendaten? Macht überhaupt keinen Sinn, die sind ja schon da und die sind so verstreut, dass sie im Endeffekt schwer dann auffindbar sind. Aber es gibt einige Fragen, die du dir stellen kannst oder beziehungsweise auch dem Team stellen könntest, die dir wahrscheinlich sehr gut helfen werden, hier besser voranzukommen. Erste ist, wie ist der Kunde bei dem Unternehmen eigentlich definiert? Typische Definitionen könnten zum Beispiel sein, aus der Betriebssicht, sind Kunden, Organisationen oder Personen, die Produkte kaufen. Aus der Marketingperspektive, Kunden sind identifizierbare Personen mit Interaktion oder Kampagnenkontakt. und so weiter. Vielleicht noch letztes Beispiel, was mir jetzt gerade noch einfällt. In Commerce Perspektive ein Kunde ist ein registrierter Nutzer im Shop mit Account. Hier entsteht genau häufig dann das Problem, alle reden über den Kunden, meinen aber unterschiedliche Dinge. Deswegen sind diese Perspektiven sehr wichtig und du musst die halt auch eingehen. Und da hilft dir vielleicht auch eine Persona Perspektive. Eine weitere Frage ist, welche Entität beschreibt den Kunden? Im Datenmodell wird der Kunde als Entität modelliert. Typische Varianten sind genau diese Daten, Entities, Customer Account, Business Partner und so weiter oder Kontakt oder aus der EAP-Sicht der Debitor. Und in einem Unternehmen kann es natürlich mehrere Entitäten geben, aber da ist genau Ein Account ist immer ein Unternehmen zum Beispiel oder ein Kontakt ist immer Person im Unternehmen. Customer sind Endkunden, Partner sind Händler und so weiter. Das ist halt einmalig festzulegen und danach über die Systeme durchzusetzen. Gerade wenn man das danach verbinden möchte mit den technischen Applikationen, hilft das sehr gut und man weiß halt danach, wo welche Datenentitäten gespeichert sind und verarbeitet werden. Da komme ich wieder auf mein Beispiel vom letzten Mal zurück. Diese DFDs, die helfen dir hier. Dann, welche Attribute gehören dazu? Da sollte man nicht so tief runtergehen. Also mit Attributen sind natürlich danach die Felder gemeint. Man sollte halt einmal nur grob einmal definieren und danach auch klarzusetzen, wer ist wo oder wo. Und natürlich muss klargesetzt sein, welches System ist verantwortlich für diese Daten. Also wer ist System of Record, wer verarbeitet sie nur oder wer speichert sie oder macht eine Zwischenspeicherung. Und danach halt genau diese Zuordnung dieser Datenentitäten, also diese Haupttöpfe und danach diese Nebentöpfe, wo ich dann nachher immer von verschiedenen Levels spreche. Level 1, 2, 3. Wobei die Levels dann nachher diese Hierarchie dann aufzeigen. Zum Beispiel ein Beispiel für klare Verantwortungsstrukturen könnte es sein, Datenbereich ist jetzt zum Beispiel Kundendaten, System of Record sind die Ansprechpartner im CM. Oder Login und Account habe ich im Commerce. Oder Bonuspunkte sind halt im Loyalty-System. Das typische Problem, was wirklich sehr häufig auftretet, ist genau das, wenn diese Verantwortung nicht definiert ist, dann ist zum Beispiel die Adresse, wird im CM verändert, im ERP bleibt sie die alte und im Commerce-System existiert noch eine dritte Version. Na, Mahlzeit. Dann existieren plötzlich drei Wahrheiten über den selben Kunden. Und ja, es ist kein Spaß. Und dann reden wir genau von dem. Wir reden von einer strukturellen Datenschuld. Und die ist extrem hoch und ich hoffe, dir ist es auch bewusst geworden, wie wichtig die ist. Wie beim letzten Mal, habe ich mir vier solche Diagnosefragen mal aufgeschrieben. Die kannst du dir gerne mitnehmen, ich schreibe sie auch in die Show Notes rein. Gibt es eine klare Definition, was ein Kunde im Unternehmen ist? Gibt es ein gemeinsames Datenmodell oder zumindest eine gemeinsame Struktur für Kundendaten? Und drittens, welches System besitzt die Verantwortung für diese Daten? Und vielleicht noch viertens, wie viele Systeme dürfen die Kundendaten wirklich verändern? Wenn diese Fragen schwer zu beantworten sind, das ist es wahrscheinlich, dann ist meist ein klares Zeichen für eine strukturelle Schuld im Datenmodell. Und nebenbei, das haben sehr, sehr viele Unternehmen. Ich würde sagen, jedes Unternehmen. Es geht einfach nur darum, wie du damit umgehst und ob du diese auch bewusst eingegangen bist. Faszit Strukturelle Schuld im Datenbund entsteht selten bewusst. Sie entsteht genauso wie die Integration sehr leise und still. Und über Jahre hinweg. Und umso mehr Silos du im Unternehmen hast, umso schneller geht das leider. Und oft werden sie erst sichtbar, wenn ein größeres Projekt gestartet wird. Oder wenn Systeme miteinander arbeiten müssen. Doch genau hier zeigt sich, wie wichtig die Architektur ist. Denn Architektur entscheidet nicht über Technologien. Sie entscheidet darüber, wie ein Unternehmen seine Realität modelliert. In der nächsten Folge schauen wir uns eine weitere technische Schuld an. Eine Schuld, die in vielen Unternehmen entsteht, wenn Standardsoftware immer weiter angepasst wird. Und also die Frage, was passiert, wenn Systeme eigentlich Standard sein sollten, aber über die Jahre zu einer Einzelanfertigung werden. Servus und Baba und bis auf bald.