Von Joannes Vermorel, Dezember 2022BI (Business Intelligence) bezieht sich auf eine Art Unternehmenssoftware zur Erstellung von Analyseberichten, die in erster Linie auf Transaktionsdaten beruhen, die über die verschiedenen Geschäftssysteme des Unternehmens gesammelt werden. BI bietet Nutzern ohne IT-Fachkenntnisse Berichtsfunktionen zur Selbstbedienung. Diese Funktionen können von der Anpassung von Parametern in bestehenden Berichten bis hin zur Erstellung völlig neuer Berichte reichen. Die meisten großen Unternehmen haben mindestens ein BI-System zusätzlich zu ihren Transaktionssystemen in Betrieb, die häufig auch ein ERP-System umfassen.
Ursprung und Begründung
Der moderne analytische Bericht kam mit den ersten Wirtschaftsprognostikern
[1] [2] vorrangig zu Beginn des 20. Jahrhunderts in den USA auf. Diese frühe Version erwies sich als äußerst populär. Sie wurde von der allgemeinen Presse aufgegriffen und war weit verbreitet. Dies deutete auf ein ausgeprägtes Interesse an quantitativen Berichten mit hoher Informationsdichte. In den 1980er Jahren begannen viele große Unternehmen, ihre Geschäftsvorgänge als elektronische Datensätze in transaktionale Datenbanken zu speichern, wobei sie in der Regel frühe
ERP-Lösungen einsetzten. Diese ERP-Lösungen waren in erster Linie dazu gedacht, bestehende Prozesse zu rationalisieren sowie die Produktivität und Zuverlässigkeit zu steigern. Viele erkannten jedoch das enorme ungenutzte Potenzial dieser Datensätze. So führte SAP 1983 die Programmiersprache ABAP
[3] ein, die der Erstellung von Berichten auf Grundlage der im ERP-System erfassten Daten gewidmet war.
Die relationalen Datenbanksysteme, wie sie in den 1980er Jahren gewöhnlich zu finden waren, wiesen jedoch zwei wesentliche Einschränkungen auf, was die Erstellung von analytischen Berichten betraf. Erstens mussten die Berichte von hochqualifizierten IT-Spezialisten gestaltet werden. Dies verlangsamte und verteuerte den Prozess und schränkte zudem die Vielfalt der Berichte, die eingeführt werden konnten, stark ein. Zweitens war die Erstellung der Berichte für die Hardware sehr fordernd. Berichte konnten in der Regel nur nachts (und in Stapeln) nach Dienstschluss erstellt werden. Dies spiegelt gewissermaßen die Einschränkungen der damaligen Hardware wider, aber auch die Einschränkungen der
Software.
Durch den Fortschritt im Bereich Hardware wurde in den frühen 1990er eine andere Art von Softwarelösungen
[4] möglich, nämlich
Business Intelligence- Lösungen. Die Kosten für RAM (Random-Access-Memory) waren stetig
zurückgegangen, während die Speicherkapazität kontinuierlich
stieg. Somit wurde die Speicherung einer speziellen, kompakteren Version von Geschäftsdaten
im Speicher (im RAM) für den sofortigen Zugriff sowohl aus technischer als auch aus wirtschaftlicher Sicht umsetzbar. Mit diesen Entwicklungen konnte die zwei wichtigsten Einschränkungen der Berichtssysteme aus dem vorangegangenen Jahrzehnt aus dem Weg geräumt werden. Die neueren Frontends der Software waren für Laien viel zugänglicher und mit den neueren Backends – mit OLAP-Technologien (s. unten) – konnte einige der größten IT-Einschränkungen überwunden werden. Dank dieser Fortschritte hatten sich BI-Lösungen gegen Ende der 1990er bei großen Unternehmen durchgesetzt.
Die weiteren Entwicklungen im Bereich der Computer-Hardware brachten in den späten 2000ern eine neue Generation von BI-Tools
[5] hervor. Die relationalen Datenbanksysteme der 1980er Jahre, die nicht in der Lage waren, Berichte auf eine praktische Art und Weise zu erstellen, waren in den 2000er Jahren zunehmend im Stande, die gesamte Transaktionshistorie eines Unternehmens im RAM zu speichern. Infolgedessen konnten komplexe analytische Abfragen innerhalb von Sekunden
ohne ein spezielles OLAP-Backend durchgeführt werden. So verlagerte sich der Schwerpunkt der BI-Lösungen auf das Frontend. Sie boten noch leichter zugängliche Web-Benutzeroberflächen – überwiegend als SaaS (Software-as-a-Service) – und verfügten über zunehmend interaktive Dashboards, die sich die Vielseitigkeit des relationalen Backends zu Nutze machten.
OLAP und mehrdimensionale Würfel
OLAP steht für
online analytical processing und hängt mit der Gestaltung des
Back-Ends einer BI-Lösung zusammen. Dieser von Edgar Codd 1993 geprägte Begriff fasst eine Reihe von Ideen zum Softwaredesign
[6] zusammen – viele von ihnen von vor den 1990ern und einige sogar aus den 1960ern. Diese Design-Ideen trugen in den 1990ern maßgeblich dazu bei, dass sich BI zu einer eigenen Klasse von Softwareprodukten entwickelte. Mit OLAP konnte die Herausforderung, neue analytische Berichte
zeitnahe zu erstellen, überwunden werden, auch wenn die Datenmenge zur Erstellung des Berichts für eine schnelle Verarbeitung zu groß war.
Die einfachste Technik zur Erstellung eines neuen Analyseberichts besteht darin,
die Daten mindestens einmal zu lesen. Ist der Datensatz jedoch so groß
[7], dass das Lesen des gesamten Datensatzes Stunden (wenn nicht sogar Tage) dauert, nimmt auch die Erstellung eines neuen Berichts Stunden oder Tage in Anspruch. So darf die Technik zur Erstellung eines aktualisierten Berichts in Sekundenschnelle nicht ein erneutes Lesen des gesamten Datensatzes bei jeder Anforderung eines neuen Berichts umfassen.
OLAP bietet an, kleinere, kompaktere Datenstrukturen zu nutzen, welche die gewünschten Berichte widerspiegeln. Dabei werden diese spezifischen Datenstrukturen nach und nach aktualisiert, wenn neuere Daten verfügbar werden. So muss das BI-System nicht den gesamten historischen Datensatz erneut lesen, wenn ein neuer Bericht angefordert wird. Es reicht aus, nur die kompakte Datenstruktur, die alle für die Erstellung des Berichts erforderlichen Informationen enthält, zu lesen. Außerdem kann die Datenstruktur, wenn sie klein genug ist, im Speicher (im RAM) gehalten werden, so dass der Zugriff schneller erfolgt als auf den für Transaktionsdaten verwendeten dauerhaften Speicher.
Gehen wir vom Beispiel eines Einzelhandelsnetzes aus, das 100 Großflächenmärkte betreibt. Der CFO möchte einen Bericht über den Gesamtumsatz in Euro pro Geschäft und Tag für die letzten 3 Jahre. Die rohen historischen Verkaufsdaten der letzten 3 Jahre umfassen über 1 Milliarde Zeilen an Daten (jeder Barcode, der in diesem Zeitraum in jedem Geschäft gescannt wurde) und mehr als 50 GB in ihrem rohen Tabellenformat. Eine Tabelle mit 100 Spalten (1 pro Großflächenmarkt) und 1095 Zeilen (3 Jahre * 365 Tage) macht jedoch weniger als 0,5 MB aus (zu 4 Byte pro Zahl). Außerdem können die entsprechenden Zellen in der Tabelle jedes Mal, wenn eine Transaktion stattfindet, entsprechend aktualisiert werden. Die Erstellung und Pflege einer solchen Tabelle veranschaulicht, wie ein OLAP-System im Kern funktioniert.
Die oben beschriebenen kompakten Datenstrukturen nehmen gewöhnlich die Form eines
OLAP-Würfels, auch mehrdimensionaler Würfel genannt, an. Die Zellen befinden sich im Würfel am Schnittpunkt der diskreten Dimensionen, welche die Gesamtstruktur des Würfels definieren. Jede Zelle enthält eine Größe (oder einen Wert), die bzw. der aus den ursprünglichen Transaktionsdaten – häufig als
Faktentabelle bezeichnet – extrahiert wurde. Diese Datenstruktur ähnelt den mehrdimensionalen Arrays, die in den meisten gängigen Programmiersprachen zu finden sind. Der OLAP-Würfel eignet sich für eine effiziente Projektion oder Aggregation entlang der Dimensionen (wie etwa Summen und Mittelwertbildung), sofern er klein genug bleibt, um in den Speicher des Computers zu passen.
Interaktive Berichterstattung und Datenvisualisierung
Berichtsfunktionen für Endbenutzer ohne IT-Fachkenntnisse zur Verfügung zu stellen, war einer der Hauptantreiber für die Einführung von BI-Tools. Daher wurde für die Technologie ein WYSIWYG-Design (
what-you-see-is-what-you-get) gewählt, das auf umfangreiche Benutzeroberflächen basiert. Dieser Ansatz unterscheidet sich von der üblichen Vorgehensweise, nämlich die Interaktion mit der relationalen Datenbank durch Abfragen, die in einer speziellen Sprache (wie SQL) zu erstellen sind. Die übliche Schnittstelle zur Bearbeitung eines OLAP-Würfels ist eine Matrixschnittstelle, wie etwa Pivot-Tabellen in einem Tabellenkalkulationsprogramm, dank denen Nutzer Filter anwenden (in der BI-Terminologie als
slice and dice bezeichnet) und Aggregationen (Durchschnitt, Minimum, Maximum, Summe usw.) durchzuführen können.
Außer für die Verarbeitung besonders großer Datenmengen ging der Bedarf an OLAP-Würfeln in den späten 2000ern parallel zu den großen Fortschritten im Bereich Hardware zurück. Es wurden neuere „schlanke“ BI-Tools eingeführt, die sich ausschließlich auf das Front-End konzentrieren. Diese schlanken BI-Tools wurden in erster Linie für die Interaktion mit relationalen Datenbanken entwickelt. Im Gegensatz dazu nutzen die „umfangreicheren“ Vorgänger hierfür integrierte Back-Ends mit OLAP-Würfeln. Diese Entwicklung wurde durch die Leistung relationaler Datenbanken möglich, die damals in der Regel komplexe Abfragen über den gesamten Datenbestand in Sekundenschnelle ausführen konnte, solange sich die Größe des Datenbestands in Grenzen hielt. Schlanke BI-Tools können als einheitliche WYSIWYG-Editoren für die verschiedenen unterstützten SQL-Dialekte betrachtet werden. (Tatsächlich erzeugen diese BI-Tools im Hintergrund SQL-Abfragen.) Die größte technische Herausforderung war die Optimierung der generierten Abfragen, um die Antwortzeit der zugrundeliegenden relationalen Datenbank zu minimieren.
Was die Funktionen zur
Datenvisualisierung von BI-Tools betraf, ging es eher um die kundenseitige Präsentation der Daten entweder über einen Desktop oder eine Webanwendung. Die Darstellungsmöglichkeiten entwickelten sich bis in die 2000er stetig weiter, als die Hardware der Endbenutzers (z. B. Workstations und Notebooks) die Anforderungen für die Datenvisualisierung (aus Sicht der Rechenressourcen) bei weitem übertraf. Heutzutage sind selbst die aufwändigsten Datenvisualisierungen wenig anspruchsvolle Prozesse, die im Vergleich zur Extraktion und Umwandlung der zugrundeliegenden Daten für die Visualisierung, sehr wenig Rechenleistung bedürfen.
Auswirkungen von BI in Unternehmen
Während der einfache Zugang ein entscheidender Faktor für die Einführung der meisten BI-Tools war, ist es in großen Unternehmen schwierig, einen Überblick über die gesamte Datenlandschaft zu behalten – nicht zuletzt wegen der unglaublichen Vielfalt an verfügbaren Daten. Selbst wenn ein BI-Tool einigermaßen zugänglich ist, spiegelt die Berichtslogik, die Unternehmen mit Hilfe von BI-Tools implementieren, in der Regel die Komplexität des Unternehmens wider. Folglich kann die Logik selbst deutlich schwieriger zugänglich sein kann als das Tool, mit dem sie ausgeführt wird.
Infolgedessen hatte die Einführung von BI-Tools in den meisten großen Unternehmen die Schaffung spezieller Analyseteams zur Folge, die in der Regel neben der IT eine unterstützende Funktion haben. Wie das Parkinsonsche Gesetz bereits vorsah,
dehnt sich Arbeit in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht. Tendenziell wachsen also im Laufe der Zeit diese Teams zusammen mit der Anzahl der erstellten Berichte, ganz unabhängig vom (wahrgenommenen oder tatsächlichen) Nutzen, den das Unternehmen aus diesen Berichten zieht.
Technische Grenzen von BI
Wie so oft gilt es auch bei BI-Tools, Kompromisse einzugehen. So geht ein leichterer Zugang zu Lasten der
Ausdrucksfähigkeit, sodass die Umwandlung der Daten auf eine relativ geringe Auswahl an Filtern und Aggregationen beschränkt ist. Dies ist die erste große Einschränkung, da viele – wenn nicht sogar die meisten – Geschäftsfragen mit diesen Operatoren nicht beantwortet werden können (z. B.
Wie hoch ist das Risiko, dass ein Kunde abwandert?). Natürlich ist es
möglich, fortgeschrittene Operatoren in BI-Benutzeroberflächen einzubauen. Solche „fortgeschrittenen“ Funktionen widersprechen jedoch dem ursprünglichen Ziel, nämlich dem einfachen Zugang auf das Tool durch Nutzer ohne technische Fachkenntnisse.
[8] Somit gleicht die Entwicklung fortgeschrittener Datenabfragen der Entwicklung von Software, eine Aufgabe, die von Natur aus schwierig ist. Interessanterweise bieten die meisten BI-Tools die Möglichkeit, „rohe“ Abfragen zu schreiben (in der Regel in SQL oder einem SQL-ähnlichen Dialekt). Damit greift man wieder auf die technische Alternative zurück, die mit dem Tool eigentlich vermieden werde sollte.
Die zweite große Einschränkung ist die
Leistung. Diese Einschränkung zeigt sich auf zwei verschiedene Arten bei schlanken bzw. umfangreichen BI-Tools. Die Logik zur Optimierung der von den schlanken BI-Tools generierten Datenbankabfragen ist gewöhnlich ziemlich ausgefeilt. Allerdings werden diese Tools letztlich durch die Leistung der zugrundeliegenden Datenbank eingeschränkt. Eine scheinbar einfache Abfrage kann sich bei der Ausführung als ineffizient erweisen und zu langen Antwortzeiten führen. Ein Datenbankentwickler kann die Datenbank sicherlich anpassen und verbessern, um dieses Problem zu lösen. Aber auch diese Option verfehlt das ursprüngliche Ziel, das BI-Tool für Nutzer ohne technische Fachkenntnisse zugänglich zu machen.
Die Leistung von umfangreichen BI-Tools wird durch das Design der OLAP-Würfel eingeschränkt. Erstens steigt die Menge an RAM, die für die Speicherung eines mehrdimensionalen Würfels erforderlich ist, rapide bei einer wachsenden Anzahl an Dimensionen im Würfel an. Selbst eine überschaubare Anzahl an Dimensionen (z. B. 10) kann zu schwerwiegenden Problemen im Zusammenhang mit dem Speicherbedarf des Würfels führen. Generell leiden In-Memory-Designs (von denen OLAP-Würfel die häufigsten Ausprägung sind) in der Regel unter speicherbezogenen Problemen.
Außerdem bietet der Würfel eine
verlustbehaftete Darstellung der ursprünglichen Transaktionsdaten. Denn keine mit dem Würfel durchgeführte Analyse kann Informationen wiederherstellen, die von vornherein verloren gegangen sind. Denken Sie an das Beispiel des Großflächenmarkts. In einem solchen Szenario können die Körbe nicht in einem Würfel dargestellt werden. Dadurch geht die Information zu Produkten, die „gemeinsam gekauft“ wurden, verloren. Das Design des OLAP-„Würfels“ schränkt die darstellbaren Daten stark ein. Doch genau diese Einschränkung macht die „Online-“Eigenschaft überhaupt erst möglich.
Grenzen von BI im Unternehmen
Die Einführung von BI-Tools in einem Unternehmen ist nicht so bahnbrechend, wie es klingen mag. Einfach gesagt, ist die Aufstellung von Zahlen an sich für das Unternehmen wertlos, wenn an diese keine Maßnahmen geknüpft werden. Schon das Design der BI-Tools setzt die „grenzenlose“ Bereitstellung von Berichten in den Fokus, es unterstützt jedoch keine konkrete Vorgehensweise. Tatsächlich erweist sich die geringe Ausdrucksfähigkeit der BI-Tools in den meisten Situationen als unzureichend, wenn man auf deren Grundlage BI-Berichte automatisieren möchte.
Außerdem neigt das BI-Tool dazu, die bürokratischen Tendenzen großer Unternehmen zu verstärken. Generell reichen Erfahrungswerte, grobe Zahlen und ein gesunder Menschenverstand oft aus, um die Prioritäten eines Unternehmens festzulegen. Eigennützigen Analysewerkzeuge, wie etwa BI, bieten jedoch reichlich Gelegenheit zur Prokrastination und zur Verwirrung durch fragwürdige und nicht umsetzbare Metriken.
BI-Tools sind anfällig für das
Design by Committee, bei dem die Ideen aller Beteiligten in das Projekt einfließen. Die Selbstbedienungsfunktion des Tools unterstreicht einen äußerst inklusiven Ansatz bei der Einführung neuer Berichte. Infolgedessen nimmt die Komplexität der Berichtslandschaft im Laufe der Zeit gewöhnlich zu – unabhängig von der Komplexität des Geschäfts, die diese Berichte widerspiegeln sollen. Der Begriff
Vanity Metrics ist weit verbreitet, um solche Kennzahlen zu bezeichnen, die in der Regel über ein BI-Tool eingeführt werden und keinen Beitrag zum Endergebnis eines Unternehmens leisten.
Lokads Ansatz
In Anbetracht der Fähigkeiten moderner Computer-Hardware ist es leicht, mit einem Berichtssystem 1 Million Zahlen täglich zu erzeugen. Schwierig hingegen ist 10 lesenswerte Zahlen pro Tag zu erzeugen. Während der Einsatz eines BI-Tools in kleinen Maße für die meisten Unternehmen positiv ist, wird es bei übermäßigem Einsatz schädlich.
In der Praxis lässt sich durch BI nur eine bestimmte Anzahl an Erkenntnissen gewinnen. Die Einführung immer weiterer Berichte führt dazu, dass mit jedem zusätzlichen Bericht die gewonnen neuen (oder verbesserten) Erkenntnisse zurückgehen. Man darf nicht vergessen, dass die Tiefe der Datenanalyse, die ein BI-Tool ermöglicht,
von vornherein begrenzt ist, da die Abfragen über die Benutzeroberfläche auch für Nutzer ohne Fachkenntnisse leicht zugänglich sein müssen.
Und selbst wenn die Daten neue Erkenntnisse liefern, heißt das noch lange nicht, dass das Unternehmen diese auch irgendwie umsetzen kann. BI ist im Kern eine
Reporting-Technologie und dreht sich nicht um bestimmte Handlungen. Das BI-Paradigma ist nicht auf die Automatisierung von Geschäftsentscheidungen (nicht einmal alltäglicher Entscheidungen) ausgerichtet.
Lokads Plattform verfügt über umfangreiche, maßgeschneiderte Berichtsfunktionen, wie BI. Im Gegensatz zu BI zielt Lokad jedoch auf die Optimierung von Geschäftsentscheidungen ab, konkret von Entscheidungen in Bezug zur Lieferkette. In der Praxis empfehlen wir, einen
Supply-Chain-Scientist mit dem Design und der späteren Pflege des numerischen Rezepts, das über Lokad die betreffenden Supply-Chain-Entscheidungen erzeugt, zu beauftragen.
Literaturhinweise
1. Fortune Tellers: The Story of America's First Economic Forecasters, von Walter Friedman (2013).
2. A Selection of Early Forecasting & Business Charts, von Walter Friedman (2014) (PDF)
3. ABAP ist eine von SAP 1983 herausgegebene Sprache und steht für Allgemeiner Berichtsaufbereitungsprozessor. Diese Sprache wurde als Vorläufer der BI-Systeme eingeführt, um das ERP (auch SAP genannt) mit einer Berichtsfunktion auszustatten. ABAP sollte den mit der Implementierung von benutzerdefinierten Berichten verbundenen technischen Mehraufwand verringern. In den 1990ern wurde ABAP zu einer Konfigurations- und Erweiterungssprache für das ERP selbst umfunktioniert. Zudem wurde die Sprache im Englischen in Advanced Business Application Programming umbenannt, um die Änderung des Schwerpunkts widerzuspiegeln.
4. BusinessObjects, das 1990 gegründet und 2008 von SAP übernommen wurde, ist das klassische Modell für BI-Lösungen aus den 1990ern.
5. Tableau, 2003 gegründet und 2019 von Salesforce übernommen, ist das klassische Modell für BI-Lösungen aus den 2000ern.
6. The origins of today’s OLAP products, Nigel Pendse, zuletzt aktualisiert im August 2007
7. Computer-Hardware hat sich seit den 1950er Jahren stets weiterentwickelt. Immer, wenn die Verarbeitung größerer Datenmengen billiger wurde, wurde auch die Speicherung größerer Datenmengen billiger. Infolgedessen ist die Menge an Geschäftsdaten seit den 1970er Jahren fast im gleichen Tempo wie die Leistungsfähigkeit der Hardware gewachsen. Somit ist die Idee von „zu vielen Daten“ ein bewegliches Ziel.
8. In den späten 1990ern und frühen 2000ern versuchten – ohne Erfolg – viele Softwareunternehmen, Programmiersprachen durch visuelle Tools zu ersetzen. Siehe auch, Lego Programming von Joel Spolsky, Dezember 2006
