Integration ist keine Verbindung, sondern der Verkehrsplan der Stadt

Als Kind waren meine liebsten Spiele fast immer Aufbau- und Simulationsspiele. In SimCity baute ich Städte, führte sie als Bürgermeister und versuchte, die Menschen darin so zufrieden wie möglich zu halten. SimCity dürfte das Spiel sein, mit dem ich in meiner Kindheit die meiste Zeit verbracht habe. Wahrscheinlich fesseln mich deshalb in letzter Zeit Mini Motorways und Mini Metro von Dinosaur Polo Club so sehr. Nur ist mir aufgefallen, dass ich diese beiden Spiele heute mit ganz anderen Augen spiele. Ich sage es immer wieder: Wer einmal mit CRM zu tun hatte — wer in diesem Feld Software entwickelt oder Unternehmen Lösungen geliefert hat —, sieht die Welt anders. Von der Planung des eigenen Arbeitstags bis zum Ordnen eines Schranks zu Hause beginnt man überall Prozesse, Beziehungen, Lücken und Verbesserungsmöglichkeiten zu erkennen. Als ich 2001 auf Siebel Systems traf und mein erstes Projekt umsetzte und als 2003 Microsoft CRM 1.0 — heute bekannt als Microsoft Dynamics 365 — in mein Leben kam, verstand ich deutlich besser, was es heißt, für ein Unternehmen eine ganzheitliche Lösung zu bauen. Ich sah, dass auch eine Unternehmensstruktur wie eine Stadt aus verschiedenen Vierteln, Prozessen, Menschen und den Wegen besteht, die diese Teile miteinander verbinden. Wenn ich heute Städtebau- und Verwaltungsspiele spiele, sehe ich noch etwas klarer: In diesen Spielen machen genau die Entscheidungen, die die Stadt wachsen lassen, sie zugleich immer komplexer. Jede neue Straße, Verbindung oder Lösung, die zunächst praktisch wirkt, kann später zum größten Engpass des Systems werden, wenn sie ohne Rücksicht auf Wachstum umgesetzt wurde. Dasselbe passiert in Unternehmensprojekten, die mit derselben Haltung angegangen werden. Deshalb wollte ich die Ähnlichkeit zwischen den Städten, die wir in Spielen bauen, und den Datenarchitekturen und Integrationen beschreiben, die wir in Unternehmensprojekten schaffen. Denn ob wir eine Stadt oder ein CDP- und CRM-Ökosystem aufbauen: Jeder Schritt von heute bestimmt unmittelbar den Verkehr, das Wachstum und die Steuerungsfähigkeit von morgen.

Wie baut man in CDP- und CRM-Projekten eine Architektur, die die Anforderungen von heute erfüllt und zugleich den Datenverkehr von morgen bewältigt?

Solange die Bevölkerung einer Stadt klein ist, macht es Spaß und fällt leicht, Straßen nach Gutdünken zu ziehen. Bei ein paar Vierteln, wenigen Fahrzeugen und geringem Verkehr funktioniert fast jede Straße. Brauchen zwei Bezirke eine Verbindung, wird eine neue eröffnet; wächst ein dritter Bezirk, bekommt auch er seine eigene Straße. Kurzfristig scheint das Problem gelöst. Sobald die Stadt zu wachsen beginnt, ändert sich das Bild. Neue Wohngebiete entstehen, die Bevölkerung nimmt zu, Geschäftszentren vermehren sich und die Bewegungsgewohnheiten der Menschen verändern sich. Straßen, die eben noch ausreichten, werden zu Engpässen. Eine Baustelle in einem Bezirk beeinflusst den Verkehr der ganzen Stadt. Fehlende Alternativrouten, falsch geplante zentrale Kreuzungen und Ampeln sowie ein zu spät erstellter Nahverkehrsplan machen Wachstum teuer und schmerzhaft. In Integrationsprojekten geschieht etwas sehr Ähnliches. Den Datenfluss zwischen ERP und CRM aufzubauen, Formulare von der Website zum Vertriebsteam zu bringen oder Callcenter-Aufzeichnungen mit dem Kundenprofil zu verknüpfen, mag anfangs wie eine Handvoll technischer Verbindungen aussehen. Doch je größer das Unternehmen wird, desto mehr werden diese Verbindungen zum Datenverkehrssystem des Unternehmens. Integration ist deshalb nicht bloß die Aufgabe, „zwei Anwendungen miteinander sprechen zu lassen“. Eine Integrationsarchitektur ist ein langfristiger Stadtplan: Sie legt fest, aus welchem System Daten kommen, welche Wege sie nehmen, wo sie angereichert werden, wer sie nutzt und wie sie in einer wachsenden Organisation gesteuert werden. Gerade in CDP- und CRM-Projekten ist es entscheidend, diesen Plan zu Projektbeginn zu erstellen.

Jeder Bezirk auf der Karte ist ein System, jede Straße ein Datenfluss

Betrachten wir die Karte, wie sie sich in Mini Motorways zeigt, nicht nur als Stadtplan, sondern als Abbild eines Technologie-Ökosystems im Unternehmen. Die verschiedenen Bezirke können für Anwendungen wie CRM, ERP, E-Commerce, die mobile App, das Callcenter, das Treuesystem, Marketing-Automation, Servicemanagement und das Data Warehouse stehen. Die kleinen Symbole sind Kunden, Transaktionen oder Kontaktpunkte; die Straßen sind die Datenflüsse zwischen diesen Systemen. Die rosafarbenen Hauptachsen sollen für Integrationen mit hohem Volumen und hoher Kritikalität stehen, die Nebenstraßen für operative Verbindungen geringerer Dichte. Brücken und Kreuzungen sind die zentralen Architekturbausteine: API-Management, Integrationsplattform, Event-Streaming-Infrastruktur oder gemeinsames Datenmodell. Dieser Vergleich zeigt eine wichtige Wahrheit: Dass eine Straße funktioniert, heißt nicht, dass das Verkehrssystem richtig geplant wurde. Ebenso wenig beweist die Tatsache, dass eine Integration heute Daten transportiert, dass die Architektur zukunftsfähig ist. Die eigentliche Frage lautet: Bleibt diese Struktur beherrschbar, wenn die Zahl der Anwendungen von fünf auf fünfundzwanzig steigt, die Zahl der Kunden von hunderttausend auf zehn Millionen und die Zahl der Nutzer von fünfzig auf zweitausend? Die Integrationsarchitektur muss diese Frage beantworten, bevor das Projekt beginnt.

Der häufigste Fehler: für jeden neuen Bedarf eine neue Straße bauen

In den meisten Unternehmen entstehen Integrationen genau dann, wenn ein Bedarf auftaucht. Die Website wird an CRM angebunden. Danach werden Kundendaten aus dem ERP ins CRM übertragen. Später beginnt die mobile App, Daten aus dem CRM zu beziehen. Kommt eine Marketingplattform hinzu, entstehen zwei weitere Verbindungen zwischen ihr und dem CRM. Nach einer Weile schließen sich auch Data Warehouse, Callcenter und Kundenservice-Anwendungen diesem Netz an. In einer kleinen Struktur mit zwei oder drei Anwendungen kann dieses Modell schnell Ergebnisse bringen. Steigt jedoch die Zahl der Anwendungen, wächst die Zahl der Verbindungen exponentiell. Wo zehn Systeme in verschiedene Richtungen Daten austauschen, werden nicht nur die Anwendungen voneinander abhängig, sondern auch Datenformate, Identitätszuordnungen, Fehlerbehandlung, Sicherheitsregeln und Geschäftsprozesse. Am Ende steht vor dem Unternehmen ein verworrenes Straßennetz auf der Karte: - Derselbe Kunde wird in verschiedenen Systemen unter verschiedenen Identitäten geführt. - Wird ein Feld geändert, sind mehrere Integrationen betroffen. - Es wird unklar, aus welchem System eine Information stammt. - Es wird schwerer herauszufinden, wo fehlerhafte Datensätze entstehen. - Fällt eines der Systeme vorübergehend aus, entstehen Kettenreaktionen. - Die Inbetriebnahme einer neuen Anwendung kann Monate dauern. - Das Wissen über die Integrationen bleibt an einzelne Personen oder Dienstleister gebunden.

In diesem Stadium ist nicht die Qualität der einzelnen Straßen das Problem. Das Problem ist, dass die Straßen ohne eine gemeinsame Verkehrspolitik gebaut wurden — also ohne an die Zukunft zu denken. Diese Zukunft beginnt damit, Wachstum vorherzusehen und abzuschätzen, wie stark die Zahl der Fahrzeuge auf einer Straße zunehmen kann. Wie wichtig die Berater sind, mit denen Sie arbeiten — die Stadtplaner in diesem Bild —, muss ich wohl kaum betonen. Mit erfahrenen und kreativen Beratern zu arbeiten führt Sie zu einer Struktur, die langfristig trägt.

CRM und CDP übernehmen in derselben Stadt unterschiedliche Aufgaben

Um die richtige Architektur zu bauen, muss man die Aufgaben von CRM und CDP voneinander trennen. Das CRM ist das operative Gedächtnis der Beziehung zum Kunden. Verkaufschancen, Angebote, Gespräche, Serviceanfragen, Aufgaben und die Aktionen der Kundenbetreuer werden dort verwaltet. Eine CRM-Lösung wie Microsoft Dynamics 365 kann im Zentrum von Vertrieb, Kundenservice und Beziehungsmanagement stehen. Die CDP wiederum soll die Spuren zusammenführen, die der Kunde in verschiedenen Kanälen hinterlässt, und daraus eine einheitliche Kundensicht bilden. Webverhalten, Aktivitäten in der mobilen App, E-Commerce-Transaktionen, Kampagnenreaktionen, Treuebewegungen und weitere Kontaktdaten lassen sich in der CDP für Identitätsauflösung, Segmentierung und Aktivierung nutzen. Einfach gesagt: - Das CRM beantwortet die Frage: „Welche Beziehung führen wir mit diesem Kunden?“ - Die CDP beantwortet die Frage: „Wie gut kennen wir diesen Kunden über alle Kontaktpunkte hinweg?“ Diese beiden Strukturen sind keine Alternativen zueinander. Richtig entworfen, nähren sie einander. Die CDP kann Verhaltens- und Präferenzsignale an das CRM weitergeben. Verkäufe, Serviceleistungen oder Interaktionen mit Kundenbetreuern im CRM können umgekehrt das Kundenprofil in der CDP anreichern. Damit diese Beziehung gesund ist, muss allerdings vorab festgelegt werden, welche Daten in welchem System entstehen und welches System für welche Datendomäne die Autorität ist. Sonst beginnt zwischen CRM, CDP, ERP und Marketingplattform der Streit darüber, „welches denn nun der richtige Kundendatensatz ist“.

Die erste Entscheidung ist nicht die Technologie, sondern die Datenhoheit

Der Ausgangspunkt einer Integrationsarchitektur ist nicht das eingesetzte Werkzeug. Die erste Entscheidung betrifft die Hoheit über die Daten. Welches System verwaltet den Firmennamen des Kunden? Wo liegt der Stammdatensatz für die Kommunikationseinwilligung? Kommt die aktuelle Adresse aus dem CRM oder aus dem ERP? Welche Anwendung besitzt die Treuepunkte? Wie entsteht die eindeutige Identität eines Kunden? Woran erkennt man, dass in verschiedenen Kanälen entstandene Datensätze zu derselben Person gehören? Integrationen, die vor der Beantwortung dieser Fragen entwickelt werden, tragen die Unklarheit nur von einem System ins nächste. Für jeden wichtigen Datenbestand muss ein Stammdatensatz oder eine Stammdatenquelle — eine verlässliche Quelle — bestimmt werden. Andere Systeme dürfen diese Daten nutzen, anreichern oder für ihre eigenen operativen Zwecke kopieren. Welche Quelle die führende ist, muss jedoch unstrittig sein. Zum Beispiel: - Die führende Quelle für finanzielle Kunden- und Rechnungsdaten kann das ERP sein. - Die führende Quelle für Verkaufschancen und Aktivitäten der Kundenbetreuer kann Microsoft Dynamics 365 sein. - Verhaltensereignisse und das vereinheitlichte Profil können in der CDP verwaltet werden. - Kommunikationseinwilligungen können, je nach Regulierung und Prozessdesign, in einem eigenen Consent-Management-System liegen. - Kundeninteraktions- oder Erlebnisschichten wie 1Page Platform können Daten aus verschiedenen Quellen in einem einzigen Kontext darstellen. Diese Verteilung muss nicht in jedem Unternehmen gleich aussehen. Wichtig ist, dass die Rollen und die Datenarchitektur festgelegt sind.

Architektur darf nicht allein am heutigen Datenvolumen ausgerichtet werden

Eine Integration, die anfangs ein paar tausend Datensätze am Tag transportiert, muss zwei Jahre später womöglich Millionen von Verhaltensereignissen bewältigen. Deshalb sollte beim Architekturentwurf nicht nur das aktuelle Datenvolumen, sondern die Wachstumstendenz der Daten bewertet werden. Die folgenden Fragen sollten mit Prognosen über mindestens drei, besser fünf Jahre beantwortet werden: - Wie stark kann die Gesamtzahl der Kunden und Interessenten wachsen? - Welches Niveau kann die tägliche Zahl der Transaktionen und Ereignisse erreichen? - Wie viele Ereignisse pro Sekunde können aus Web, mobiler App und physischen Kanälen eintreffen? - Wie viel der historischen Daten wird aufbewahrt? - Wie schnell müssen Daten aktualisiert werden? - Welche Prozesse können in Echtzeit laufen, welche im Batch? - Auf das Wievielfache des normalen Volumens kann es in Kampagnen- oder Saisonzeiten gehen? - Aus wie vielen verschiedenen Quellen wird das Profil eines Kunden gespeist? Hier ist zu betonen, dass Echtzeitintegration nicht in jedem Fall die richtige Wahl ist. Ein Vertriebsmitarbeiter muss die letzte Serviceanfrage des Kunden vielleicht sofort sehen. Monatliche finanzielle Klassifizierungsdaten hingegen können durchaus nachts per Batch-Prozess übertragen werden. Jede Information in Echtzeit zu bewegen erhöht Kosten und Komplexität. Alles im Batch zu übertragen verlangsamt das Kundenerlebnis. Die richtige Architektur bringt den Bedarf an Geschwindigkeit mit dem Geschäftswert der Daten in Einklang.

Eine der wertvollsten Projekterfahrungen, die ich hier als Beispiel anführen kann, ist wohl das Starbucks-Projekt: in sieben Jahren mehr als 7 Millionen Kunden zu erreichen, Transaktionen in den Kanälen des Kunden binnen Millisekunden abzuwickeln und den entstehenden Andrang an der Kasse mit den richtigen Maßnahmen aufzulösen. Über die Zeit, die wir an diesem Projekt gearbeitet haben, ist all das für mich ein Beleg dafür, dass wir einen guten Stadtplan aufgestellt hatten.

Nicht nur die Zahl der Anwendungen zählt, sondern auch ihre Vielfalt

Vorherzusagen, wie viele Anwendungen künftig im Einsatz sein werden, genügt allein nicht. Auch wo diese Anwendungen laufen und wer sie betreiben wird, muss geplant werden. Mit der Zeit kann das Unternehmens-Ökosystem zu einer Mischung aus folgenden Bausteinen werden: - cloudbasierte Unternehmensanwendungen, - im Haus betriebene Altsysteme, - SaaS-Lösungen, die einzelne Fachbereiche eingekauft haben, - Plattformen von Geschäftspartnern und Händlern, - mobile Anwendungen, - eigens entwickelte Microservices, - Data Warehouses und Analyseumgebungen, - Dienste für künstliche Intelligenz, - Systeme in Filialen und im Außendienst. Je größer diese Streuung wird, desto schwerer wird es, nicht nur Verbindungen herzustellen, sondern sie auch sicher und beobachtbar zu halten. Welcher Dienst greift auf welche Daten zu? Wie wird autorisiert? Wenn ein Kunde Löschung oder Anonymisierung verlangt, aus welchen Systemen müssen die Daten entfernt werden? Wie werden API-Nutzungsgrenzen verwaltet? Wenn ein Datenfluss stoppt, wem fällt das auf? Eine Integrationsarchitektur muss deshalb API-Management, Authentifizierung, Autorisierung, Verschlüsselung, Protokollierung, Fehlerüberwachung und Wiederverarbeitung von Anfang an abdecken. Sicherheit ist keine nachträglich errichtete Schranke, sondern die Verkehrsregel, die schon beim Straßenbau entworfen wird.

Das Wachstum von Abteilungen und Nutzern gehört zur Architektur

Ein CRM- oder CDP-Projekt wächst nicht nur im Daten- und Systemmaßstab. Auch die Organisation wächst. Nutzt zu Beginn nur ein zehnköpfiges Vertriebsteam das CRM, können mit der Zeit Kundenservice, Marketing, Außendienst, Finanzen, Management, Händler und Geschäftspartner hinzukommen. Aus einer Struktur für fünfzig Nutzer können Hunderte, ja Tausende werden. Jede Abteilung sieht den Kunden durch ein anderes Fenster: - Das Vertriebsteam will Chancen und kommerzielles Potenzial sehen, - das Marketingteam Segmente und Kampagnenreaktionen, - der Kundenservice Anfragen und Zufriedenheit, - das Finanzteam Risiko und Zahlungsstatus, - die Operations-Teams den Liefer- oder Serviceprozess. Diese Bedürfnisse beruhen auf einer gemeinsamen Kundensicht; aber nicht jeder muss Zugriff auf alle Daten haben. Die künftige Zahl der Abteilungen und Nutzer beeinflusst daher unmittelbar das Rollenmodell, die Zugriffsrechte, das Bildschirmdesign, die Berichtsstruktur und die Lizenzplanung. Und die Integrationsarchitektur muss die Daten nicht nur ins richtige System bringen, sondern mit der richtigen Berechtigung und im richtigen Kontext zum richtigen Nutzer.

Was sind die Grundprinzipien einer belastbaren Integrationsarchitektur?

Sich auf die Zukunft vorzubereiten heißt nicht, am ersten Tag die größte und teuerste Infrastruktur zu bauen. Aber jene Entscheidungen, die verhindern, dass die Architektur beim Eintreten des Wachstums komplett ausgetauscht werden muss, müssen früh fallen. Dafür lassen sich einige Grundprinzipien übernehmen. Technologische Kopplung Eine Änderung in einem System darf nicht unmittelbar alle anderen Systeme betreffen. Anwendungen sollten möglichst über definierte APIs, Ereignisse oder gemeinsame Integrationsdienste kommunizieren. Gemeinsames Datenglossar Für Begriffe wie „Kunde“, „aktiver Kunde“, „Interessent“, „Auftrag“ und „Interaktion“ braucht es gemeinsame Definitionen. Dass dasselbe Feld in verschiedenen Abteilungen Verschiedenes bedeutet, muss verhindert werden. Service-/API-first-Design Wird eine neue Fähigkeit entwickelt, darf nicht nur der aktuelle Bildschirm oder die aktuelle Anwendung im Blick sein. Auch wie diese Fähigkeit künftig von anderen Anwendungen genutzt wird, gehört in die Planung. Ereignisbasierte Kommunikation Ereignisse wie eine Bestellung, eine Profilaktualisierung oder die Teilnahme an einer Kampagne können kontrolliert an die betroffenen Systeme ausgelöst werden. So muss nicht jede Anwendung das Quellsystem permanent abfragen. Beobachtbarkeit Ob eine Integration läuft, sollte nicht nur das technische Team manuell prüfen. Verzögerungen, Fehler, fehlgeschlagene Datensätze und Volumenänderungen müssen sichtbar sein. Ein Tagesabschluss und regelmäßige Health-Checks erhöhen zusätzlich die Verlässlichkeit des Systems. Wiederholbarkeit Ist ein System vorübergehend nicht erreichbar, dürfen keine Daten verloren gehen. Fehlgeschlagene Vorgänge müssen sicher gespeichert und nach Behebung des Problems erneut verarbeitet werden können. Warteschlangen und — besonders für mobile Anwendungen — Offline-Fähigkeit werden hier entscheidend. Sicherheit und Datenschutz Zugriffsrechte, Maskierung, Verschlüsselung, Aufbewahrungsfristen und Löschprozesse sollten natürliche Bestandteile der Architektur sein.

Wie sollte eine Integrations-Roadmap entstehen?

Die architektonische Vision darf langfristig sein; der Umsetzungsplan sollte in Stufen vorgehen. Erster Schritt: die Karte zeichnen In der ersten Phase werden Systeminventar, Datenquellen, bestehende Verbindungen und kritische Geschäftsprozesse bestimmt. Es wird geklärt, welches System welche Daten besitzt. Am Ende dieser Phase sollte das Unternehmen mindestens Folgendes in der Hand haben: - eine Karte der bestehenden und der Zielsysteme, - die kritischen Datenflüsse, - eine Matrix der Datenhoheit, - einen gemeinsamen Ansatz für die Kundenidentität, - Prinzipien für Sicherheit und Autorisierung, - Volumen- und Leistungsprognosen, - eine priorisierte Liste der Integrationen. Zweiter Schritt: das Rückgrat bauen In der zweiten Phase werden API- und Integrationsstandards festgelegt. Mechanismen für Identitätsabgleich, Fehlerbehandlung, Überwachung und Protokollierung gehen in Betrieb. Einige wenige Flüsse mit dem höchsten Geschäftswert werden Ende-zu-Ende umgesetzt. Ziel ist nicht, alle Systeme auf einmal zu verbinden, sondern das verlässliche Rückgrat zu schaffen, auf dem die späteren Verbindungen aufsetzen. Dritter Schritt: CDP- und CRM-Anwendungsfälle erweitern Das Kundenprofil wird angereichert; Vertriebs-, Service- und Marketingszenarien kommen ins System. Abteilungsbezogene Sichten und Berechtigungen reifen aus. Vierter Schritt und danach: Skalierung und Modell Mit wachsendem Datenvolumen, steigender Anwendungszahl und größerer Nutzerbasis werden Kapazitätstests, Kostenoptimierung und Architektur-Reviews zur Routine. Ein Integrationsleitfaden sorgt dafür, dass neue Integrationen denselben Standards folgen. Eine Roadmap sollte nicht als starrer Projektplan verstanden werden, sondern als Stadtplan, der mit dem Unternehmen mitwächst.

Messen Sie den Erfolg nicht an der Zahl der Verbindungen

Der Erfolg eines Integrationsprogramms lässt sich nicht daran messen, wie viele Systeme angebunden wurden. Eine große Zahl von Verbindungen kann ebenso gut ein Zeichen unkontrollierten Wachstums sein wie guter Architektur. Aussagekräftiger sind diese Maßstäbe: - die Zeit, die es braucht, eine neue Anwendung ins Ökosystem einzubinden, - der Anteil fehlerhafter oder verlorener Datensätze, - die Verzögerung bei der Aktualisierung des Kundenprofils, - der Anteil der Kunden, die sich nicht eindeutig zusammenführen lassen, - der Bedarf an manueller Datenkorrektur, - die Zeit bis zur Erkennung einer Integrationsstörung, - die Zeit, bis neue Abteilungen ins System aufgenommen sind, - die Klarheit darüber, wem Datenfelder gehören und woher sie stammen, - die Zahl der Verbindungen, die eine Änderung an einem System betrifft. Eine gesunde Architektur macht Wachstum unsichtbar. Wenn die Komplexität nicht im selben Tempo steigt wie die Zahl der Anwendungen, Nutzer und Datensätze, ist das Fundament richtig gelegt.

Fazit: Der Verkehr von morgen steckt in den Architekturentscheidungen von heute

CDP- und CRM-Projekte starten meist mit Bildschirmen, Funktionen und kurzfristigen Integrationslisten. Dabei ist es das dahinterliegende Datenverkehrssystem, das über den langfristigen Erfolg dieser Projekte entscheidet. Ein Unternehmen, das heute nur eine Handvoll Anwendungen verbindet, kann in wenigen Jahren zu einer Struktur werden, die Daten aus Dutzenden Anwendungen bezieht, Millionen von Kundenereignissen verarbeitet und Tausende Nutzer aus verschiedenen Abteilungen bedient. Wird diese Möglichkeit zu Projektbeginn nicht vorhergesehen, erhöht jede neue Verbindung sowohl die Investitions- als auch die Betriebslast. Wird sie erkannt und richtig geplant, wird jede neue Anwendung zu einem natürlichen Plug-and-play-Teil der bestehenden Architektur.