Business Intelligence (BI)

BI (Business Intelligence) bezieht sich auf eine Klasse von Unternehmenssoftware, die sich auf die Erstellung von analytischen Berichten basiert, die hauptsächlich auf den Transaktionsdaten basieren, die durch die verschiedenen Geschäftssysteme gesammelt werden, die das Unternehmen zur Durchführung seiner Aktivitäten verwendet. BI soll Benutzern, die keine IT-Spezialisten sind, selbstbedienende Berichtsfunktionen bieten. Diese selbstbedienenden Funktionen können von der Anpassung von Parametern in vorhandenen Berichten bis zur Erstellung völlig neuer Berichte reichen. Die meisten großen Unternehmen haben mindestens ein BI-System im Einsatz, das häufig neben ihren Transaktionssystemen, einschließlich eines ERP-Systems, verwendet wird.

Ursprung und Motivation

Der moderne analytische Bericht entstand mit den ersten Wirtschaftsprognostikern^{1 2}, hauptsächlich in den USA, zu Beginn des 20. Jahrhunderts. Diese frühe Version erwies sich als äußerst beliebt und erhielt viel Aufmerksamkeit in der Mainstream-Presse und wurde weit verbreitet. Diese Beliebtheit zeigte, dass ein ausgeprägtes Interesse an quantitativen Berichten mit hoher Informationsdichte bestand. In den 1980er Jahren begannen viele große Unternehmen, ihre Geschäftstransaktionen als elektronische Aufzeichnungen zu speichern, die in Transaktionsdatenbanken abgelegt waren und in der Regel einige frühe ERP-Lösungen nutzten. Diese ERP-Lösungen waren hauptsächlich darauf ausgelegt, bestehende Prozesse zu optimieren und die Produktivität und Zuverlässigkeit zu verbessern. Viele erkannten jedoch das enorme ungenutzte Potenzial dieser Aufzeichnungen und SAP führte 1983 die ABAP-Programmiersprache ein, die sich auf die Generierung von Berichten basierend auf den in ERP selbst gesammelten Daten konzentrierte³.

Die relationalen Datenbanksysteme, wie sie typischerweise in den 1980er Jahren verkauft wurden, wiesen jedoch zwei wesentliche Einschränkungen in Bezug auf die Erstellung von analytischen Berichten auf. Erstens musste das Design der Berichte von hochqualifizierten IT-Spezialisten durchgeführt werden. Dies machte den Prozess langsam und teuer und beschränkte die Vielfalt der Berichte, die eingeführt werden konnten, erheblich. Zweitens war die Erstellung der Berichte sehr belastend für die Computertechnik. Berichte konnten in der Regel nur nachts (und im Batch) erstellt werden, wenn der Geschäftsbetrieb eingestellt war. Dies spiegelte zum Teil die Einschränkungen der Computertechnik der damaligen Zeit wider, aber es spiegelte auch die Software-Einschränkungen wider.

Anfang der 1990er Jahre ermöglichte der Fortschritt der Computertechnik die Entstehung einer anderen Klasse von Softwarelösungen ⁴, Business Intelligence-Lösungen. Die Kosten für RAM (Random Access Memory) waren kontinuierlich gesunken, während seine Speicherkapazität kontinuierlich gestiegen war. Dadurch wurde die Speicherung einer spezialisierten, kompakteren Version von Geschäftsdaten im Speicher (im RAM) zur sofortigen Nutzung sowohl aus technologischer als auch aus wirtschaftlicher Sicht zu einer realisierbaren Lösung. Diese Entwicklungen adressierten die beiden Hauptbeschränkungen von Berichtssystemen, wie sie vor einem Jahrzehnt implementiert wurden: Die neueren Software-Frontends waren für Nicht-Spezialisten viel zugänglicher, und die neueren Software-Backends - mit OLAP-Technologien (unten diskutiert) - beseitigten einige der größten IT-Beschränkungen. Dank dieser Fortschritte waren BI-Lösungen bis zum Ende des Jahrzehnts bei großen Unternehmen weit verbreitet.

Mit dem Fortschreiten der Computertechnik entstand in den späten 2000er Jahren eine neue Generation von BI-Tools ⁵. Die relationalen Datenbanksysteme der 1980er Jahre, die nicht in der Lage waren, Berichte bequem zu erstellen, konnten in den 2000er Jahren zunehmend die gesamte Transaktionshistorie eines Unternehmens im RAM speichern. Dadurch konnten komplexe analytische Abfragen innerhalb von Sekunden ohne ein dediziertes OLAP-Backend abgeschlossen werden. Der Fokus der BI-Lösungen verlagerte sich daher auf das Frontend und lieferte noch zugänglichere Web-Benutzeroberflächen - hauptsächlich SaaS (Software-as-a-Service) - und immer interaktivere Dashboards, die die Vielseitigkeit des relationalen Backends nutzten.

OLAP und mehrdimensionale Würfel

OLAP steht für Online Analytical Processing. OLAP ist mit dem Design des Backends einer BI-Lösung verbunden. Der Begriff, geprägt von Edgar Codd im Jahr 1993, vereint eine Reihe von Software-Design-Ideen ⁶, von denen die meisten bereits vor den 1990er Jahren existierten und einige bis in die 1960er Jahre zurückreichen. Diese Design-Ideen waren entscheidend für das Aufkommen von BI als eigenständige Klasse von Softwareprodukten in den 1990er Jahren. OLAP adressierte die Herausforderung, frische analytische Berichte zeitnah erstellen zu können, auch wenn die Menge an Daten, die für die Erstellung des Berichts verwendet werden, zu groß war, um schnell verarbeitet zu werden.

Die einfachste Technik zur Erstellung eines frischen analytischen Berichts besteht darin, die Daten mindestens einmal zu lesen. Wenn jedoch der Datensatz so groß ist ⁷, dass das vollständige Lesen Stunden (wenn nicht Tage) dauert, erfordert auch die Erstellung eines frischen Berichts Stunden oder Tage. Um einen aktualisierten Bericht in Sekundenschnelle zu erstellen, darf die Technik daher nicht das erneute Lesen des gesamten Datensatzes bei jeder Aktualisierung des Berichts beinhalten.

OLAP schlägt vor, kleinere, kompaktere Datenstrukturen zu nutzen, die den interessierenden Berichten entsprechen. Diese spezifischen Datenstrukturen sollen inkrementell aktualisiert werden, wenn neue Daten verfügbar werden. Wenn also ein frischer Bericht angefordert wird, muss das BI-System nicht den gesamten historischen Datensatz erneut lesen, sondern nur die kompakte Datenstruktur, die alle Informationen enthält, die für die Generierung des Berichts benötigt werden. Darüber hinaus kann die Datenstruktur, wenn sie klein genug ist, im Speicher (im RAM) gehalten und somit schneller als der persistente Speicher für Transaktionsdaten abgerufen werden.

Betrachten wir das folgende Beispiel: Stellen Sie sich ein Einzelhandelsnetzwerk mit 100 Hypermärkten vor. Der CFO möchte einen Bericht über den Gesamtumsatz in Euro pro Geschäft und Tag der letzten 3 Jahre. Die rohen historischen Verkaufsdaten der letzten 3 Jahre umfassen mehr als 1 Milliarde Zeilen Daten (jeder gescannte Barcode in jedem Geschäft für diesen Zeitraum) und mehr als 50 GB in ihrem rohen tabellarischen Format. Eine Tabelle mit 100 Spalten (1 pro Hypermarkt) und 1095 Zeilen (3 Jahre * 365 Tage) umfasst jedoch weniger als 0,5 MB (bei einer Rate von 4 Bytes pro Zahl). Darüber hinaus können die entsprechenden Zellen in der Tabelle bei jeder Transaktion entsprechend aktualisiert werden. Die Erstellung und Pflege einer solchen Tabelle veranschaulicht, wie ein OLAP-System unter der Oberfläche aussieht.

Die oben beschriebenen kompakten Datenstrukturen nehmen in der Regel die Form eines OLAP-Würfels an, auch als mehrdimensionaler Würfel bezeichnet. Zellen existieren im Würfel an der Schnittstelle der diskreten Dimensionen, die die Gesamtstruktur des Würfels definieren. Jede Zelle enthält eine Maßnahme (oder einen Wert), der aus den ursprünglichen Transaktionsdaten extrahiert wird und häufig als Faktentabelle bezeichnet wird. Diese Datenstruktur ähnelt den mehrdimensionalen Arrays, die in den meisten gängigen Programmiersprachen zu finden sind. Der OLAP-Würfel eignet sich für effiziente Projektions- oder Aggregationsoperationen entlang der Dimensionen (wie Summieren und Durchschnittsbildung), solange der Würfel klein genug ist, um in den Speicher des Computers zu passen.

Interaktive Berichterstellung und Datenvisualisierung

Die Bereitstellung von Berichtsfunktionen für Endbenutzer, die keine IT-Spezialisten sind, war ein wesentlicher Treiber für die Nutzung von BI-Tools. Aus diesem Grund wurde eine WYSIWYG-Designmethode (what-you-see-is-what-you-get) verwendet, die auf benutzerfreundlichen Oberflächen basiert. Dieser Ansatz unterscheidet sich von der üblichen Methode zur Interaktion mit einer relationalen Datenbank, bei der Abfragen mithilfe einer spezialisierten Sprache (wie SQL) erstellt werden. Die übliche Schnittstelle zur Manipulation eines OLAP-Würfels ist eine Matrix-Schnittstelle, ähnlich wie Pivot-Tabellen in einem Tabellenkalkulationsprogramm, die es Benutzern ermöglicht, Filter anzuwenden (im BI-Jargon als slice and dice bezeichnet) und Aggregationen durchzuführen (Durchschnitt, Minimum, Maximum, Summe usw.).

Mit Ausnahme der Verarbeitung besonders großer Datensätze nahm der Bedarf an OLAP-Würfeln in den späten 2000er Jahren parallel zu den großen Fortschritten in der Computertechnologie ab. Neuere “dünne” BI-Tools wurden eingeführt, die sich ausschließlich auf die Benutzeroberfläche konzentrierten. Die schlanken BI-Tools wurden hauptsächlich für die Interaktion mit relationalen Datenbanken entwickelt, im Gegensatz zu ihren “dicken” Vorgängern, die integrierte Backends mit OLAP-Würfeln nutzten. Diese Entwicklung war möglich, weil die Leistungsfähigkeit relationaler Datenbanken zu dieser Zeit in der Regel komplexe Abfragen über den gesamten Datensatz in Sekundenschnelle ermöglichte - vorausgesetzt, der Datensatz blieb unter einer bestimmten Größe. Dünne BI-Tools können als vereinheitlichte WYSIWYG-Editoren für die verschiedenen SQL-Dialekte angesehen werden, die sie unterstützten. (Tatsächlich generieren diese BI-Tools unter der Haube SQL-Abfragen.) Die Haupttechnische Herausforderung bestand darin, die generierten Abfragen zu optimieren, um die Reaktionszeit der zugrunde liegenden relationalen Datenbank zu minimieren.

Die Datenvisualisierungsfähigkeiten von BI-Tools waren größtenteils eine Frage der Datenpräsentation auf der Client-Seite, entweder über eine Desktop- oder Webanwendung. Die Präsentationsfähigkeiten entwickelten sich stetig weiter, bis in die 2000er Jahre, als die Hardware der Endbenutzer (z. B. Workstations und Notebooks) im Hinblick auf die Rechenleistung weit über das hinausging, was für die Datenvisualisierung erforderlich war. Heutzutage sind selbst die aufwendigsten Datenvisualisierungen unkomplizierte Prozesse, die im Vergleich zur Verarbeitung und Transformation der zugrunde liegenden Daten, die visualisiert werden, kaum Rechenressourcen beanspruchen.

Die organisatorischen Auswirkungen von BI

Während die Zugänglichkeit ein entscheidender Faktor für die Nutzung der meisten BI-Tools war, ist die Navigation durch die Datenlandschaft großer Unternehmen schwierig, nicht zuletzt aufgrund der enormen Vielfalt der verfügbaren Daten. Darüber hinaus spiegelt die Berichtslogik, die Unternehmen über BI-Tools implementieren, in der Regel die Komplexität des Geschäfts wider, und als Ergebnis kann die Logik selbst viel weniger zugänglich sein als das Tool, das ihre Ausführung unterstützt.

Als Ergebnis führte die Nutzung von BI-Tools - zumindest in den meisten großen Unternehmen - zur Schaffung dedizierter Analyseteams, die in der Regel als Supportfunktion neben der IT-Abteilung tätig sind. Wie von Parkinsons Gesetz vorhergesagt, dehnt sich die Arbeit aus, um die verfügbare Zeit für ihre Fertigstellung auszufüllen; diese Teams neigen dazu, sich im Laufe der Zeit zusammen mit der Anzahl der generierten Berichte zu vergrößern, unabhängig von den Vorteilen (wahrgenommen oder tatsächlich) für das Unternehmen durch den Zugang zu diesen Berichten.

Technische Grenzen von BI

Wie so oft gibt es bei BI-Tools einen Kompromiss zwischen Vorzügen, was bedeutet, dass eine größere Zugänglichkeit mit einem Verlust an Ausdruckskraft einhergeht. In diesem Fall sind die auf die Daten angewendeten Transformationen auf eine relativ begrenzte Klasse von Filtern und Aggregationen beschränkt. Dies ist die erste große Einschränkung, da viele - wenn nicht die meisten - Geschäftsfragen mit diesen Operatoren nicht beantwortet werden können (zum Beispiel Was ist das Kundenabwanderungsrisiko?). Natürlich ist es möglich, erweiterte Operatoren in die Benutzeroberfläche des BI-Tools einzuführen, jedoch widersprechen solche “fortgeschrittenen” Funktionen dem ursprünglichen Zweck, das Tool für nicht-technische Benutzer leicht zugänglich zu machen. Das Entwerfen von erweiterten Datenabfragen ist daher nicht anders als das Erstellen von Software, eine Aufgabe, die von Natur aus schwierig ist. Als belegende Anekdote bieten die meisten BI-Tools die Möglichkeit, “rohe” Abfragen zu schreiben (in der Regel in SQL oder einem SQL-ähnlichen Dialekt), was auf den technischen Pfad zurückführt, den das Tool eigentlich beseitigen sollte.

Die zweite große Einschränkung ist die Leistung. Diese Einschränkung tritt bei dünnen und dicken BI-Tools in zwei unterschiedlichen Ausprägungen auf. Dünne BI-Tools enthalten in der Regel eine ausgeklügelte Logik zur Optimierung der von ihnen generierten Datenbankabfragen. Diese Tools sind jedoch letztendlich durch die Leistung begrenzt, die von der als Backend dienenden Datenbank angeboten werden kann. Eine scheinbar einfache Abfrage kann sich als ineffizient in der Ausführung erweisen und zu langen Antwortzeiten führen. Ein Datenbankingenieur kann sicherlich die Datenbank modifizieren und verbessern, um dieses Problem zu beheben. Diese Lösung widerspricht jedoch erneut dem ursprünglichen Ziel, das BI-Tool für nicht-technische Benutzer zugänglich zu halten.

Dicke BI-Tools haben ihre Leistung durch das Design der OLAP-Würfel selbst begrenzt. Erstens steigt der RAM-Bedarf rapide an, um einen multidimensionalen Würfel im Speicher zu halten, wenn die Dimensionen des Würfels zunehmen. Selbst eine moderate Anzahl von Dimensionen (z. B. 10) kann zu schwerwiegenden Problemen im Zusammenhang mit dem Speicherplatzbedarf des Würfels führen. Im Allgemeinen leiden In-Memory-Designs (wobei OLAP-Würfel am häufigsten vorkommen) häufig unter speicherbezogenen Problemen.

Darüber hinaus ist der Würfel eine verlustbehaftete Darstellung der ursprünglichen Transaktionsdaten: Keine Analyse, die mit dem Würfel durchgeführt wird, kann Informationen wiederherstellen, die bereits verloren gegangen sind. Denken Sie an das Beispiel des Hypermarkts. In einem solchen Szenario können Körbe nicht in einem Würfel dargestellt werden. Daher gehen die Informationen über “zusammen gekaufte” Artikel verloren. Das gesamte “Würfel”-Design von OLAP beschränkt stark, welche Daten überhaupt dargestellt werden können. Diese Einschränkung ist jedoch genau das, was die “Online”-Eigenschaft überhaupt erst möglich macht.

Geschäftliche Grenzen von BI

Die Einführung von BI-Tools in einem Unternehmen ist weniger transformative, als es zunächst erscheinen mag. Einfach ausgedrückt, die Produktion von Zahlen an sich hat für das Unternehmen keinen Wert, wenn keine Maßnahmen an diese Zahlen geknüpft sind. Das Design der BI-Tools betont zwar eine “grenzenlose” Produktion von Berichten, unterstützt jedoch keinen tatsächlichen Handlungsbedarf. In den meisten Situationen erweist sich die geringe Ausdruckskraft der BI-Tools als zu einschränkend, wenn es darum geht, irgendetwas auf der Grundlage der BI-Berichte zu automatisieren.

Außerdem neigt das BI-Tool dazu, die bürokratischen Tendenzen großer Unternehmen zu verstärken. Anekdotische Beweise, grobe Zahlen und gesunder Menschenverstand sind oft ausreichend, um Prioritäten für ein Unternehmen festzulegen. Die Existenz eines selbstbezogenen Analysetools wie BI bietet jedoch reichlich Gelegenheit zum Aufschieben und zur Verwirrung mit einer endlosen Reihe fragwürdiger und nicht handlungsorientierter Kennzahlen.

BI-Tools sind anfällig für die Probleme der Entwurfsdurchführung durch Ausschüsse, bei denen die Ideen aller Beteiligten in das Projekt einfließen. Die selbstbezogene Natur des Tools betont einen umfassend inklusiven Ansatz bei der Einführung neuer Berichte. Als Ergebnis neigt die Komplexität der Berichtslandschaft dazu, im Laufe der Zeit zu wachsen, unabhängig von der Geschäftskomplexität, die diese Berichte widerspiegeln sollen. Der Begriff Vanity Metrics hat sich weit verbreitet, um Kennzahlen zu reflektieren - in der Regel implementiert durch ein BI-Tool - wie diese, die nicht zum Geschäftsergebnis eines Unternehmens beitragen.

Lokads Standpunkt

Angesichts der Möglichkeiten moderner Computerhardware ist es einfach, ein Berichtssystem zu verwenden, um 1 Million Zahlen pro Tag zu produzieren; 10 Zahlen pro Tag zu produzieren, die es wert sind, gelesen zu werden, ist jedoch schwierig. Während ein BI-Tool in kleinen Dosen für die meisten Unternehmen eine gute Sache ist, wird es in höheren Dosen zu einem Gift.

In der Praxis gibt es nur so viele Erkenntnisse, die aus BI gewonnen werden können. Die Einführung immer neuerer Berichte führt zu schnell abnehmenden Erträgen in Bezug auf neue (oder verbesserte) Erkenntnisse, die durch jeden zusätzlichen Bericht gewonnen werden. Denken Sie daran, dass die Tiefe der Datenanalyse, die von einem BI-Tool zugänglich ist, aus Designgründen begrenzt ist, da Abfragen über die Benutzeroberfläche für Nicht-Spezialisten leicht zugänglich bleiben müssen.

Außerdem bedeutet selbst dann, wenn eine neue Erkenntnis aus den Daten gewonnen wird, dies nicht, dass das Unternehmen daraus etwas Handlungsorientiertes machen kann. BI ist in seinem Kern eine Berichterstattungs-Technologie: Es betont keinen Aufruf zur Handlung für das Unternehmen. Das BI-Paradigma ist nicht darauf ausgerichtet, Geschäftsentscheidungen zu automatisieren (nicht einmal die banalen).

Die Funktionen der Lokad-Plattform umfassen umfangreiche maßgeschneiderte Berichtsfunktionen, wie BI. Im Gegensatz zu BI zielt Lokad jedoch auf die Optimierung von Geschäftsentscheidungen ab, insbesondere solche, die die Supply Chain betreffen. In der Praxis empfehlen wir, dass ein Supply Chain Scientist für die Gestaltung und spätere Wartung des numerischen Rezepts verantwortlich ist, das - über Lokad - die entscheidungsbasierten Optimierungen der Supply Chain generiert, die von Interesse sind.

Anmerkungen