KI verschiebt den Aufwand, sie eliminiert ihn nicht

Vor Kurzem bin ich auf einen Artikel von Luise Freese auf heise online gestoßen, der beschreibt, warum LLM-basierte Business Intelligence in vielen Unternehmen über die Demo-Phase nicht hinauskommt. Beim Lesen musste ich ständig an Fertigungsdaten denken, denn die Beobachtungen aus der BI-Welt lassen sich fast eins zu eins auf den Shopfloor übertragen.

Die Kernbeobachtung des Artikels: Dialogbasierte BI-Systeme funktionieren in Demos zuverlässig, weil sie auf sauber strukturierten, überschaubaren Datenbeständen laufen. Im produktiven Betrieb treffen sie dagegen auf gewachsene Datenlandschaften, in denen zentrale Kennzahlen wie Umsatz oder Kunde nicht einheitlich definiert sind, sondern sich über Jahre in unterschiedlichen Berichten und Fachbereichen unterschiedlich ausgeprägt haben. Ein Sprachmodell muss diese Mehrdeutigkeit bei jeder Anfrage neu auflösen, während klassische BI-Werkzeuge sie längst implizit in ihre Berichte eingebaut haben.

Dieselbe Mehrdeutigkeit auf dem Shopfloor

Was in der BI Umsatz oder Kunde ist, ist in der Fertigung OEE, Stillstandzeit oder Ausschussquote. Auch hier existieren Definitionen selten zentral und verbindlich, sondern implizit, je nach Linie, Werk oder Schicht gewachsen. Eine Anlage zählt einen Rüstvorgang möglicherweise als Stillstand, eine andere nicht. Eine Linie bereinigt Ausschusszahlen um bekannte Anlaufverluste, eine andere tut das nicht. Für Menschen, die mit diesen Berichten arbeiten, sind solche Anpassungen selbstverständlich. Ein Sprachmodell, das auf Zuruf eine Auswertung liefern soll, kennt diese impliziten Regeln nicht und kann sie auch nicht aus den Rohdaten ableiten.

Die eigentliche Herausforderung liegt also nicht in der Sprachverarbeitung, sondern in der eindeutigen Zuordnung fachlicher Bedeutung. Für MES-Daten gilt dieselbe Logik.

Die These: Aufwand verschiebt sich, er verschwindet nicht

Der heise-Artikel beschreibt, wie sich die Rolle von BI-Teams durch dialogbasierte Systeme verändert. Die Erstellung einzelner Reports tritt in den Hintergrund, die Pflege konsistenter Kennzahldefinitionen und semantischer Strukturen rückt in den Vordergrund. Der Aufwand wird nicht kleiner, er verlagert sich von der Ausführung zur Vorbereitung.

Für MES-Umgebungen bedeutet das: Wer sich von einem Sprachmodell auf dem Shopfloor eine Abkürzung erhofft, muss vorher genau die Arbeit leisten, die in vielen Betrieben bislang vermieden wurde. Saubere Stammdaten. Eindeutige Kennzahldefinitionen über Linien und Werke hinweg. Konsistente Schnittstellen zwischen den Systemen, die diese Daten liefern. Ohne diese Vorarbeit liefert ein Sprachmodell auf dem Shopfloor keine Abkürzung, sondern nur schneller falsche Antworten. Warum diese Vorarbeit trotzdem kein verlorener Aufwand ist, beschreibt Thimo Keller in Digitalisierung ist kein Vorspiel für KI.

Warum Composable MES hier ansetzt

Offene Schnittstellen und Modularität lösen dieses Problem nicht automatisch. Eine offene Schnittstelle definiert noch keine einheitliche OEE-Berechnung. Aber sie schafft die strukturelle Voraussetzung dafür, dass eine solche Definition überhaupt konsistent durchsetzbar wird — weil Kennzahlen dann an einer Stelle definiert und über alle Module hinweg konsistent bereitgestellt werden können.

In starr integrierten Systemen mit proprietären Schnittstellen bleibt selbst der beste Wille zur Datenbereinigung an Systemgrenzen hängen. Wenn MDE, Werkerführung und Auftragsmanagement nur über offene, dokumentierte Schnittstellen kommunizieren, lässt sich eine Kennzahl wie Stillstandzeit an einer Stelle definieren und über alle Module hinweg konsistent anwenden. Wie diese Module in der Praxis zusammenarbeiten, steht in Composable, aber nicht isoliert.

Drei Fragen für Entscheider

Aus dieser Logik lassen sich Fragen ableiten, an denen sich die eigene Datenreife prüfen lässt — unabhängig davon, ob ein KI-gestütztes System konkret geplant ist oder nicht.

Erstens: Sind Kennzahlen wie OEE oder Stillstandzeit über Linien und Werke hinweg einheitlich definiert, oder existieren mehrere, leicht abweichende Auslegungen nebeneinander?

Zweitens: Gibt es eine benannte Verantwortlichkeit für diese Definitionen, oder entstehen sie informell in einzelnen Berichten und Systemen?

Drittens: Lassen sich die relevanten Daten aus den eingesetzten Systemen tatsächlich programmatisch abrufen, oder liegen sie in geschlossenen Systemen, aus denen sie nur manuell oder über Umwege extrahierbar sind?

Wer diese Fragen für seine Fertigungsumgebung nicht beantworten kann, für den bleibt jedes Vorhaben in diese Richtung zunächst ein strukturelles Thema, kein technisches. Eine noch kürzere Vorprüfung sind die vier Fragen vor dem KI-Projekt.

Fazit

KI-gestützte Systeme auf dem Shopfloor sind kein Ersatz für architektonische Vorarbeit. Sie machen im Zweifel nur sichtbarer, wie viel davon noch fehlt.