Was muss (m)ein BI-Tool leisten? Die Digital Analytics Value Chain

Heute behauptet eine Vielzahl von Anbietern, BI, also Business Intelligence, zu machen. Wer eine BI-Lösung für sein Unternehmen anschaffen will, steht damit vor einem Problem, denn weil der Begriff so facettenreich ist und jeder ihn anders (d.h. zu seinem Vorteil) auslegt, wird es immer schwieriger, die Spreu vom Weizen zu trennen und eine Software zu finden, die genau die Funktionen mitbringt, die für die eigene Organisation entscheidend sind.

Die Digital Analytics Value Chain

Business Intelligence kann als eine Wertschöpfungskette betrachtet werden, von den rohen Daten bis hin zu fertigen Analysen und Handlungsempfehlungen. Aus dieser Überlegung heraus habe ich die „Digital Analytics Value Chain“ entwickelt. Mit ihrer Hilfe kann eine Software, die als „BI“ beworben wird, darauf überprüft werden, wieviele und welche Schritte der Wertschöpfungskette tatsächlich abgedeckt werden. Ein Beispiel: Obwohl es viele Visualisierungswerkzeuge gibt, die alle mit dem Label „BI“ versehen werden, leisten diese in der Regel nur einen kleinen Teil dessen, was wirklich von einer umfassenden BI-Plattform erwartet wird.

Vor einer Entscheidung für ein bestimmtes BI-Produkt sollte das Team deshalb genau festlegen, welche Aspekte der Digital Analytics Value Chain die Lösung enthalten muss. Mit diesem Paket an Anforderungen kann eine effiziente Vorauswahl unter den Anbietern getroffen werden, bevor  es in die Detailanalyse und Prüfung weiterer Kriterien geht. 

Digital Analytics Value Chain

Collection (Sammlung)

Die Sammlung oder Erfassung der benötigten Rohdaten ist die Grundvoraussetzung für eine spätere Analyse. Dabei lassen sich zwei Typen unterscheiden: Tools, die diese Daten selbst generieren, die also selbst als Primärdatenquelle dienen, und Tools, die andere, externe Primärdatenquellen abfragen und deren Datenbestand archivieren. Das wohl bekannteste Beispiel für den ersten Typ ist Google Analytics, das das Verhalten der Besucher auf einer Website mit seinem eigenen Tracking-Code misst. Klassische BI-Tools gehören dagegen in der Regel zum zweiten Typ, da sie ausschließlich für die Analyse und nicht für die Erzeugung neuer Informationen gedacht sind.

Vor der Entscheidung für ein neues BI-Tool sollte die Frage beantwortet werden, ob die bereits im Unternehmen vorhandenen Systeme alle relevanten Informationen erfassen und speichern, oder ob zunächst eine Lücke im Datenbestand geschlossen werden muss. Neben den üblichen Tracking-Systemen wie Google Analytics & Co., die Ereignisse passiv belauschen, zählen natürlich die transaktionsbasierten Systeme, also Wawi bzw. ERP, und die stammdatenbasierten Systeme wie CRM und PIM, zu den zentralen Datenquellen, die von einer BI-Lösung genutzt werden können. Es macht also in der Regel nur dann Sinn, eine BI-Lösung mit eingebauter Tracking-Komponente anzuschaffen, wenn der entsprechende Sachverhalt nicht durch andere Datenquellen abgedeckt wird.

Cleansing (Bereinigung)

Da aus den angeschlossenen Datenquellen häufig Informationen mit gemischter Qualität kommen, die die Validität von Analysen beeinflussen können, ist es – zumindest in größeren Projekten – eine gute Praxis, Maßnahmen zur Bereinigung und Sicherheit der Datenqualität vor der Weiterverarbeitung durchzuführen. Dies kann die Erkennung von Ausreißern (z.B. absurd hohe Werte), die Eliminierung von Duplikaten oder auch die inhaltliche Überprüfung (z.B. durch Adressverifizierung) beinhalten. Die Anforderungen an die Bereinigung hängen stark von den Datenquellen einerseits und von den Anwendungszwecken der BI-Lösung andererseits ab. Soll die BI zur Adressselektion genutzt werden mit der Folge, dass aus dieser Datenbasis ggf. tausende Briefe postalisch verschickt werden, ist die Nutzung einer Software zur Adressvalidierung sicher eine sehr gute Idee.

Die Datenbereinigung ist, da sie häufig teure Zusatzsoftware erfordert, nicht Teil des Standardumfangs der handelsüblichen BI-Lösungen. Hier sollte also bei der Beschaffung besonders darauf geachtet werden, dass der Aspekt nicht vernachlässigt wird. Denn auch mit der modernsten Software gilt sonst: Shit in, shit out…

Linking (Verknüpfung)

Kommen Daten aus unterschiedlichen Quellen, müssen diese nicht nur gemeinsam in einem Data Warehouse gespeichert, sondern auch inhaltlich verknüpft werden. In dieser Verknüpfung liegt häufig der große Mehrwert einer BI-Lösung, da sich die entsprechenden Analysen sonst nur, wenn überhaupt, mit hohem Aufwand durchführen lassen. Das Standardbeispiel im eCommerce ist die Verknüpfung von Warenwirtschaftsdaten wie Retouren und Einstandspreisen mit Marketing-Kanälen aus dem Webanalyse-System.

Während nahezu alle BI-Tools solche Verknüpfungsmöglichkeiten anbieten (abgesehen von reinen Visualisierungswerkzeugen), unterscheidet sich die Implementierung mitunter stark. Viele Tools bringen die unterschiedlichen Datenquellen nicht wirklich physisch zusammen, sondern verknüpfen die Daten lediglich in der Abfrage- oder Visualisierungsschicht ad hoc. Das hat mehrere Nachteile: da die Verknüpfung immer im Moment der Anzeige berechnet werden muss, ist die Performance deutlich schlechter; meist muss der Anwender wissen, wie die Verknüpfung herzustellen ist, sich also mit dem Datenmodell auskennen; und es schränkt die Analysemöglichkeiten ein auf simples Addieren oder Multiplizieren von Werten. High-End BI-Lösungen ermöglichen es, diese Verknüpfungen bereits bei der Datenmodellierung anzulegen, sodass sie vorberechnet werden. Spezialisierte Branchenlösungen stellen die Verknüpfungen sogar automatisch her.

Structuring (Strukturierung)

Die Strukturierung von Daten ist Kernaufgabe eines klassischen Data Warehouses. Während die Informationen in den Datenquellen zur operativen Nutzung optimiert sind, geht es in einem Data Warehouse darum, sie möglichst leicht und performant abfragbar zu machen. Darüber hinaus sollte an diesem Punkt die Frage, aus welchem Vorsystem eine Information kommt, keine Rolle mehr spielen. Die Data Warehouse-Struktur abstrahiert von den Eigenheiten der Datenquellen und ist typischerweise stark denormalisiert und redundant. Gängige Strukturierungsmodelle sind Star- oder Snowflake-Schema.

Seit einigen Jahren zeichnet sich ein Trend hin zu Ad-hoc-Reporting- und Visualisierungswerkzeugen ab, die, begünstigt durch immer mehr und günstigeren Hauptspeicher, mit In-Memory-Technologien die Notwendigkeit zu teuren, dedizierten Data Warehouses reduzieren. Das Versprechen dieser neuen Generation von Tools ist Self-Service-BI, bei dem jeder Anwender seine Analysen einfach komplett selbst und ohne Hilfe oder Vorarbeit der IT zusammen klicken kann. So verlockend diese Vorstellung ist, so gern wird vergessen, dass damit auch der Schritt der Strukturierung und Vereinheitlichung entfällt, sodass Anwender gezwungen sind, sich viel tiefer in die Struktur der Datenquellen einzuarbeiten und selbst Kennzahlendefinitionen zu erarbeiten, was dem Ziel eines richtigen BI-Projekts zuwiderläuft.

Enrichment (Anreicherung)

Der Wert einer BI-Lösung liegt in denjenigen Analysen, die mit den reinen Rohdaten nicht möglich sind, die also aus einer Kombination, Weiterverarbeitung und Anreicherung der Daten entstehen. Die Möglichkeiten reichen von einfachen berechneten Kennzahlen über komplexere Berechnungen wie Customer Lifetime Values bis hin zu Cluster- und Kohortenbildungen und Customer Journey Verkettung.

Wichtig bei der Anschaffung einer BI-Lösung ist, dass die Architektur diese Form von nachgelagerten Berechnungen und Anreicherungen überhaupt erlaubt. Systeme, die auf Ad-hoc-Abfragen ausgerichtet sind, bieten dies in der Regel nicht, da ihnen das eigentliche Data Warehouse und die Möglichkeit für programmierte Batch-Verarbeitung fehlen.

Access (Zugriff)

Die in einer BI-Lösung gespeicherten Informationen sind kein Selbstzweck, sondern müssen möglichst einfach und effizient weiterverarbeitet und genutzt werden können. Der Zugriff hängt dabei maßgeblich von den verwendeten Technologien ab. Während klassische SQL-Datenbanken mit weit verbreiteten Tools und Sprachen abgefragt werden können, ist dies bei NoSQL-Datenbanken oder Big Data-Technologien wie Hadoop nicht unbedingt der Fall. Ein weiterer Aspekt ist die Speicherung der Daten: Liegen diese „on premise“ auf einem eigenen Server, der über das eigene Netzwerk erreicht werden kann, oder irgendwo in der Cloud? Wenn letzteres: Wie sind Zugriffe und Abfragen auf den Daten organisiert? Gibt es Begrenzungen bzgl. Abfragengröße und Rechenzeit? Hier entscheidet sich, auf welche Weise Ihre Mitarbeiter komplexe Analysen durchführen können.

Visualization (Visualisierung)

Häufig mit BI gleichgesetzt wird die Visualisierungsschicht, die in der Regel der zentrale Berührungspunkt der Benutzer mit dem System ist. Hier geht es darum, aus den Daten Sinn zu machen und die wichtigen Informationen verständlich darzustellen. Da es hier zahllose Tools gibt, die sich ausschließlich auf diesen Aspekt fokussieren und auf bestehende BI-Architekturen aufgesetzt werden können, es gleichzeitig stark auf den individuellen Geschmack ankommt, halte ich den Punkt bewusst kurz. Wichtig ist, dass das Visualisierungswerkzeug zum darunter liegenden Technologie-Stack passt. Je weniger ausgeprägt meine BI-Architektur ist, desto mehr muss das Visualisierungstool können, z.B. die Zusammenführung von Daten, die Generierung von komplexen Abfragen oder die Definition von berechneten Kennzahlen. Idealerweise ist diese Logik-Schicht in der Architektur aber abgetrennt (s. „Linking“, „Structuring“ und „Enrichment“) und die Visualisierungsschicht kann „dumm“ sein und sich voll auf die Darstellung konzentrieren.

Communication (Kommunikation)

Eine immer wichtigere Aufgabe von BI ist es, auch die Kommunikation von Analyseergebnissen innerhalb der Organisation und den Austausch darüber zwischen den Mitarbeitern zu ermöglichen. Das Erzeugen von statischen Reports per PDF und Versenden per E-Mail ist die einfachste und antiquierteste Form davon. Web-basierte Plattformen ermöglichen heute den einfachen Austausch von Analysen und Dashboards innerhalb des Unternehmens, sodass jeder Benutzer jederzeit den aktuellen Stand der Geschäftsentwicklung sieht, interaktiv ins Detail einsteigen und die Sicht auf die Daten an die eigenen Bedürfnisse anpassen kann.

Darüber hinaus bieten moderne BI-Plattformen Werkzeuge wie Kommentarfunktionen, Foren, Chats und Newsfeeds für die Kommunikation über die Analyseergebnisse, sodass alle relevanten Informationen innerhalb eines Systems bleiben. Während dies sicherlich selten ein Muss-Kriterium bei der Anschaffung einer Software ist, lohnt es sich doch, die positive Wirkung auf die Akzeptanz und Verbreitung der Lösung in der Organisation in die Überlegungen einzubeziehen.

Interpretation

Eine Analyse durchzuführen ist eine Sache. Zu verstehen, was das Ergebnis bedeutet und daraus die richtigen Schlüsse zu ziehen, eine ganz andere. Häufig braucht es dafür geschulte Mitarbeiter mit jahrelanger Erfahrung. Da BI jedoch immer mehr zur „Commodity“ wird und viele kleine Unternehmen ohne ein Heer von Analysten das Ziel ausgeben, datengetrieben arbeiten zu wollen, wird die automatisierte, maschinelle Interpretation von Daten immer wichtiger. Dabei geht es in erster Linie darum, einen Kontext zur Verfügung zu stellen, z.B. Vergangenheitsdaten, eine Planung oder Hochrechnung, in dem eine Entwicklung als positiv oder negativ eingestuft werden kann. Im nächsten Schritt müssen die Treiber dieser Entwicklung identifiziert und ggf. die Gründe ausfindig gemacht werden. Im Idealfall präsentiert das System dem Nutzer bereits nach dem Login eine Übersicht über den akuten Handlungsbedarf.

Eine solche systemseitige Interpretation ist deshalb schwer umzusetzen, weil sie eine genaue inhaltliche Kenntnis der ausgewerteten Informationen erfordert. Ein generisches BI-Tool, das Daten lediglich verarbeitet und anzeigt, aber nicht versteht, kann dies nicht leisten. Hier ist dann die BI-Abteilung oder der Implementierungspartner gefordert, entsprechende Reports zu entwickeln. Spezialisierte Branchenlösungen sind im Vorteil, weil der Anbieter genau weiß, für welchen Zweck die Software eingesetzt wird und die wichtigsten Anwendungsfälle „vordenken“ kann.

Discovery (Entdeckung)

Zur Interpretation von Daten ist die Kenntnis ihrer Struktur und des zu lösenden Problems erforderlich. Wenn die Daten unstrukturiert und das Problem unbekannt sind, wenn also das zu erwartende Ergebnis ebenfalls unvorhersehbar ist, dann bewegen wir uns im Bereich des Data Mining, oder, wie es im Zeitalter von Big Data häufig genannt wird, der Data Science. Dies ist in der Regel eine weitere Anwendung auf dem bereits bestehenden Datenbestand und nicht unbedingt Teil der Kern-BI-Lösung, da hier gänzlich andere Tools, Methoden und auch Mitarbeiterkompetenzen benötigt werden. Dabei wird in den Daten nach Trends, Mustern und Korrelationen gesucht. Bei der Anschaffung einer BI-Lösung sollte zumindest schon einmal geklärt werden, ob Data Mining später genutzt werden soll und welche Tools mit der angeschafften Software kompatibel sind.

Recommendation (Empfehlung)

Ob nun Daten im Hinblick auf ein bekanntes Problem untersucht und interpretiert oder mit Data Mining neue Erkenntnisse gewonnen werden, das Ziel ist immer eine Handlungsempfehlung für die Organisation. Automatisiert und maschinell eine Handlungsempfehlung zu geben, ist die Königsdisziplin für jede Software, und dies kann nur entweder durch Fleiß, nämlich das Vordenken aller möglichen Fälle, oder durch eine echte semantische Engine erreicht werden. Weil es fast unbegrenzte Möglichkeiten und Themenfelder gibt, für die Handlungsempfehlungen gegeben werden können, hat sich eine Vielzahl von spezialisierten Tools für alle möglichen Fälle entwickelt, die auf eine bestehende BI-Lösung aufgesetzt werden können. Auch dieser Aspekt der Wertschöpfungskette wird somit von den meisten klassischen BI-Anbietern nicht mehr abgedeckt, sondern muss durch Speziallösungen zugekauft werden. Bei der Anschaffung ist insofern auf zukünftige Anforderungen und Kompatibilität zu achten.

Action (Aktion)

Wenn Daten analysiert und interpretiert sind und eine Handlungsempfehlung vorliegt, ist der letzte Schritt die Rückführung in die operativen Prozesse. Dies setzt eine ausgehende Schnittstelle in Richtung der zentralen Steuerungssysteme, z.B. ERP/Warenwirtschaft, E-Mail-Marketing-Tool, Bid Management / Ad Server etc. voraus, die die von der BI aufbereiteten Daten entgegen nehmen und weiterverarbeiten können. So liefert die BI die Empfehlung für einen Reaktivierungs-Newsletter an bestimmte Empfänger, für ein Invest in eine bestimmte Marketing-Kampagne oder die Nachbeschaffung eines bestimmten Produkts.

Da die anzubindenden Systeme auf beiden Seiten vielfältig sind, sind die meisten Anbieter von z.B. E-Mail-Marketing-Tools dazu übergegangen, statt konkreter Handlungsempfehlungen nur Rohdaten von der BI entgegen zu nehmen und daraus eigene Ableitungen zu treffen. Marketing-Automatisierung ist jedoch ein immer weiter wachsendes Thema mit zahlreichen Akteuren. Wichtig ist, bei der Anschaffung zu bedenken, dass Marketing-Automatisierungs-Tools häufig zwar die zur Erfüllung ihrer Aufgaben notwendigen Daten importieren und analysieren, aber eben keine vollständige BI sind im Hinblick auf Vollständigkeit der Daten, Zugriffs- und Analysemöglichkeiten. Eine richtige BI-Lösung wird meistens trotzdem benötigt, sodass zwischen den beiden Systemen eine möglichst effiziente Aufgabenteilung stattfinden sollte.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s