Warum KI-Pilotprojekte in der Fertigung stocken – und der übliche Rat es schlimmer macht

Im August 2026 berichtete Nordiska Projekt, dass 85 % der schwedischen Industrieunternehmen KI noch nicht über das Pilotstadium hinausgebracht haben.

Lesen Sie das als Zahl über Pilotprojekte, nicht über KI. Bis zum Pilotprojekt zu kommen, ist nicht das Schwierige. Jemand hat einen Anwendungsfall gefunden, jemand eine Budgetposition, jemand hat es umgesetzt, und dann war Schluss. In fünf von sechs Fällen war Schluss.

Zwischen Pilotprojekt und Rollout passiert etwas, und zwar so zuverlässig, dass es ein Muster ist und kein Pech. Es lohnt sich zu fragen, was.

Ein Projekt, das sich nicht abschließen lässt

Fragen Sie die meisten Fertigungsunternehmen, was zwischen Pilotprojekt und Rollout steht. Sie bekommen eine Variante derselben Antwort: Die Daten sind noch nicht so weit.

Fragen Sie weiter, was die Daten so weit bringen würde, und die Antwort wird unscharf.

Genau darin liegt das Problem. „Erst die Daten bereinigen“ ist der meistgehörte Rat zu KI in der Industrie, und er ist keine Aufgabe. Es gibt keine Definition von „fertig“, niemanden, der ihn für erledigt erklären kann, und keinen Test, mit dem Sie an einem gewöhnlichen Dienstag prüfen könnten, ob Sie angekommen sind. Jeder ehrliche Versuch, ihn einzugrenzen, ergibt ein größeres Projekt als das, dem er den Weg bereiten sollte: erst ein Data Warehouse, dann ein Fehlerkatalog, dann eine Bereinigung der Historie, die nicht zum neuen Katalog passt.

Ein Pilotprojekt ist klein genug, um dem zu entgehen. Es läuft auf einer Linie, mit einem Datensatz, den jemand für diesen Anlass von Hand bereinigt hat. Beim Rollout wartet das Projekt ohne Ende, und genau dort stehen die 85 %.

Der Rat hilft also nicht bloß nicht weiter. Er ist ein plausibler Grund dafür, dass die Zahl so aussieht, wie sie aussieht: Ein Unternehmen, das eine unendliche Aufgabe abschließen soll, bevor es eine endliche beginnt, schafft keine von beiden.

Niemand verweigert sich

Man sollte klar sagen, dass das kein Disziplinproblem ist, denn meist wird es als eines diagnostiziert.

Fast jede Instandhaltungssoftware der letzten zwei Jahrzehnte verlangt beim Abschluss eines Arbeitsauftrags dasselbe: ihn zu klassifizieren. Welche Fehlerart, welches Bauteil, welche Ursache. Leonard Lin, der bei Maintmaster für Manufacturing Intelligence verantwortlich ist, bringt auf den Punkt, was dabei herauskam: „Das macht niemand, das ist viel zu viel Aufwand.“

Sehen Sie sich an, was verlangt wurde. Mehrere Sekunden Klassifizierungsarbeit, mehrere hundert Mal pro Woche, von jemandem, dessen Schicht gerade zu Ende ist. Genau, auf Dauer und ohne je eine Rückmeldung, ob es richtig war. Das hält keine Belegschaft durch, und keine hat es je getan. Die Anforderung war unzumutbar, und zwar auf eine Weise, die vom Büro aus nicht zu sehen war.

Damit ist jeder Plan, dessen erster Schritt lautet diesmal füllen alle die Felder ordentlich aus, derselbe Plan, der die Daten hervorgebracht hat, die Sie heute haben.

Das hat eine zweite Hälfte, und sie läuft andersherum. Warum so wenig Instandhaltungshistorie lesenswert ist, erklärt Leonard nicht damit, dass schlecht geschrieben wurde, sondern damit, dass sie nie jemand gelesen hat: Für einen Eintrag, den niemand liest, hatte auch niemand einen Grund, ihn gut zu schreiben. Qualität folgt der Nutzung. Sie kommt nicht vor ihr.

Nimmt man beide Hälften zusammen, ist „erst die Daten bereinigen“ nicht nur endlos. Der Rat arbeitet gegen sich selbst. Er verordnet Warten, und das Warten ist genau der Mechanismus. Ein Unternehmen, das mit dem Lesen seiner Einträge wartet, bis sie lesenswert sind, hält genau den Prozess am Laufen, der verhindert, dass sie es werden.

Was das Pilotprojekt tatsächlich bewiesen hat

Hier lohnt es sich, kurz innezuhalten. Ein Pilotprojekt, das funktioniert hat, mit Daten, die Sie jetzt als nicht so weit bezeichnen, hat Ihnen bereits etwas gesagt: Für diesen Zweck waren die Daten gut genug.

Das ist möglich, weil die Anforderung an die Struktur gesunken ist. Freitext in der Wartungsdokumentation ist heute auswertbar. Die Klassifizierung muss weder vollständig noch einheitlich sein, weil die Analyse nicht mehr darauf angewiesen ist, dass sie die Bedeutung trägt. Das ist eine echte Veränderung, und die meisten Ratschläge am Markt stammen aus der Zeit davor.

Unverändert ist, dass das Ereignis überhaupt erfasst sein muss. Das ist eine andere Hürde als saubere Daten, und eine viel niedrigere. Sie liegt aber nicht bei null, und an ihr lohnt es sich zu messen.

Welche Ihrer Einträge diese Hürde nehmen, ist eine Frage mit einer echten Antwort, und sie zu klären, dauert einen Nachmittag, kein Programm: Was KI Ihren Instandhaltungsdaten verzeiht – und was nicht ist der Test.

Ein begrenzter erster Schritt

Der sinnvolle nächste Schritt ist an dieser Stelle kein größeres Datenprojekt. Es ist ein kleineres, mit einem Ende.

Was auch immer Ihr Pilotprojekt bewiesen hat, es hat es an einem abgegrenzten Ausschnitt der Daten bewiesen. Legen Sie also den nächsten Ausschnitt fest. Eine Linie, eine Anlagenklasse, ein Werk: ein Umfang, bei dem Sie sagen können, was „erfasst“ bedeutet, und prüfen können, ob es stimmt. Kein Programm, dessen Erfolgskriterium die Abwesenheit eines Problems ist.

Das ist eine Entscheidung, die ein Betriebsleiter treffen und zu Ende bringen kann. „Die Daten bereinigen“ ist das nicht, und nach zwei Jahren, in denen es nicht zu Ende gebracht wurde, überraschen die 85 % nicht.

Eines lässt dieser Umfang offen: wie vollständig der Ausschnitt sein muss, bevor seine Auswertung Ihnen etwas sagt. Die Latte liegt niedriger, als die meisten Teams annehmen. Nach Leonards Einschätzung können Sie mit mittelguten Daten anfangen. Sagen wir, 50 % der abgeschlossenen Arbeitsaufträge enthalten sowohl den Fehler als auch das, was dagegen getan wurde – oder jeder nennt den Fehler, und keiner hält die Abhilfe fest. Niemand würde das eine oder das andere als sauberen Datensatz verteidigen. Trotzdem sind in beiden Fällen die Probleme sichtbar, bei denen sich Handeln lohnt, weil genau diese Probleme wiederkehren, und Wiederholung übersteht auch eine lückenhafte Stichprobe. Was Sie damit gewinnen, ist eine Richtung: welche Anlagen und welche wiederkehrenden Ausfälle Aufmerksamkeit verdienen, nicht wie groß sie sind. Um zu entscheiden, wo Sie als Nächstes hinschauen, ist das alles, was Sie brauchen.

Das ist das Argument dafür, früh zu lesen statt spät. Fangen Sie auf halbem Weg an und lassen Sie das, was die Auswertung zeigt, bestimmen, wie sich die Erfassung verbessert. Manufacturing Intelligence ist dafür da, diesen Weg zu verkürzen, und setzt keinen Standard voraus, den Sie vorher erreichen müssen.

Einen solchen Umfang festzulegen heißt vor allem, vor dem Start drei Dinge aufzuschreiben. Keines davon verlangt eine Entscheidung für eine Plattform:

• Wo. Eine Linie, eine Anlagenklasse, ein Standort. Nicht „die Instandhaltung“.
• Was als erfasst gilt. Ein Satz, den Sie einem Techniker und einem Meister geben könnten und bei dem beide zustimmen. Wenn Sie ihn nicht schreiben können, ist der Umfang noch zu groß.
• Wann Sie hinschauen. Ein Datum im Kalender, an dem Sie eine Stichprobe lesen und prüfen, ob sich die Antwort verändert hat. Kein Meilenstein, sondern ein Termin zum Lesen.

Der dritte Punkt ist der, der unter den Tisch fällt, und er ist der, der daraus ein Projekt mit Ende macht. Ohne ihn gibt es keinen Moment, an dem jemand sagen kann, dass es funktioniert hat. Also wächst der Umfang still und leise in die Lücke hinein. Das ist derselbe Fehler wie „erst die Daten bereinigen“, nur im kleineren Maßstab.

Nichts davon ist eine KI-Entscheidung. Es ist die gewöhnliche Disziplin, mit der man eine Veränderung in der Produktion eingrenzt, angewandt auf die Erfassung statt auf eine Maschine. Es lohnt sich, das auszusprechen, weil der KI-Rahmen diese Disziplin gern außer Kraft setzt: Teams, die nie ein Instandhaltungsprojekt ohne Grenzen genehmigen würden, genehmigen ein Datenprojekt ohne Grenzen, weil das Datenprojekt nach Vorbereitung klingt und nicht nach Arbeit.

Wenn die ehrliche Antwort auf die Frage Wird das Ereignis in einem System erfasst, in dem Moment, in dem es passiert? „Nein“ lautet, weil es in einem Schichtbuch, einer Excel-Tabelle oder einem Gespräch steckt, dann ist genau dies das begrenzte Projekt, und es ist kleiner als das, das Sie gerade eingrenzen wollten. Wie Instandhaltungsabteilungen den Weg vom Papier zur digitalen Erfassung gehen, beschreibt unser Beitrag zur Digitalisierung in der Instandhaltung. Maintmaster CMMS ist eine Möglichkeit, direkt bei der Arbeit festzuhalten, was passiert ist und was dagegen getan wurde. Davon hängt jede spätere Auswertung ab.

Fangen Sie dort an. Es hat ein Ende, und genau das ist der Unterschied.