Wie mein Kollege Stefan Reissing im Tipp der Woche 9 dieses Jahres bereits beschrieben hat, ist ein so genanntes Data Driven Decision Making (DDDM) ein sehr guter Ansatz zur Entscheidungsfindung auf Basis aller im Unternehmen vorliegenden Daten.
Heute möchte ich Ihnen darauf aufbauend das Data Driven Operational Model (D-DOM) in diesem Tipp der Woche vorstellen um damit die Theorie auf eine praxis-relevante Ebene zu überführen und Ihnen gerade im Hinblick auf AI Funktionalitäten ihres Kundenservices, greifbare Ideen mitzugeben.
Basis jeder AI-Funktionalität im Kundenservice im Rahmen von (Voice)-Bots sind Identifizierung und Authentifizierung des Kunden, Intent-Erkennung und parallel dazu Micro-Services, Prediction-Logik, Algorithmen oder Decision Engines, welche wiederum auf Datenmodellen und derer Interpretation aus den verfügbaren Unternehmens- und Kundendaten aufbauen.
Jetzt könnte man nun annehmen, dass es im Prinzip doch sehr einfach sein muss. „Einfach alle verfügbaren Daten in einer sinnvollen Art zusammenführen, eine AI darüber laufen lassen und am Ende stehen dann die fertigen Use Cases inklusive Mirco-Services und Prediction Scores.“ Klingt einfach und so einfach ist es in der Realität aber leider nicht.
Zunächst ist es wichtig sich den Ausgangszustand zu vergegenwärtigen
Jede Kunden-Interaktion-Schnittstelle sammelt viele Kunden-Daten(punkte) und diese summieren sich in der Laufzeit der Schnittstelle auf eine enorme Menge. Um es anhand von verfügbaren Daten für einen Bestellprozess etwas greifbarer zu machen:
Abseits davon, dass jede einzelne dieser Daten-Sammlungen schon sehr unterschiedliche Dimensionen des Kundenverhaltens für einen einzigen Prozess (Bestellung) beleuchtet, sind diese auch innerhalb der jeweiligen Daten-Silos sehr komplex und nicht immer intuitiv sortiert und einfach nutzbar so dass hieraus kein eindeutiges stereotypisches Verhaltensmuster der Kunden und damit AI Use Case abgleitet werden kann.
Hinzu kommt, dass wir hier in Summe teilweise von Datenmengen im mehrstelligen Terabyte-Bereich und sogar mehr sprechen, denn diese (Datensammlungs-)Systeme laufen und sammeln meist schon mehrere Jahre.
Sobald Sie jetzt anfangen für eine Use Case Ermittlung oder einen PoC direkt in den Systemen bzw. in den Backends Datenabfragen in einer relevanten Menge und Frequenz zu tätigen oder selbst direkt Verknüpfungen zwischen diesen und anderen Datenbanken zu erstellen, wird die Last auf den Backends vermutlich schnell so groß werden, dass der Anruf eines Systemadministrators mit dem Verweis auf eine „Architecture Violation“ nicht lange auf sich warten lassen wird, sofern Sie selbst ohnehin die Berechtigung auf den Zugriff besitzen und ihre eigene Workstation oder ihr Terminal in der Lage ist diese großen Datenmengen zu verarbeiten.
Für einige Aspekte der Datenanalyse bieten zwar große Anbieter wie Google mit der Analytics Komponente bereits System-Ressourcen-schonende Lösungen, Online-Daten und Abfragen zu konsolidieren und Standard-KPIs aufzuführen aber das reduziert nicht die Menge der Daten im Hintergrund und hier betrifft es insbesondere und ausschließlich Online-Interaktionen. Hinzu kommt dass einige Hersteller wie Apple mit ihrer neuen Privacy Policy und Data Consent Regelung die Weitergabe an Daten aus Applikationen oder Apps mit einer aktiven Zustimmung versieht, was die Datenqualität an sich verringern kann.
Tipp 1: Überlegen Sie sich eine Strategie welche Datenquellen sie für eine AI-basierte Use Case Entwicklung heranziehen wollen und müssen und dann – wichtig – auch wirklich brauchen. Brauchen Sie tatsächlich Kundenverhaltensdaten von vor drei oder vier Jahren während sich sowohl ihre Produkte, Services als auch das generelle Kundenverhalten in diesem Zeitraum geändert haben?
Versuchen Sie besser zunächst einfache und ohne viel Datenaufwand und Schnittstellen verursachende Use Cases mit aktuellen Daten zu konzipieren. Diese Daten können verhältnismäßig einfacher für eine Analyse abgezweigt werden und oft reicht schon ein Extrakt von wenigen Hundert Kunden um rein statistisch schon eine gute Trefferquote zu landen. Und egal wie gut sie auch mit der ersten Iteration „treffen“, werden sie um eine nachträgliche Nachjustierung nicht herum kommen.
Wenn sich ihre Annahmen in diesem ersten Use Case bewähren, können diese dann Schritt für Schritt erweitert und mit weiteren Datenquellen und Services angereichert werden und sie können gemeinsam mit ihrer KI lernen. Scheitern diese bereits am Anfang ist zudem die Ursachenforschung dann auf weniger Fehlerquellen beschränkt und man kann auf dieser Basis schneller korrigieren und im Nachgang sukzessive auf dieser Basis aufbauen.
Sie gewinnen somit an drei Stellen: Velocity, Relevanz und Qualität.
Daten sind bekanntlich das neue Gold und somit werden diese ausgiebig und so oft es geht gesammelt. Man weiß ja schließlich nie wofür man diese noch gebrauchen kann und wenn man sich vergegenwärtigt, welche Daten dann auf eine Online-Bestell-Journey oder über App-Berechtigungen freiwillig preisgegeben und auf der anderen Seite gesammelt werden, kann man sich vorstellen was da alles zusammen kommt. Es wird genommen was angeboten wird:
Keine Sorge: Ich möchte jetzt aber nicht auf die ethisch-moralische Seite oder Datenschutzaspekte hinaus, sondern rein aus einer AI-Use Case Entwicklungsstrategie und auf Basis von Clean Data überlegen, was hierfür Sinn ergibt.
Benötige ich zum Beispiel persönliche Informationen oder Merkmale zu Alter, Geschlecht, Wohnort oder Standort für meinen Use Case?
Auch wenn es vielleicht interessant sein könnte eine Auswertung zu haben, ob ein männlicher Kunde zwischen 34 und 49 Jahren mit Wohnort in Norddeutschland und aktuell in München in einer Eigentumswohnung lebend, eine X-prozentige Wahrscheinlichkeit eher ein Produkt zu beziehen als eine weibliche Kundin zwischen 18 und 26 Jahren mit Wohnort in Berlin in einer WG, kann das für den Erfolg des betreffenden Use Cases überhaupt keine Rolle spielen.
Das Interessante einer KI ist, dass zuvor als logisch angenommene Zusammenhänge in der Realität und mit echten Kunden getestet am Ende komplett über den Haufen geworfen werden können.
Vergessen Sie bitte auch nicht: Jede zusätzliche Verknüpfung mit einer weiteren Datenquelle kostet Rechenleistung und damit Geschwindigkeit, Zeit und Geld für die Entwicklung einer entsprechenden Schnittstelle und eines entsprechenden Abfrage-Algorithmus. Zudem steigt das Ausfallrisiko einer Auswertung mit mehreren Applikationen und Schnittstellen nicht linear sondern exponentiell.
Tipp 2: Auch wenn sehr viele verfügbare Daten(quellen) und Verknüpfungen verfügbar sind und verführerisch erscheinen, sind viele davon überflüssig und für den Erfolg eines Use Cases nicht relevant. Sie werden mit weniger Schnittstellen auch schon gute Effekte und erste Learnings erzielen auf denen sie gut aufbauen können.
Achten Sie lieber darauf „Clean Data“ zu haben, also solche die von Unschärfe oder Manipulationen nicht oder nur schwer beeinflussbar sind. Wenn Sie mit wenigen Datenquellen und wenigen Daten starten, sollten diese auch „sauber“ sein um ein optimales Start-Ergebnis zu erzielen.
Daten allein haben keine Aussagekraft es bedingt einer Interpretation um diese brauchbar zu machen. Fragen Sie sich: Inwiefern tragen diese Daten und Informationen zu dem von mir geplanten Use-Case bei? Welche Daten(quellen) sind wichtig und welche nicht. Ähnlich einer Customer Journey Analyse wird empfohlen hier für jeden Schritt des Use Cases zu prüfen ob und welche Dateninformation hier einen tatsächlichen Mehrwert bietet.
Wichtig ist parallel zu prüfen und überlegen, welche dieser Daten eine hohe Relevanz und welche lediglich einen indikativen Charakter und Einfluss haben. Zum Beispiel kann bei einem Bestellprozess der Kredit-Score für einen Kunden einen wesentlichen Einfluss auf die angebotenen Zahlarten haben. Ebenso kann es wichtig sein, zu berücksichtigen welche Produkte zuvor bestellt wurden, um entsprechende, noch vor Abschluss der Kaufvorgangs, Add-On-Angebote oder Services auszuspielen.
Ob der gleiche Kunde jedoch zuvor mehrfach vor dem Bestellvorgang ein Produkt in der App, dann im Web in und dann aus dem Warenkorb genommen hat, oder in einer Zufriedenheitsumfrage den Bestellprozess aus Grund X oder Y negativ bewertet hat, ist hier eher sekundär zu sehen und spielt beim Ausspielen eines Bestell-Support-AI-Use Cases eine untergeordnete Rolle.
Gleichzeitig kann aber eine zeitliche Analyse einer Kundenverhaltens-Chronologie, Abhängigkeiten aufzeigen, die sowohl für eine Use-Case-Entwicklung als auch Prozessanpassung nutzbar sind. Einige Daten verfügen über Time-Stamps, andere wiederum nicht und hier ist es klug zu prüfen inwiefern der zeitliche Faktor eine Rolle bei dem jeweiligen Use Case spielen kann.
Tipp 4: Daten auszuwählen und zu verknüpfen ist nur die halbe Miete. Prüfen Sie wie die Informationen und Daten voneinander aber auch externen Einflüssen abhängen. Und wichtig: Welche für ihren Use Case Sinn ergeben und Priorität haben. Erst wenn diese Logik nachvollzogen werden kann, macht es Sinn die entsprechenden Aufwände für die Datenbereinigung, Verknüpfung, Backend-Schnittstellen-Entwicklung und Use Case Design anzugehen.
Wie bereits erwähnt, gibt es unterschiedlichste Datenquellen und diese werden in der Regel auch von unterschiedlichen Unternehmensbereichen selbst verwaltet und isoliert betrachtet.
Ergo: Wenn das Daten Know-How, die Kompetenz und Verantwortlichkeit für AI Use Cases nicht zentral zusammengeführt und verantwortet wird, entstehen diese typischen Effekte. Hier ein paar Beispiele, die ihnen vermutlich bekannt vorkommen:
Tipp 5: Es ist bei dem Thema AI-Data Management und AI Use Case Entwicklung absolut essenziell die Komponenten: Überblick, Urteilskraft und Tatkraft in eine zentrale Funktion und Hand zu übergeben.
Dies ist im Idealfall ein X-funktionales Team aller betroffenen Abteilungen, welches auf Basis vorgegebener Unternehmensprioritäten die entsprechenden Datenquellen und Daten selektiert, aufbereitet und für etwaige Priorisierungen bei der Use Case Entwicklungen erstellt und diese ganzheitlich End-2-Ende verantwortet.
Der übergeordnete Fachbegriff hierfür ist „Data Driven Operating Model“ oder kurz D-DOM welches als Eckpunkte folgende Elemente beinhaltet:
Fazit:
Einfach AI Use Cases zu entwickeln, indem man Daten zusammenführt diese zentral ablegt und dann nur noch warten muss bis diese sich von allein in automatisierte Use Cases verwandeln gehören in die Welt der Märchen und Sagen.
Die Realität ist deutlich komplizierter aber auch kein Hexenwerk, wenn man sich der Ausgangslage bewusst ist und weiß in welche Richtung eine Organisation entwickelt werden muss um dieses Themenfeld erfolgreich zu gestalten.
Sie werden ohnehin vermutlich sehr schnell auf die in diesem Tipp aufgeführten Hindernisse stoßen und diese können die Argumentationsbasis für die weitere Transformation ihrer Organisation in Richtung D-DOM liefern.
Daher gilt grundsätzlich:
Carlos Carvalho – Senior Consultant
junokai