Wenn es darum geht, mit den Methoden der Customer Analytics tiefere Einsichten in das Verhalten oder den Wertbeitrag der eigenen Kunden zu gewinnen, steht zunächst immer die Frage: Welche Daten benötigen wir? In welcher Qualität müssen die Daten vorliegen?
Und schon hier setzt in vielen Fällen die Ernüchterung ein: "Unsere Daten sind fragmentiert, qualitativ sehr heterogen, von ordentlich bis fragwürdig. Wir haben keine einheitliche Datenbasis, die Daten sind nicht vollständig im Data Warehouse abgebildet und Änderungen wie Datenbereinigungen sind teuer." Schon mal gehört?
Und dann der Schluss: "Bevor wir hier Erkenntnisse gewinnen können, müssen wir erstmal aufräumen, konsolidieren, anreichern!" Kurz: ein umfangreiches IT-Projekt starten.
Geht es dann noch um den Wunsch z.B. des Marketingleiters, künftig auch verstärkt Webdaten zur Auswertung des Kundenverhaltens zu nutzen - ein "klassisches" Big Data Thema - dann wird die Situation nicht einfacher.
Kürzlich las ich im Blog des Harvard Business Review einen Beitrag von Bill Franks, der ziemlich genau die Erfahrungen beschreibt, die auch wir häufig machen. In vielen Organisationen sehen wir nämlich, dass bei dieser Art der Herausforderung einem traditionellen Weg gefolgt und mit klassischem Projektmanagement über Anforderungsspezifikationen und Implementierungen von Datenerfassungs- und Transformationsprozessen begonnen wird. Dann, nach längerer Projektlaufzeit, können auf der vermeintlich besseren Datenbasis erste Piloten zu Customer Analytics gefahren werden. Iterationen wegen veränderter Anforderungen und neuer Erkenntnisse, was wirklich benötigt wird, sind die Regel. Dieses Vorgehen ist häufig teuer und langwierig. Wichtige Business-Ziele werden erst spät erreicht - oder fallen sogar dem Rotstift zum Opfer.
Muss das so sein? Gibt es eventuell einen schlankeren Weg?
Die agile Softwareentwicklung macht uns vor, wie wir wieder verstärkt die zu erreichenden Ziele in den Vordergrund rücken. Mit kurzen "Entwicklungssprints", die auf kleinere und fassbare Aufgabenstellungen fokussieren und schnell Sichtbarkeit und Prüfbarkeit erzeugen. Aber wie kann das bei analytischen Fragestellungen funktionieren?
Auch hier gilt: Mit kleinen und fassbaren Teilaufgaben beginnen. Beispielsweise hat sich bewährt, Piloten auf einmaligen Datenabzügen mit einem fachlichen Teilfokus durchzuführen. Und dann schnell in die Daten reinleuchten, Machbares abschätzes, Fehlendes identifizieren, erste wertvolle Business-Antworten liefern und präsentieren.
Mit SAS Visual Analytics wird diese Art des Prototyping sogar noch einfacher: Die Datenaufbereitung ist schlank, Analysen und Berichte können ohne Coding und Implementierung erzeugt und unmittelbar visualisiert werden. Die erzielten Ergebnisse sind so auch zügig einem größeren Kreis von Entscheidern verständlich darstellbar. Das schafft Buy-In für nachfolgende Schritte.
Innovative Technologien ermöglichen also auch hier ein Umdenken: Es lohnt sich, klassische Arbeitsweisen zu überprüfen und durch agilere, schlankere Verfahren zu ersetzen. Probieren Sie es aus!
