Datenbasiert zu entscheiden bedeutet, Beobachtungen und Messwerte für eine Entscheidung zu nutzen und anschließend zu messen, was passiert ist. Für mich ist diese Rückkopplung inzwischen der wichtigste Grund, warum Datenverarbeitung für Unternehmen eine eigene Fähigkeit sein sollte. Mehr Daten zu speichern hat für sich genommen wenig Nutzen. Auch nützliche KI hängt von derselben Rückkopplung ab.
Der Wert entsteht in der Entscheidung
Ein Unternehmen entscheidet datenbasiert, wenn aktuelle Fakten fester Bestandteil seiner Entscheidungen sind. Diese Informationen müssen ankommen, solange noch gehandelt werden kann. Herkunft und Bedeutung müssen klar genug sein, um das Ergebnis prüfen zu können.
Erik Brynjolfsson, Lorin Hitt und Heekyung Kim untersuchten für eine Studie 179 große börsennotierte Unternehmen. Unternehmen, die großen Wert auf datenbasierte Entscheidungen legten, erreichten bei Leistung und Produktivität Werte, die 5 bis 6 % über dem lagen, was aufgrund ihrer übrigen Investitionen und ihres IT-Einsatzes zu erwarten gewesen wäre (Brynjolfsson, Hitt und Kim, 2011). Die Stichprobe war begrenzt, und die Autoren äußerten sich vorsichtig zur Kausalität. Nachdem sie allgemeine IT-Investitionen berücksichtigt hatten, brachten sie den gemessenen Unterschied mit der Art in Verbindung, wie Entscheidungen getroffen wurden.
Gespeicherte Daten schaffen geschäftlichen Nutzen, wenn sie das Handeln einer Person verändern. Das kann eine Lieferroute, eine Maschineneinstellung, eine Bestellung, einen Produktionsplan oder einen Preis betreffen.
Drei Beispiele dafür, wie verbundene Daten Entscheidungen verbessern
UPS: die Reihenfolge der heutigen Stopps
Ein:e Zustellfahrer:in trifft auf jeder Tour viele kleine Entscheidungen. Über das gesamte Zustellnetz summieren sich deren Auswirkungen. Die Reihenfolge von 120 oder mehr Stopps beeinflusst die gefahrene Strecke, die Leerlaufzeit, den Kraftstoffverbrauch und die Zahl der in einer Schicht zugestellten Pakete.
UPS entwickelte sein On-Road Integrated Optimization and Navigation System (ORION) für genau diese Entscheidung. Es verbindet Details zu einzelnen Paketen, eigene Kartendaten, Fahrzeugtelemetrie und Routing-Algorithmen, um jeden Tag eine effiziente Route zu berechnen. Die Erfahrung der Fahrer:innen bleibt Teil des Systems.
UPS führte ORION 2016 auf allen vorgesehenen Routen in den USA ein. Im ersten vollständigen Nutzungsjahr 2017 meldete das Unternehmen 100 Millionen weniger gefahrene Meilen, 100.000 metrische Tonnen weniger CO2 und Einsparungen bei den Betriebskosten von 410 Millionen US-Dollar (UPS Corporate Sustainability Progress Report, 2017).
Google: die nächste Anpassung der Kühlung
Die Kühlung eines Rechenzentrums ist ein kontinuierliches Regelungsproblem. Pumpen, Kältemaschinen, Kühltürme, Wetter und Rechenlast beeinflussen sich auf eine Weise, die sich mit festen Regeln nur schwer abbilden lässt. Google hatte seine Rechenzentren über Jahre effizienter gemacht, weshalb weitere Verbesserungen allein mit technischer Intuition schwer zu finden waren.
DeepMind nutzte historische Messwerte aus Tausenden Sensoren, darunter Temperatur, Leistung, Pumpendrehzahl und Sollwerte der Regelung. Mit diesen Daten trainierte das Team Modelle, die Energieeffizienz, Temperatur und Druck vorhersagten. Die Vorhersagen dienten dazu, mögliche Änderungen der Steuerung gegen betriebliche Grenzen zu prüfen, bevor das System eine Empfehlung ausgab.
In einem laufenden Rechenzentrum senkte das System den Energieverbrauch für die Kühlung um 40 % und den Overhead der Power Usage Effectiveness (PUE) um 15 % (Google DeepMind, 2016). Die PUE setzt den gesamten Energieverbrauch eines Rechenzentrums ins Verhältnis zum Energieverbrauch seiner IT-Systeme; der Overhead ist der Anteil oberhalb des Idealwerts 1,0. Für das Modell mussten historische Sensordaten einheitlich erfasst, mit Steuerungseinstellungen verknüpft und gegen eine klar definierte Zielgröße bewertet werden. Anschließend flossen die Empfehlungen zurück in den laufenden Betrieb.
Scanfil: die nächste Produkteinführung
Das Elektronikwerk von Scanfil in Suzhou hatte ein ERP-System, doch Teile der Anlagen waren nicht angebunden, die durchgängige Materialrückverfolgbarkeit war eingeschränkt und es gab kein verlässliches zentrales System für Fehler und Reparaturen. Das erschwerte die Qualitätskontrolle und häufige Linienwechsel in einer Fertigung mit vielen Varianten und kleinen Stückzahlen.
Das Werk band 236 Maschinen an und stellte 2.189 Produktroutings in einem zentralen Manufacturing-Operations-Management-System (MOM) bereit. Damit erhielt das Werk eine gemeinsame Sicht auf Materialien, Routings, Fehler, Reparaturen und aktuelle Maschinendaten. Laut einer Fallstudie von Siemens sank die durchschnittliche Zeit für eine Produkteinführung von 40 auf 9 Stunden. Dadurch waren mit derselben Konfiguration vier bis sechs Produkteinführungen möglich, während sich die Gesamtproduktivität um mehr als 10 % verbesserte (Siemens und Scanfil).
Datenbasierte Entscheidungen bilden einen Regelkreis
Die Beispiele unterscheiden sich stark in Größe und Ablauf, folgen aber derselben Struktur:
- Eine wiederkehrende Entscheidung wird genau benannt.
- Die nötigen Beobachtungen kommen aus den Systemen, die sie erzeugen.
- Geschäftsregeln oder Modelle machen aus den Beobachtungen eine Antwort.
- Die Antwort erreicht eine Person oder Maschine, solange noch gehandelt werden kann.
- Das Ergebnis wird erfasst, damit die nächste Entscheidung besser werden kann.
Die fünf Schritte bilden einen Regelkreis, der eine Person unterstützen kann, wie ORION eine:n Fahrer:in unterstützt, oder Anlagen innerhalb festgelegter Sicherheitsgrenzen steuert. Wie weit automatisiert wird, ist eine Designentscheidung. Beide Varianten hängen von derselben Fähigkeit zur Datenverarbeitung ab.
Auch alltägliche Geschäftsprozesse folgen diesem Muster. Eine Einkaufsleitung, die Lieferantenausgaben konsolidieren will, braucht Lieferantenstammdaten aus mehreren ERP-Systemen, die denselben Rechtsträgern zugeordnet sind. Eine Produktionsleitung, die bei einem verlustbringenden Auftrag eingreifen will, braucht Zyklusereignisse verknüpft mit Auftragsdaten, Materialkosten und Lohnsatz. Das Controlling braucht für eine Frage zur Marge die Transformationslogik und die Quelldatensätze hinter der Zahl. Die Entscheidung kann in einer Besprechung, in einem Dashboard, auf einer ERP-Maske oder über eine API getroffen werden. In jedem Fall beruht sie auf einem Datenfluss.
Ob ein Ergebnis eine Entscheidung noch verändern kann, hängt vom Zeitpunkt ab. Eine korrekte Margenabweichung zwei Wochen nach einer Schicht ist für die Buchhaltung nützlich. Dieselbe Abweichung kann während der Schicht die Personalplanung, die Materialbereitstellung oder das nächste Angebot verändern. Diesen Unterschied haben wir am Beispiel der Auftragsmarge ausführlicher beschrieben.
KI braucht dieselbe Grundlage
Die Qualität der Daten bestimmt, was ein KI-System wissen und welche Handlungen es unterstützen kann. Wer sie nur als vorbereitende Bereinigung behandelt, unterschätzt ihre Rolle.
Ein KI-System braucht außerdem die Beziehungen zwischen Fakten, die Bedeutung jedes Feldes und die Grenzen, innerhalb derer es handeln darf. Dazu gehören die korrekte Zuordnung von Kundenkennungen aus drei ERP-Systemen, stabile Schlüssel zwischen Produktionsaufträgen und Maschinenereignissen sowie die Erkennung von Änderungen an einer Quelle, bevor ein Ergebnis als verlässlich gilt.
Google konnte sein Kühlungsmodell trainieren und testen, weil Tausende historische Sensormesswerte vorlagen, die Zielgröße definiert war, die Betriebsgrenzen feststanden und sich die Vorhersagen mit einem realen Ergebnis vergleichen ließen.
Wir nutzen Sprachmodelle, um den Aufwand für Aufbau und Abfrage von Datenflüssen zu reduzieren. Aus Anweisungen in normaler Sprache können sie Zuordnungen, Transformationen und Abfragen entwerfen. Beetl macht diese Entwürfe sichtbar und verlangt eine Freigabe, bevor eine Pipeline produktiv geschaltet wird.

Die Grundlage ist Datenintegration
Die meisten Unternehmen haben die einzelnen Fakten bereits, verteilt über ERP-Tabellen, operative Datenbanken, SaaS-APIs, lokale Maschinen, Dateien und Tabellenkalkulationen. Jedes System ist für sich genommen schlüssig; nützliche geschäftliche Fragen reichen über seine Grenzen hinaus.

Für Fragen über Systemgrenzen hinweg braucht es einen verlässlichen technischen Ablauf: Quellen lesen, die eingelesenen Daten quellgetreu speichern, Transformationen explizit und versioniert halten, Ergebnisse validieren und abfragbar machen sowie Fehler offenlegen. Kosten und Fehleranfälligkeit steigen, wenn dieser Ablauf für jeden neuen Anwendungsfall neu gebaut wird.
Wir bauen Beetl, um diese technische Grundlage wiederverwendbar zu machen. Heute liest Beetl Daten aus Datenbanken, ERP-Systemen, Dateien, Tabellenkalkulationen und lokalen operativen Systemen ein. SQL-Pipelines transformieren quellnahe Daten in validierte Datensätze, die innerhalb von Beetl geprüft und abgefragt werden können. Zeitsteuerung, Zustandsverwaltung, Zugangsdaten, Deployment, Monitoring und Wiederherstellung laufen auf derselben Plattform.

Die quellspezifische Arbeit bleibt sichtbar: wie ein System angesprochen wird, welche Felder welchen Geschäftskonzepten entsprechen, welche Regeln einen Ausgabedatensatz erzeugen und wie Datensätze voneinander abhängen. Beetl liest Quellsysteme, ohne sie zu verändern, und bewahrt vor kundenspezifischen Transformationen eine quellgetreue Kopie auf. Sichtbare Definitionen und erhaltene Quelldaten erleichtern es, eine Antwort zu reproduzieren, zu prüfen und abzustimmen.
Beetl nutzt dasselbe Betriebsmodell für wiederkehrendes Management-Reporting, Lieferantenanalysen, Produktionskostenanalysen und andere Fragen, die mehrere Quellen benötigen. Deployment, Monitoring und Wiederherstellung laufen für jeden Datenfluss über dieselbe Infrastruktur, während seine quellspezifischen Regeln explizit bleiben.
Was wir ermöglichen wollen
Wir wollen, dass Unternehmen eine wichtige wiederkehrende Entscheidung mit aktuellen, nachvollziehbaren Daten verbessern können, ohne zunächst ein eigenes Datenplattform-Team aufzubauen. Quellen, Zuordnungen und Betriebshistorie aus dem ersten Datenfluss lassen sich dann für den nächsten wiederverwenden.
Am Anfang stehen eine Quelle, ein nützlicher Datensatz und eine wichtige Entscheidung. Sobald der Datenfluss in Produktion ist, lässt sich messen, ob sich die Entscheidung und ihr Ergebnis verbessern. Quellen, Zuordnungen, Ergebnisse und Betriebshistorie können anschließend den nächsten Datenfluss und spätere KI-Systeme unterstützen.
Wir bauen Beetl, weil operative Fakten noch immer zu spät in die relevanten Entscheidungen einfließen. Unternehmen sollten mit einer Entscheidung beginnen und die dabei entstandene Arbeit für weitere Entscheidungen, Analysen und KI wiederverwenden können.

