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 Tätigkeiten 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 über ein ERP-System verfügt.

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, erhielt 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 wurden und in der Regel auf frühen ERP-Lösungen basierten. 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 gesammelten Daten konzentrierte.

Die relationalen Datenbanksysteme, wie sie typischerweise in den 1980er Jahren verkauft wurden, wiesen jedoch zwei wesentliche Einschränkungen hinsichtlich der Erstellung analytischer Berichte 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 ³, den Business Intelligence-Lösungen. Die Kosten für RAM (Random Access Memory) waren kontinuierlich gesunken, während die Speicherkapazität kontinuierlich gestiegen war. Dadurch wurde es möglich, eine spezialisierte, kompaktere Version der Geschäftsdaten im Speicher (im RAM) für den sofortigen Zugriff zu speichern, sowohl aus technologischer als auch aus wirtschaftlicher Sicht. Diese Entwicklungen adressierten die beiden Hauptbeschränkungen der Berichtssysteme, 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 Fortschritt 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, das noch zugänglichere Web-Benutzeroberflächen lieferte - hauptsächlich SaaS (Software-as-a-Service) - und zunehmend interaktive Dashboards mit der Vielseitigkeit des relationalen Backends.

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 Lesen des gesamten Datensatzes 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. Dadurch muss das BI-System beim Abrufen eines frischen Berichts 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. Wenn die Datenstruktur klein genug ist, kann sie sogar 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 Datensätze (jeder gescannte Barcode in jedem Geschäft für diesen Zeitraum) und mehr als 50 GB im rohen tabellarischen Format. Eine Tabelle mit 100 Spalten (eine 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 den Schnittpunkten 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 wurde 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 Durchschnittsberechnung), 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 Verbreitung 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 spezialisierte Abfragesprachen (wie SQL) verwendet 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 entwickelt, um mit relationalen Datenbanken zu interagieren, 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 Sekunden ausführen konnte - 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, vernachlässigbar sind.

Die organisatorischen Auswirkungen von BI

Während die Zugänglichkeit ein entscheidender Faktor für die Verbreitung 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 der Einführung von BI-Tools führte dies bei 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 erweitern, unabhängig von den Vorteilen (wahrgenommen oder tatsächlich) für das Unternehmen durch den Zugriff auf diese Berichte.

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 von BI einzuführen, aber solche “fortgeschrittenen” Funktionen widersprechen ⁷ 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 die Datenbank sicherlich modifizieren und verbessern, um dieses Problem zu beheben. Aber auch hier widerspricht diese Lösung 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 geht die Information “zusammen gekauft” 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 transformierend, als es zunächst erscheinen mag. Einfach ausgedrückt hat die Produktion von Zahlen an sich keinen Wert für das Unternehmen, wenn keine Maßnahmen an diese Zahlen geknüpft sind. Das Design von 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: Sie betont keinen Handlungsaufruf für das Unternehmen. Das BI-Paradigma zielt nicht darauf ab, 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, genauer gesagt auf diejenigen, 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