Data-Driven Decision Making (datengestützte Entscheidungsfindung)
bezeichnet Entscheidungen, die sich auf gemessene Werte stützen statt auf Berichte aus zweiter Hand oder auf die Erfahrung einzelner Personen. In der Produktion sind diese Werte reichlich vorhanden: Jede Steuerung, jeder Sensor, jedes Leitsystem schreibt laufend mit.

Am Zugang zu Daten scheitert es deshalb selten. Es scheitert an drei Stellen davor: Die Zahl bedeutet in zwei Systemen etwas Verschiedenes, sie ist älter als die Entscheidung, oder niemand ist zuständig, wenn sie ausschlägt. Ein Dashboard behebt keinen dieser drei Punkte — es macht sie nur sichtbarer.

Der nüchterne Maßstab lautet deshalb nicht „Wie viele Kennzahlen zeigen wir?“, sondern: Welche Entscheidung fällt heute anders als vorher — und wie viel früher?

„Wie lief Linie 3 gestern?“ ist in vielen Werken keine Frage mit einer Antwort.
Das Leitsystem rechnet die Verfügbarkeit über die geplante Laufzeit, das MES zählt Rüstzeiten nicht als Stillstand, und im Controlling steht eine Tabelle, die einmal jemand gebaut hat. Alle drei Zahlen sind korrekt berechnet. Verschieden sind die Definitionen.

Das ist kein Datenproblem, sondern ein Benennungsproblem. Es löst sich erst, wenn eine Größe einmal festgelegt wird — mit Definition, Einheit und Zuständigem — und alle Verbraucher sie von genau diesem Platz holen. Genau das leistet ein Unified Namespace: Er ist der Ort, an dem aus vielen Zahlen eine wird.

Zwischen einem Ereignis in der Anlage und einer Maßnahme liegen immer fünf Schritte: Erfassung, Einordnung, Sicht, Bewertung, Maßnahme. Diese Strecke ist die eigentliche Kennzahl der Entscheidungsfähigkeit — nicht die Zahl der Reports.

Wo Auswertungen für jede Frage neu entstehen, ist der längste Abschnitt nicht die Technik, sondern die Wartezeit: auf den nächsten Berichtslauf, auf jemanden, der die Daten zusammenstellt, auf die Klärung, welche Fassung gilt. Steht die Struktur dagegen schon und fließt der Wert laufend, entfallen genau diese Abschnitte.

Dieselben fünf Stationen, zwei Wege — der Unterschied liegt in dem, was nicht jedes Mal neu gebaut werden muss.

Wichtig ist die Richtung, nicht der Rekord: Eine Entscheidung, die einmal im Quartal fällt, braucht keine Sekundenwerte. Eine Umrüstentscheidung in der laufenden Schicht schon.

Eine Zahl taugt zur Entscheidung, wenn sie alle vier erfüllt. Drei von vier genügen nicht
— die fehlende bestimmt, was am Ende passiert.

• Der Wert entsteht automatisch

  Er wird erfasst, nicht eingetragen. Handaufschriebe altern zwischen zwei Schichten und dokumentieren am Ende eher die Sorgfalt der Erfassenden als den Prozess.

• Die Bedeutung ist festgelegt

  Definition, Einheit und Bezugsgröße stehen fest und gelten in jedem System gleich. Erst damit ist ein Vergleich zwischen zwei Linien oder zwei Werken zulässig.

• Der Wert ist jünger als die Entscheidung

  Nicht „in Echtzeit“, sondern schnell genug für den Takt, in dem entschieden wird. Der Maßstab kommt aus dem Prozess, nicht aus der Technik.

• Schwelle und Zuständiger stehen daneben

  Ab wann ist eine Abweichung eine Abweichung, und wer handelt dann? Ohne diese beiden Angaben ist eine Kennzahl Berichtswesen, keine Entscheidung.

Der häufigste Fehler ist, alles gleich schnell machen zu wollen. Sinnvoll ist die umgekehrte Reihenfolge: erst klären, in welchem Takt entschieden wird, dann die Datenstrecke danach auslegen.

Aufschlussreich ist die letzte Spalte: Auf keiner Ebene ist fehlende Messtechnik der Grund.
Es ist jedes Mal die Struktur dazwischen. Warum das eine Architekturfrage ist

Was eine Feedback-Schleife wirklich verlangt

Der Nutzen datengestützter Entscheidungen zeigt sich erst, wenn die Wirkung derselben Maßnahme gemessen wird — mit derselben Kennzahl, vor und nach der Änderung. Das klingt selbstverständlich und scheitert regelmäßig daran, dass die Definition zwischenzeitlich angepasst wurde. Wer Veränderungen bewerten will, braucht deshalb nicht nur eine benannte Größe, sondern eine stabile: Flexibel sind die Inhalte, nicht das Ordnungsprinzip.

Datengestützt heißt nicht datengesteuert. Drei Grenzen bleiben, und sie zu benennen macht den Ansatz belastbarer:

• Zielkonflikte löst keine Zahl. Durchsatz gegen Rüstzeit, Bestand gegen Lieferfähigkeit, Termin gegen Instandhaltung — das sind Abwägungen. Daten machen den Preis jeder Option sichtbar; die Gewichtung bleibt eine Leitungsentscheidung.
• Was nicht gemessen wird, verschwindet aus der Debatte. Anlaufverhalten, Erfahrungswissen einzelner Bediener, Zustand einer alten Anlage — wer nur auswertet, was erfasst ist, entscheidet systematisch daran vorbei.
• Eine Kennzahl, die steuert, wird optimiert. Sobald an einer Zahl gemessen wird, verändert sich das Verhalten in ihre Richtung — auch dann, wenn das dem Ziel schadet. Deshalb gehört zu jeder Steuerungskennzahl eine Gegenkennzahl.

Und eine praktische Grenze: Frühzeitig sichtbare Abweichungen nützen nur, wenn sie jemanden erreichen, der handeln darf. Eine Benachrichtigung ohne Mandat erzeugt Betriebsamkeit, keine Korrektur.

pronubes ist die Schicht zwischen Shopfloor und IT. Für Entscheidungen sind drei Teile davon maßgeblich:

• pronubes Edge erfasst Werte lokal im Werk über OPC UA, MQTT, REST, SQL und Dateiformate — und puffert, wenn die Verbindung ausfällt. Damit entstehen keine Lücken, die später als Ausreißer interpretiert werden.
• pronubes Zones vergibt die Struktur, in der ein Wert eindeutig einem Standort, Bereich und Aggregat gehört. Das ist die Ebene, auf der aus drei Zahlen eine wird.
• pronubes Insights zeigt, welche Quelle wann was geliefert hat — einschließlich der Ströme, die schweigen. Eine Kennzahl, deren Quelle seit zwei Tagen stillsteht, sieht auf einem Dashboard aus wie eine gute Nachricht.

Die Werte lassen sich von dort an Auswertesysteme, Dashboards und einen Data Lake weitergeben — ohne dass jedes Zielsystem eigene Anbindungen an die Anlagen braucht. Mehr zur Plattform