Sie haben bereits BI. Was fehlt, sind verlässlich verknüpfte Daten.

Die meisten mittelständischen Unternehmen, mit denen wir gesprochen haben, besitzen bereits ein Business-Intelligence-Tool. Es kam mit dem ERP, oder jemand hat vor ein paar Jahren Power BI gekauft, oder eine Beratung hat Dashboards gebaut, die in der Präsentation gut aussahen. Am Tool liegt es selten. Wenn uns ein Controller sagt, das Reporting funktioniere nicht, meint er fast nie, dass die Diagramme hässlich sind. Er meint, dass er den Zahlen nicht traut, oder dass das Dashboard ungeöffnet bleibt, weil es mehr Aufwand kostet, ihm etwas Belastbares zu entlocken, als die Rechnung von Hand zu machen.

In diesem Beitrag geht es darum, warum das passiert, und warum die Lösung in einer Schicht liegt, auf die kaum jemand schaut: die Daten unterhalb des Dashboards, der Teil, der Ihre Systeme miteinander verknüpft und festlegt, was die Zahlen bedeuten.

Das Symptom

Ein Hersteller, mit dem wir gesprochen haben, hatte das Reporting-Modul seines ERP die ganze Zeit aktiviert und es tatsächlich nie genutzt. Die zugrunde liegenden Daten waren zu unzuverlässig, als dass sich die Berichte gelohnt hätten. BI stand ihnen jahrelang zur Verfügung. Was ihnen fehlte, waren Daten, denen im Haus jemand glaubte.

Von innen ist das schwer zu erkennen, weil die Verantwortlichen in diesen Unternehmen gar nicht meinen, ein Datenproblem zu haben. KPMG hat im Global Tech Report 2026 für die Industrieproduktion 258 Technologieverantwortliche aus 22 Ländern zwei Fragen in derselben Befragung gestellt: 83 % gaben an, solide Datengrundlagen für KI aufzubauen, und 76 % nannten unzuverlässige Daten als eines der größten KI-Risiken. Dieselben Befragten, wenige Fragen auseinander. Das Vertrauen in die Datenschicht liegt deutlich über ihrem tatsächlichen Zustand, und deshalb zeigt sich das Problem meist erst dann, wenn jemand eine Zahl braucht, lange nach der Budgetentscheidung.

Das Muster ist so konstant, dass wir es inzwischen erwarten. Ein leistungsfähiges BI-Tool sitzt auf einem ERP, nach ein paar Zukäufen auch auf zwei oder drei, dazu ein Lagersystem, ein Shopfloor-System und die üblichen Tabellen. Die Dashboards existieren und bleiben ungeöffnet, weil alle wissen, dass die Zahlen nicht ganz zusammenpassen, und eine Zahl, die man relativieren muss, ist schlechter als gar keine.

Das Diagramm sind die letzten fünf Prozent

Es gibt eine hilfreiche Art, das Verhältnis zu sehen. Wenn ein Bericht endlich funktioniert, ist der sichtbare Teil auf dem Bildschirm nur ein kleiner Bruchteil der Arbeit, die ihn belastbar gemacht hat. Ein ERP-Experte, mit dem wir gesprochen haben und der viele davon gebaut hat, schätzt es auf etwa 95 % Datenverarbeitung und 5 % Visualisierung, und das deckt sich mit dem, was wir sehen.

Nichts von dieser Verarbeitung taucht im Dashboard auf, und genau sie ist der Grund, warum man dem Dashboard überhaupt trauen kann. Ein BI-Tool setzt voraus, dass die Arbeit bereits erledigt ist. Es ist eine Präsentationsschicht und zeigt, was man ihm gibt, auch Daten, die auf eine Weise falsch sind, die das Diagramm nicht sichtbar machen kann. Und einmal verlorenes Vertrauen kehrt womöglich nie zurück, zurück bleibt ein Stapel ungenutzter BI-Dashboards.

Warum „einfach ein Dashboard dazu“ das nicht löst

Drei Fehlerquellen machen Reporting unzuverlässig, und jede davon liegt vor dem Diagramm, dort, wo ein BI-Tool nicht hinreicht.

1. Es gibt keinen gemeinsamen Schlüssel. Zwei Systeme führen Daten zum selben Auftrag, also muss die Verknüpfung aus Feldern rekonstruiert werden, die nie zur Identifikation gedacht waren. Macht man es falsch, zählt der Bericht doppelt oder lässt stillschweigend Zeilen weg, und in beiden Fällen sieht er korrekt aus. Genau das macht eine falsche Verknüpfung gefährlich und nicht bloß ärgerlich.
2. Dasselbe Wort bedeutet Verschiedenes. Wir haben erlebt, dass ein Maschinenstillstand in einem Werk mit 15 Kategoriecodes erfasst wurde und in einem anderen mit 87, sodass „Stillstandzeit“ keine einzelne Zahl ist, solange niemand festlegt, wie die Schemata aufeinander abbilden. Im Finanzbereich dasselbe Bild: „Revenue“ in einem Hauptbuch und „Umsatzerlöse“ in einem anderen sind nicht automatisch dieselbe Position, und ein konsolidierter Bericht, der das annimmt, ist falsch, bevor er gezeichnet wird.
3. Für beides ist niemand zuständig. Diese Unternehmen haben einen Controller, der gut mit Excel umgehen kann, oder einen Entwickler, der SQL schreibt, weil es sonst niemand tut, und kein dokumentiertes Schema, sodass das Wissen darüber, wie die Systeme zusammenpassen, in den Köpfen einiger weniger steckt.

Derselbe Bericht, aus zwei unterschiedlichen Verknüpfungen gezeichnet. Einer davon liegt um 11 % daneben, und im Diagramm werden Sie nicht herausfinden, welcher.

Ein BI-Tool gibt diesem Controller eine leere Fläche und setzt voraus, dass er bereits saubere, verknüpfte und verstandene Daten in der Hand hält. Diese Annahme ist der Engpass.

Eine Zahl bis zur Quelle zurückverfolgen

Ein BI-Tool zeigt Ihnen eine Zahl. Sobald die Daten Systemgrenzen überschritten haben, kann es Ihnen nicht mehr sagen, woher diese Zahl stammt, und genau diese Lücke ist der Grund, warum ein Dashboard, dem man nicht traut, vor jeder Entscheidung noch einmal von Hand geprüft wird. Dieses Nachprüfen ist der eigentliche Aufwand: langsam, erledigt von der Person, deren Zeit am teuersten ist, und jeden Monat aufs Neue.

Wir kennen das von innen. Bevor es Beetl gab, haben wir drei die Datenplattform hinter einem Produkt für programmatische Stellenanzeigen bei einem HR-Tech-Unternehmen mit rund 1.200 Mitarbeitenden neu gebaut. 6 Data Engineers betrieben eine Pipeline, die täglich Milliarden von Events verarbeitete, und der größte Teil ihrer Kapazität floss in eine einzige Schleife: Jemand meldete eine Zahl, die falsch aussah, und das Team brauchte Tage, um festzustellen, ob sie tatsächlich falsch war oder die Kennzahl sich genau wie vorgesehen verhielt, und dann weitere Tage für den Backfill. Die Pipeline war nicht wirklich das Problem. Nachzuweisen, was die Pipeline getan hatte, war das Problem.

Diese Schleife zu schließen war der Zweck des Umbaus, und deshalb ist unsere Plattform so gebaut, wie sie gebaut ist. Datenvorfälle gingen um rund 90 % zurück, und etwa 70 % der Engineering-Kapazität des Teams flossen zurück in die Entwicklung. Dieses Unternehmen war nie Beetl-Kunde und Beetl existierte damals noch nicht; das sind Zahlen, die wir an einem System gemessen haben, das wir selbst gebaut und betrieben haben.

Die Schleife, die den größten Teil der Kapazität von sechs Engineers verbraucht hat, und dieselbe Frage, gegen einen nachvollziehbaren Wert beantwortet.

Wenn unsere Plattform also einen Wert berechnet, können Sie ihn anklicken und bis zur Quelltabelle zurückverfolgen, zur Verknüpfung, die die Datensätze zusammengeführt hat, und zur versionierten Regel, die ihn erzeugt hat. Sie finden heraus, ob die Zahl falsch liegt oder Ihre Einschätzung, und zwar in Minuten.

Ehrlicherweise hat unsere Data Lineage weiterhin 2 Grenzen:

1. Wir können zeigen, wie das Tool zu einer Zahl gekommen ist. Wir können nicht bestätigen, dass das Quellsystem von vornherein das Richtige erfasst hat, und diese Garantie kann niemand seriös geben.
2. Die Rückverfolgung reicht nicht bis auf die einzelne Zelle. Sobald Werte in einer SQL-Berechnung zusammenfließen, lässt sich ein Aggregat nicht wieder in die Zeilen zerlegen, aus denen es entstanden ist. Zeigen können wir immer die Eingangsdaten, die Transformation und die Version der Regel, die gelaufen ist.

In der Praxis klärt das die meisten Diskussionen, denn sie drehen sich in aller Regel darum, welche Datensätze einbezogen wurden und wie ein Feld verstanden wurde, und nicht um die Rechnung.

Die Integration ist der schwierige Teil

Sind die Daten einmal verknüpft und ihre Bedeutung geklärt, sind die Berichte vergleichsweise einfach. Wir machen die Verknüpfung und das Entitätsmodell einmal, und aus einer Margenansicht, einer Stillstandsansicht und einer Lieferantenansicht wird eine Auswertungssicht auf dieselben Daten statt drei getrennter Projekte. Der schwierige und wirklich wertvolle Teil ist die Integration darunter. Die Rechnung obendrauf ist gewöhnlich, und ein Hersteller, der seinen eigenen Prozess kennt, durchschaut jedes Produkt, das so tut, als sei die Arithmetik das Kunststück.

Michele hat denselben Punkt von der anderen Seite her aufgeschrieben, in warum datenbasierte Entscheidungen im Alltag so schwer sind: Daten zahlen sich erst aus, wenn sie eine Entscheidung verändern, und die Integration für jede neue Frage neu zu bauen ist genau das, was verhindert, dass daraus Routine wird.

Dafür gibt es auch eine messbare Fassung, und sie kommt mit zwei Einschränkungen, die man nennen sollte. Der Connectivity Benchmark 2026 von MuleSoft, durchgeführt von Vanson Bourne im Oktober und November 2025, beziffert den Anteil der IT-Zeit für Entwurf, Bau und Test individueller Integrationen auf 36 %: mehr als ein Drittel eines Teams, das für Verbindungen aufgewendet wird statt für etwas, das ein Kunde zu sehen bekommt. Salesforce gehört MuleSoft und verkauft Integrationssoftware. Und die 1.050 befragten IT-Verantwortlichen arbeiten alle in Organisationen ab 1.000 Mitarbeitenden, also nicht in der Größenordnung, für die wir bauen. Lesen Sie die Zahl als Beleg dafür, dass dieses Problem mitwächst, und nicht als Messung Ihres eigenen Hauses.

Auch deshalb beschreiben wir, was wir tun, als programmierbare Datenintegration und nicht als weiteres Analyse-Tool. Reporting ist eine der Möglichkeiten, die diese Schicht eröffnet, und es sitzt auf etwas, das vorher existieren muss.

Was das für Ihre Kaufentscheidung bedeutet

Wenn Ihren Dashboards nicht getraut wird, helfen weitere Dashboards nicht, und ein besseres BI-Tool auch nicht. Die Schicht, die repariert werden muss, ist die darunter. BARC hat im Data, BI and Analytics Trend Monitor 2026, einer Befragung von 1.579 Fachleuten, Datenqualitätsmanagement wieder auf Platz eins für 2026 gesetzt. Datensicherheit, Datenkultur, Governance und Datenkompetenz folgen darauf, und erst nach diesen fünf kommen KI, Machine Learning und generative KI. Die Menschen, die diese Arbeit machen, haben die Reihenfolge der Schichten bereits festgelegt. Das ist es wert, vor einer Budgetentscheidung zu wissen, denn aus der Ferne sehen beide ähnlich aus und kosten sehr unterschiedlich viel Zeit.

Wir bauen diese Integrationsschicht für Unternehmen, die dafür kein eigenes Datenteam einstellen wollen. Wenn Ihr Problem diese Form hat, bringen Sie uns nicht eine Reporting-Anforderung mit, sondern die Liste der Systeme, aus denen Sie einen belastbaren Satz Zahlen bekommen wollen.