Sind dir im Bereich des E-Commerce auch schon komplexe Diskussionen über den Weg gelaufen, welches Team oder welche Abteilung "den Kunden" besitzt? Und was alles zu "dem Kunden" gehört und was nicht? Dieser Artikel bringt hoffentlich zusätzliche Einsichten in die Ursachen dieser Diskussion und bietet einen möglichen Lösungsweg an.
Vertikalisierung schärft Begriffe
In den letzten Jahren hat unsere Firma, neuland, vermehrt vertikalisierte Eigenentwicklungen für und mit unseren Auftraggebern betreiben können. Das Ziel ist, die organisatorische und technische Trägheit bisheriger monolithischer Systeme zu überwinden. D.h. wir können durch Vertikalisierung organisatorisch skalieren, um die Entwicklungsgeschwindigkeit steigern zu können, und wir können die Qualität der Lösungen schneller steigern (kurze Iterationszyklen).
Dazu zerlegen wir vormals monolithisch angelegte E-Commerce-Systeme in mehrere voneinander komplett getrennte Systeme, die dem Muster von Self-Contained Systems (SCS) folgen. Durch dieses Muster und moderne Automatisierung können in unseren Projekten viele Teams voneinander vollständig entkoppelt arbeiten. D.h. es können z.B. 40 EntwicklerInnen an einer E-Commerce-Plattform in 5 8-Personen-Teams arbeiten und jedes Team kann unabhängig von den anderen 50 mal am Tag deployen (im Schnitt sind 10 Deployments pro Team und Tag typisch).
Diese Vorteile lassen sich allerdings nur sinnvoll nutzen, wenn auch die fachliche Entkopplung der Teams gelingt. D.h. wenn die Entwicklung eines neuen Features i.d.R. komplett allein innerhalb eines SCS und damit eines Teams erfolgen kann. Andernfalls müssen sich Teams häufig abstimmen und die organisatorischen Skalierungsvorteile gehen verloren. Es wird also neben den technischen Architekturmustern, die Entkopplung bei der "Handarbeit" ermöglichen, ein fachliches Schnittmuster benötigt, welches die Entkopplung auf der fachlichen/organisatorischen Ebene unterstützt: Dies leistet die kundenzentrierte Vertikalisierung. Im Rahmen solch fachlicher Schnittmuster ist wiederum eine intensive und kontinuierliche Schärfung fachlicher Konzepte und Begriffe erforderlich, um Fehler zu vermeiden, die die Kopplungen zwischen SCS-Teams dauerhaft erhöhen.
Typische Indikatoren für ungünstige Kopplungen sind Brüche in den sprachlichen Verwendungskontexten der Begriffe: Zwei Gruppen/Teams benutzen das gleiche Wort, aber in unterschiedlichen Kontexten. Die Entdeckung solcher Brüche deckt sich mit Konzepten rund um die "ubiquitous language" im Domain Driven Design.
Zwei mal "KundIn"
In dem Prozess kontinuierlicher Schärfung von Fachlichkeit ist mir in letzter Zeit ein spezifisches Spannungsfeld um den Begriff des/der "KundIn" immer wieder begegnet: Ich glaube, man muss im E-Commerce den/die "KundIn" in (mind.) zwei Begriffe aufspalten, die getrennt voneinander behandelt werden müssen.
Ich versuche den Bruch mit den Zusätzen "juristisch" und "Marketing" aufzulösen. Ich habe als Architekt mit unterschiedlichen Personen gesprochen, die den Begriff "Kunde" benutzen, und sicher sind, die Hoheit über die Entität "KundIn" besitzen zu müssen. Die einen argumentierten aus der Sicht von Marketing/Personalisierung von Angeboten, die anderen aus Sicht von "Vertragsabschluss" und persönlichem "Konto".
Für mich ergibt sich eine Differenz, die ich so beschreibe:
- Das Marketing interessiert sich dafür, "KundInnen" attraktive Angebote zu machen (digital wie analog). Ein Stichwort dazu ist "Bedarfsweckung". Dabei tauchen Konzepte wie "Kampagnen", "Gutscheine", "Aktionen" auf, die die Marketingangebote und ihre Steuerung umfassen. Der/die "KundIn" taucht primär auf als "Sitzung", "Tracking", "Kundensegment", "Haushalt/Familie" etc. und erst nachrangig als der/die juristisch eindeutig identifizierte KundIn. Eigenschaften einer "Sitzung" werden eher in Wahrscheinlichkeiten (zu 73% weiblich) ausgedrückt. Es ist i.d.R. wichtiger, das aktuelle Bedürfnis anhand aktuellem Verhalten zu erkennen als historische Daten zu analysieren.
- Beim "Vertragsabschluss" spielen dagegen z.B. Zahlungsvorgänge, das Handhaben sensibler persönlicher Daten und ihre korrekte historische Verwaltung ("Umzug", "Konto") die entscheidende Rolle. Es gibt extrem hohe Ansprüche an sichere Authentifikation und Autorisation von KundInnen und an die Korrektheit von Daten. KundInnen können sich mehrfach registrieren und werden auch getrennt geführt, wenn nicht juristisch vertretbar ein Doppelkonto erkannt werden kann.
Ich glaube es hier mit zwei verschiedenen Begriffen zu tun zu haben, die nur gerne die gleiche Bezeichnung erhalten: "KundIn". Und ich halte es für extrem hilfreich, beide voneinander zu trennen, weil sie tatsächlich andere Ansprüche erfüllen müssen. Aus Sicht des Marketing kann man es online schon zu Beginn einer Sitzung mit einem/r MarketingkundIn zu tun haben. Erste beobachtbare Verhaltensweisen beim Besuch einer Website (z.B. über das Tracking: Clicks) können genutzt werden, um Kampagnen zu beginnen, Gutscheine anzubieten u.a. Zu dem Zeitpunkt sind MarketingkundInnen aber noch weit vom Konzept juristischer KundInnen entfernt, wie es beim Vertragsabschluss eine Rolle spielt. Und vielleicht kommt es auch nie zu einer Registrierung im Sinne der/des juristischen "KundIn".
Erst wenn sich KundInnen registrieren, werden ihre Sitzungen mit einer/m "juristischen KundIn" verbunden. Aber selbst bei personengebundenem Marketing kann es sinnvoll sein, dieses an Konzepten wie "Haushalt" u.ä. zu binden und nicht jedem Mitglied eines Haushalts den gleichen Gutschein zu schenken.
Entkoppelt man beide Konzepte voneinander, entsteht in beiden Bereichen mehr Flexibilität in der Entwicklung von Ideen und Lösungen. Z.B. können Anonymisierungen für "MarketingkundInnen" gewählt werden, die einen freieren Umgang mit den Daten erlauben.
Besonders wichtig aus Sicht des Themas kundenzentrierter Vertikalisierung ist, dass der/die juristische KundIn vorrangig in direktem Kontext eines Kundenbedürfnisses entsteht: Dann, wenn KundInnen sich entscheiden zu kaufen. Dagegen sind die Marketing-Konzepte rund um Bedarfsweckung/Aufmerksamkeit allenfalls sehr mittelbar mit einer Kundenmotivation verbunden, eher handelt es sich hier um eine Motivation der Organisation/Firma. D.h. der/die MarketingkundIn entsteht in keinem Kontext eines Kundenbedürfnisses. Stattdessen möchte die Organisation hier etwas erreichen und verwendet in diesem Kontext einen KundInnenbegriff, der anderen Anforderungen und Gesetzmäßigkeiten unterworfen wird.
Trennung in verschiedene Entitäten
Die Schlussfolgerung ist meiner Meinung nach, dass die Konzepte und damit die Entitäten der "juristischen KundInnen" von den "MarketingkundInnen" getrennt werden sollten, da sie nicht das gleiche meinen und in ganz unterschiedlichen Kontexten ihren Ursprung haben und Verwendung finden.
Insbesondere im Rahmen einer kundenzentrierten Vertikalisierung wird der Nutzen dadurch deutlich, dass es sich um verschiedene Teams handelt, die auf diese Weise voneinander entkoppelt werden: Beide Teams können ihre Entitäten unabhängig erzeugen, löschen und ändern. Und sie müssen sie lediglich zur Replikation bereitstellen, wenn sie von anderen benötigt werden. Aber die Use Cases von juristischen Ansprüchen genügenden KundInnenregistrierungen für Kaufabschluss und Kontoverwaltung (inkl. Datenschutz und ggfs. AGBs) können komplett getrennt von denen um Marketing umgesetzt werden - und vice versa.
Um die Verwirrung noch etwas zu steigern: Das bedeutet, dass im Rahmen von Marketingaktionen juristische KundInnen entstehen können (z.B. bei Gewinnspielen). User-Interfaces für solche Registrierungen gehören dann dem Team, welches die juristischen KundInnen besitzt. D.h. die beiden KundInnen-Begriffe müssen immer präsent sein und in den Use Cases korrekt unterschieden werden.
Technisch bedeutet das: Es sollte nur Referenzen zwischen "MarketingkundInnen" und "juristischen KundInnen" geben, aber diese Referenzen müssen frei wählbar sein und dürfen nicht an die Restriktionen des jeweils anderen KundInnen-Begriffs gekoppelt sein.