BI-Schulden (Business Intelligence)

BI-Schulden sind die aufgelaufenen Kosten von Abkürzungen, undokumentierten Daten und ungesteuerten Dashboards in der Analyseumgebung eines Unternehmens. Wie technische Schulden in der Softwareentwicklung verstärken sie sich über die Zeit: Jede schnelle Notlösung macht die nächste Änderung schwerer, langsamer und riskanter.

Unternehmen mit hohen BI-Schulden verbringen mehr Zeit damit, alte Berichte zu pflegen, als neue Erkenntnisse zu gewinnen. Das Symptom ist vertraut: In vielen Teams kann eine Analystin den Großteil ihrer Woche damit verbringen, bestehende Dashboards zu aktualisieren und widersprüchliche Zahlen abzugleichen, und nur einen kleinen Teil mit tatsächlicher Analyse. Eigentlich müsste das Verhältnis umgekehrt sein, doch Jahre aufgelaufener Abkürzungen machen das ohne bewusste Sanierung unmöglich.

Wie BI-Schulden aussehen

BI-Schulden zeigen sich in fünf wiedererkennbaren Mustern. Die meisten Unternehmen haben alle fünf, kaum eines hat eines davon gemessen. Die Beispiele auf dieser Seite, von der Grafik unten bis zu den Szenarien zu Migration und Self-Service, sind illustrativ: ein typisches Bild, keine Daten eines einzelnen Unternehmens.

Wildwuchs an Dashboards. 500 Berichte in Power BI liegen im Arbeitsbereich. 80 % wurden in 90 Tagen nicht geöffnet. Niemand weiß, welche aktuell sind, welche Entwürfe und welche für ein Projekt gebaut wurden, das vor zwei Jahren endete. Neue Berichte entstehen, weil einen bestehenden zu finden schwerer ist, als von vorn zu beginnen.

Uneinheitliche Kennzahlen. Der Finanzbereich meldet 12 Mio. US-Dollar Monatsumsatz. Der Vertrieb meldet 11,4 Mio. US-Dollar. Der Unterschied geht auf drei undokumentierte Ausschlüsse in der Abfrage der Vertriebspipeline zurück: Partnerumsatz ist in der einen ausgeschlossen und in der anderen enthalten. Die Bezeichnung ist identisch. Beide Zahlen sind gegen ihre eigene Logik „richtig“, doch das Unternehmen kann sich auf keine einzige Wahrheit einigen.

Fest verdrahtete Transformationen. Ein wichtiger Vorstandsbericht hängt an einer SQL-Abfrage, die ein Analyst vor drei Jahren geschrieben hat. Sie enthält Fachregeln als CASE-Anweisungen mit Kommentaren wie „Altkonten ausschließen, auf Wunsch von Sarah (2023)“. Niemand weiß, wer Sarah ist, worin der Wunsch bestand oder ob er noch gilt.

Abhängigkeit von Einzelpersonen. Wenn die erfahrene Analystin im Urlaub ist, kann niemand den Vorstandsbericht aktualisieren. Die ETL-Logik existiert nur in ihrem Kopf. Ihr Weggang, freiwillig oder nicht, würde eine Krise auslösen und nicht bloß eine Lücke hinterlassen.

Veraltete Datenquellen. Das Unternehmen ist vor 18 Monaten von einer Datenbank auf eigenen Servern zu Snowflake gewechselt. Die Hälfte der Dashboards wurde auf das neue Warehouse gerichtet. Die andere Hälfte liest weiterhin aus dem alten System, das nach einem anderen Zeitplan aktualisiert wird. Beide Gruppen zeigen plausibel aussehende Zahlen, die sich leicht unterscheiden.

Wie BI-Schulden entstehen

BI-Schulden entstehen selten durch eine bewusste Entscheidung. Sie laufen über vier Muster auf, die sich im Moment vernünftig anfühlen.

Tempo vor Governance. Eine Bereichsleitung braucht bis Freitag einen Bericht. Die Analystin baut ihn aus einer Rohtabelle, ohne Dokumentation, ohne Tests und mit einem fest verdrahteten Datumsfilter. Die Bereichsleitung ist begeistert. Der Bericht wird zur Dauereinrichtung. Über zwölf Monate laufen ein Dutzend solcher „schnellen Berichte“ auf, jeder mit undokumentierten Annahmen und ohne Verantwortlichen.

Technologiewechsel ohne Aufräumen. Das Unternehmen wechselt von SQL Server zu Snowflake. Das Migrationsteam verschiebt die wichtigen Tabellen. Niemand erfasst die 200 Berichte, die auf das alte System zeigen. Beide Systeme laufen monatelang parallel, dann jahrelang. Die Kosten, zwei Systeme zu pflegen, verstärken sich, doch das alte abzuschalten verlangt, jeden Bericht zu prüfen, ein Vorhaben, das niemand finanzieren will.

Organisatorischer Wandel. Nach einer Fusion bestehen zwei Umgebungen für BI nebeneinander. Jede definiert „Kundenzahl“ anders, die eine zählt aktive Konten, die andere aktive Nutzer. Der zusammengeführte Vorstandsbericht mittelt beide, was in beide Richtungen falsch ist. Niemand gleicht die Definitionen ab, weil der politische Preis dafür, sich für eine zu entscheiden, höher ist als der Preis, mit beiden zu leben.

Self-Service ohne Leitplanken. Das Unternehmen führt BI-Anwendungen im Self-Service ein, stellt aber keine zertifizierten Datenquellen bereit, keine Definitionen von Kennzahlen und keine Nutzungsverfolgung. Binnen sechs Monaten gibt es 200 Dashboards. Binnen zwölf Monaten verbringt das Analyseteam mehr Zeit mit der Frage „Welches Dashboard stimmt?“ als mit neuer Analyse.

BI-Schulden messen

BI-Schulden sind messbar. Fünf Indikatoren lassen sich mit der Analytik der vorhandenen BI-Plattform und einem Scan mit dem Datenkatalog prüfen.

Nutzung der Berichte: Wie viel Prozent der Berichte wurden in den letzten 90 Tagen aufgerufen? Einen allgemeingültigen Richtwert gibt es nicht, also setzen Sie sich ein eigenes Ziel und verfolgen Sie den Verlauf. Nicht aufgerufene Berichte sind die, die Rechenzeit und Pflege kosten und keinen Wert liefern.

Einheitlichkeit der Kennzahlen: Nehmen Sie fünf zentrale Kennzahlen (Umsatz, Kundenzahl, Churn-Rate, Marge, Pipeline-Wert) und prüfen Sie, ob sie über alle Dashboards hinweg dieselbe Zahl liefern. Jede Abweichung ist ein Schuldenposten mit einer nachvollziehbaren Ursache.

Abdeckung der Dokumentation: Wie viel Prozent der Tabellen im Warehouse haben Beschreibungen, Verantwortliche und dokumentierte Lineage? Auch hier gilt: Setzen Sie sich ein eigenes Ziel und verfolgen Sie den Verlauf von Quartal zu Quartal. Undokumentierte Tabellen sind für Nutzer im Self-Service unsichtbar und für Analysten riskant.

Risiko durch Einzelpersonen: Wie viele Berichte kann nur eine einzige Person pflegen? Jeder davon ist ein Single Point of Failure und ein Posten der BI-Schulden.

Geschwindigkeit der Abfragen: Wie viele Berichte brauchen länger als 30 Sekunden zum Laden? Langsame Berichte deuten oft auf angehäufte Komplexität hin: Joins über unnötige Tabellen, nicht optimierte, organisch gewachsene Abfragen oder Datenmodelle aus einer anderen Zeit.

Die Kosten von BI-Schulden fürs Geschäft

BI-Schulden sind nicht bloß eine technische Unannehmlichkeit. Sie haben messbare finanzielle Wirkung.

Verzögerte Entscheidungen. Wenn Beteiligte den Zahlen nicht trauen, verlangen sie vor dem Handeln eine Bestätigung. Eine Preisentscheidung, die zwei Wochen wartet, während Analysten widersprüchliche Berichte abgleichen, kostet Marktanteile. Eine Anpassung der Lieferkette, die aufgeschoben wird, weil die Bestandsdaten zweifelhaft sind, verursacht Lagerhaltungskosten. Die Verzögerung ist der Preis, und sie wird den BI-Schulden selten zugerechnet.

Aufwand in der Entwicklung. 500 undokumentierte Berichte zu pflegen frisst Analystenzeit, die in neue Erkenntnisse fließen könnte: Berichte aktualisieren, kaputte Abfragen reparieren, Zahlen abgleichen. In der Harvard Business Review schätzte der Datenqualitätsexperte Thomas C. Redman, dass Wissensarbeiter 50 % ihrer Zeit in „versteckten Datenfabriken“ verlieren, die sich mit Daten befassen, denen niemand traut.

Risiko bei der Compliance. Undokumentierte Datenflüsse und ungesteuerte Kennzahlen schaffen Prüfungsrisiken. Wenn eine Aufsicht fragt „Wie haben Sie diese Risikokennzahl gerechnet?“ und die Antwort verlangt, sich durch fünf undokumentierte SQL-Abfragen mit fest verdrahteten Fachregeln zu arbeiten, hat das Unternehmen eine Lücke bei der Compliance und nicht bloß ein BI-Problem.

BI-Schulden abbauen

BI-Schulden abzubauen ist ein systematisches Programm und kein Wochenendprojekt. Eine Sanierung dauert oft Monate. Alles von Grund auf neu zu bauen scheitert oft, denn das Geschäft kann nicht ein Jahr lang auf Analyse verzichten, während das Team neu entwirft.

Ein praktikabler Weg ist eine Pipeline aus fünf Schritten.

Schritt 1: Katalogisieren. Erfassen Sie alle Berichte, Dashboards, Datenquellen und deren Nutzungsstatistik. Ein Datenkatalog automatisiert das, indem er die Metadaten der BI-Plattform und die Verbindungen zum Warehouse durchsucht. Das Ergebnis ist ein vollständiges Bild davon, was es gibt und was tatsächlich genutzt wird.

Schritt 2: Definieren. Richten Sie ein Business Glossary mit kanonischen Definitionen für die zentralen Kennzahlen ein. „Umsatz“ bekommt eine Definition, eine Rechnung, eine Quelltabelle. Das ist eine fachliche und keine technische Entscheidung: Finanzen, Vertrieb und Marketing müssen sich auf die Definition einigen, weshalb es Wochen dauert und nicht Stunden.

Schritt 3: Lineage dokumentieren. Verfolgen Sie jeden wichtigen Bericht von der Kennzahl im Dashboard bis ins Quellsystem. Finden Sie undokumentierte Transformationen, fest verdrahtete Fachregeln und manuelle Schritte. Werkzeuge für Data Lineage automatisieren vieles davon, doch die fest verdrahtete Logik in SQL-Abfragen verlangt eine Prüfung von Hand.

Schritt 4: Stilllegen. Archivieren Sie Berichte ohne jede Nutzung in den letzten 90 Tagen. Benachrichtigen Sie die Verantwortlichen, setzen Sie eine Frist von 30 Tagen und entfernen Sie die Berichte danach. Dieser Schritt ist politisch schwerer als technisch: Menschen wehren sich gegen die Stilllegung „ihrer“ Berichte, selbst wenn niemand sie nutzt. Die Nutzungsdaten aus dem Katalog nehmen der Sache die Mehrdeutigkeit.

Schritt 5: Steuern. Richten Sie Freigabeprozesse für neue Berichte und Datenquellen ein, damit keine neuen Schulden auflaufen. Kein Dashboard geht ohne dokumentierte Datenquelle, Definitionen der Kennzahlen und Verantwortlichen in Betrieb. Dieser Schritt verhindert, dass die anderen vier zur Dauerübung werden.

Neuen BI-Schulden vorbeugen

Vorbeugen kostet weit weniger als Sanieren. Fünf Praktiken verhindern, dass BI-Schulden erneut auflaufen.

Dokumentation vor Veröffentlichung verlangen. Kein Dashboard geht ohne Beschreibung der Datenquelle, Definitionen der Kennzahlen und Verantwortlichen in Betrieb. Das entspricht dem Code-Review in der Analyse: Es bremst die Veröffentlichung, und genau das ist der Zweck.

Datenquellen zertifizieren. Pflegen Sie eine kuratierte Liste freigegebener Tabellen und Sichten, auf denen Nutzer im Self-Service aufbauen dürfen. Nicht zertifizierte Quellen verlangen eine Begründung und eine Prüfung. Das verhindert die Abkürzung „aus einer Rohtabelle bauen“, die die meisten BI-Schulden erzeugt.

Nutzung der Berichte verfolgen. Markieren Sie Berichte ohne Aufrufe in 90 Tagen automatisch zur Prüfung. BI-Plattformen liefern die Nutzungsdaten, der Datenkatalog zeigt sie im Zusammenhang. Berichte, die niemand nutzt, sollten weder Rechenzeit noch Pflegeaufmerksamkeit verbrauchen.

Kennzahlen im Glossar vereinheitlichen. Jede neue Kennzahl muss ins Business Glossary, bevor sie auf einem Dashboard auftaucht. So hat jede neue Kennzahl vom ersten Tag an eine Definition, eine Rechnung und einen Verantwortlichen und nicht erst rückwirkend, nachdem sie bereits Verwirrung gestiftet hat.

Vierteljährlich prüfen. Planen Sie vierteljährliche Prüfungen der BI-Schulden ein, die die fünf Indikatoren aus dem Abschnitt zum Messen erheben. Verfolgen Sie den Verlauf. Feiern Sie Fortschritte. Eine vierteljährliche Durchsicht von zwei Stunden verhindert ein Sanierungsprojekt, das sich über Monate zieht.

Wie Dawiso BI-Schulden senkt

Der Datenkatalog und das Business Glossary von Dawiso passen direkt auf das Problem der BI-Schulden.

Der Katalog durchsucht die Metadaten des Warehouse und die Verbindungen zur BI-Plattform und erfasst die Tabellen, Sichten und Berichte in den angebundenen Quellen, samt der Nutzungsstatistik, wo das Quellsystem sie bereitstellt (etwa bei SAP BW BEx Queries), die ungenutzte Bestände sichtbar macht. Das ist Schritt 1 der Sanierung, automatisiert. Statt einer Prüfung von Hand entsteht ein Verzeichnis, das bei jedem Scan aktualisiert wird, während Berichte entstehen und stillgelegt werden.

Das Business Glossary bietet einen einzigen Ort, an dem Kennzahlen definiert werden, sodass „Umsatz“ über alle Dashboards hinweg dasselbe bedeutet. Wenn zwei Berichte verschiedene Umsatzzahlen zeigen, ist die Definition im Glossar der Ort, an dem die Abweichung nachvollzogen und aufgelöst wird, und nicht eine Sitzung, in der jedes Team seine eigene Tabelle verteidigt.

Data Lineage verfolgt jeden Bericht zurück zu den Quellen dahinter. Wenn der Vorstandsbericht an einer SQL-Abfrage mit unerklärten CASE-Anweisungen hängt, zeigt die Lineage, welche Tabellen und Quellen den Bericht speisen; die fest verdrahtete Logik selbst zu prüfen bleibt ein manueller Schritt.

Datenprodukte erfassen Qualitätsprüfungen und SLAs, gemessen von Ihren Werkzeugen für Datenqualität, sodass der Zustand einer Quelle dort sichtbar ist, wo man sie findet. Eine veraltete Datenquelle, an der 15 Berichte hängen, vervielfacht die BI-Schulden, und die Lineage zeigt, welche Berichte von ihr abhängen.

Über das Model Context Protocol (MCP) können KI-Assistenten Dawiso schon beim Bau eines Berichts abfragen, um Definitionen im Glossar nachzuschlagen, die Lineage zu verfolgen und die Attribute eines Objekts einzusehen, einschließlich des Verantwortlichen, sofern erfasst. Das ist Vorbeugung im Moment des Entstehens und hält neue BI-Schulden aus dem System heraus.

Fazit

BI-Schulden sind kein Technologieproblem. Sie sind ein Problem der Governance mit technischen Folgen. Die meisten Unternehmen mit mehr als einer Handvoll Dashboards haben BI-Schulden in gewissem Maß. Die Frage ist, ob sie gemessen und gesteuert werden oder ungeprüft anwachsen dürfen. Die Pipeline aus fünf Schritten, also katalogisieren, definieren, dokumentieren, stilllegen und steuern, ist nicht glanzvoll, aber sie ist ein Weg, der ohne vollständigen Neubau wirkt. Und die Praktiken zur Vorbeugung kosten weit weniger als eine Sanierung. Unternehmen, die BI-Schulden als vorrangiges Thema behandeln, verbringen weniger Zeit mit der Pflege von Berichten und mehr damit, Daten tatsächlich für Entscheidungen zu nutzen.

Quellen

• Harvard Business Review - Thomas C. Redman, Bad Data Costs the U.S. $3 Trillion Per Year (2016)
• Dawiso Help - Data product quality and SLAs
• Dawiso Help - Dawiso Model Context Protocol (MCP)