+150 XP

Warum KI-Projekte in der Fertigung nach dem Pilot stecken bleiben

# Warum KI-Projekte in der Fertigung nach dem Pilot stecken bleiben

Ein Computer-Vision-System zur Erkennung von Schweißfehlern erreichte in einem Pilotwerk in Ohio 98 % Genauigkeit. Die Schichtleiter waren begeistert. Sechs Monate später scheiterte dasselbe Modell in einem Schwesterwerk in Polen so deutlich, dass die Bediener anfingen, es zu umgehen: Sie gaben Teile, die das System als fehlerhaft markiert hatte, manuell frei, nur um die Linie am Laufen zu halten. Gleicher Anbieter, gleiches Modell, gleiche Fehlerart. Was ist schiefgelaufen?

Am Algorithmus hatte sich nichts geändert. Geändert hatten sich der Kamerawinkel, die Umgebungsbeleuchtung, die Oberflächenbeschaffenheit der Metalllegierung und die Tatsache, dass das Qualitätsteam im polnischen Werk nie gefragt worden war, wie das Tool seine Arbeit verändern würde. Das ist das häufigste Fehlermuster bei KI in der Fertigung, und es erklärt, warum so viele Projekte nie über eine einsame Pilotlinie hinauskommen.

Die Lücke zwischen Pilot und Skalierung, in Zahlen

Die Schätzungen schwanken, aber mehrere Branchenstudien (Gartner, McKinsey, BCG, circa 2023 bis 2025) beziffern den Anteil der KI-Piloten, die in den vollen Produktivbetrieb skalieren, durchgängig auf 20 % bis 30 %. Das heißt: Etwa 7 von 10 KI-Piloten in der Fertigung, die „funktionieren", werden nie zu operativen Systemen, die an mehreren Standorten genutzt werden.

Das gilt nicht nur für die Fertigung, aber die Fertigung hat Eigenschaften, die die Lücke vergrößern:

  • Physische Variabilität zwischen Standorten. Ein Modell, das auf Beleuchtung, Kameras und Materialien eines Werks trainiert wurde, lässt sich oft nicht übertragen.
  • Legacy-Infrastruktur. Speicherprogrammierbare Steuerungen (PLCs, die Industrierechner, die Maschinen steuern) und Manufacturing Execution Systems (MES, die Software, die die Produktion in Echtzeit verfolgt) unterscheiden sich je nach Werk, manchmal je nach Installationsjahrzehnt.
  • Belegschaft und Betriebsratsdynamik. Änderungen an Prüf- oder Instandhaltungsabläufen betreffen Arbeitsrollen direkt, nicht abstrakt.

Fehlermuster 1: Das Modell generalisierte nicht, aber niemand hat es getestet

Der Fall Ohio-Polen ist ein Data-Drift-Problem: Die statistischen Eigenschaften der neuen Daten passen nicht mehr zu dem, worauf das Modell trainiert wurde. In der Computer Vision zeigt sich das als Unterschied bei Beleuchtung, Kamerawinkel, Bauteilausrichtung oder Oberflächenbeschaffenheit.

Gute Evaluationspraxis fängt das vor dem Rollout ab, nicht danach:

Pilot validation checklist (vision QC example):
1. Test model on data from 2+ physical sites, not just the pilot site
2. Vary lighting conditions and camera angles in test set
3. Include seasonal variation if outdoor or unconditioned space
4. Report accuracy PER SITE, not blended average
5. Define minimum acceptable accuracy before deployment, in writing

Der gemittelte Durchschnitt ist die Falle. Ein Modell, das in Ohio 98 % und in Polen 81 % genau ist, erscheint als „91 % Durchschnittsgenauigkeit", was in Ordnung klingt und das eigentliche Problem verdeckt.

Fehlermuster 2: Der ROI-Case ignorierte die Integrationskosten

Piloten laufen fast immer auf geliehener Infrastruktur: ein Laptop, eine Ersatzkamera, der Rechner eines Data Scientist mit einem Jupyter Notebook. Skalieren heißt, sich mit dem MES, dem PLC-Netzwerk und oft einem Enterprise-Resource-Planning-System (ERP) zu verbinden, das vor einem Jahrzehnt von einem Anbieter konfiguriert wurde, den es nicht mehr gibt.

Eine grobe Faustregel von KI-Implementierern in der Fertigung: Der Pilot selbst macht oft 10 bis 20 % der Gesamtprojektkosten aus. Integration, Change Management und Multi-Site-Rollout machen den Rest aus. Projekte, die den Pilot budgetieren, aber nicht die Skalierungsphase, gehen genau an dem Punkt das Geld und die Geduld des Managements aus, an dem der eigentliche Wert entstehen würde.

Einfaches Rechenbeispiel. Angenommen, ein Pilot zur Fehlererkennung kostet 150.000 $ (Schätzung, illustrativ) und weist eine prognostizierte jährliche Einsparung von 400.000 $ pro Linie durch weniger Ausschuss aus. Das sieht nach einer starken Rendite aus. Aber die Skalierung auf 12 Werke erfordert pro Standort Kamerainstallation, Netzwerk-Upgrades und Schulung lokaler Mitarbeiter, geschätzt 80.000 $ pro Standort. Das sind allein 960.000 $ Rollout-Kosten, vor jeglicher Softwarelizenzierung. Die Einsparung pro Linie kann außerhalb des Best-Case-Pilotstandorts ebenfalls schrumpfen. Der ROI des Piloten und der ROI des Programms sind unterschiedliche Rechnungen, und für einen CFO zählt nur die zweite.

Fehlermuster 3: Change Management, nicht Technologie

Bediener, die um ihren Arbeitsplatz fürchten oder die nie gefragt wurden, wie ein Tool funktionieren sollte, finden Wege, es auszuhebeln. Das ist in der Adoptionsforschung gut dokumentiert (siehe die laufende Berichterstattung der MIT Sloan Management Review zu KI und Akzeptanz in der Belegschaft) und gilt nicht nur für die Fertigung, aber die Werkshalle macht Widerstand leicht: den Sensor als defekt melden, die Markierung übersteuern oder einfach aufhören, Daten konsistent einzugeben.

Erfolgreiche Rollouts behandeln die Mitarbeiter an der Linie als Stakeholder im Systemdesign, nicht als Endnutzer, die ein fertiges Tool erhalten. Praktische Maßnahmen, die in erfolgreichen Programmen auftauchen:

  • Qualitätsprüfer in das Labeling der Trainingsdaten einbeziehen (sie wissen bereits, wie ein Fehler aussieht)
  • Bedienern einen expliziten Override-Pfad mit Logging geben, kein stilles Umgehen
  • Performance-Kennzahlen mit dem Team teilen, nicht nur Management-Dashboards

Fehlermuster 4: Kein klarer Owner nach Ende des Piloten

Piloten werden meist von einem Data-Science-Team, einer Innovationsgruppe oder dem Solutions Engineer eines Anbieters betrieben. Sobald der Pilot die Machbarkeit belegt, muss die Verantwortung an den Werksbetrieb und die IT übergehen. Diese Übergabe findet häufig nicht statt, und das System wird zur Waise: Niemand ist dafür zuständig, das Modell neu zu trainieren, wenn eine neue Teilenummer eingeführt wird, niemand verantwortet den Wartungsvertrag, niemand eskaliert, wenn die Genauigkeit nachlässt.

Eine nützliche Governance-Frage für jedes KI-Deployment in der Fertigung: Wer ist sechs Monate nach Go-live für die Genauigkeit dieses Modells verantwortlich, und in welchem Rhythmus überwacht diese Person es? Wenn es darauf keine namentliche Antwort gibt, ist das Projekt nicht skalierungsreif.

Wissenscheck

1. Was war im Beispiel Ohio-Polen mit den Schweißfehlern die Grundursache für das Scheitern des Modells im zweiten Werk?

2. Warum ist die Lücke zwischen Pilot und Skalierung in der Fertigung tendenziell größer als in vielen anderen Branchen, die KI einführen?

3. Was zeigt das Verhalten der Bediener im polnischen Werk, markierte Teile zu umgehen, am unmittelbarsten?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten dazu, warum ein KI-Pilot in der Fertigung, der in einem Werk hohe Genauigkeit erreicht, in einem anderen Werk scheitern kann.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten zur Statistik, dass nur 20-30 % der KI-Piloten in der Fertigung in den Produktivbetrieb skalieren.

Wählen Sie alle richtigen Antworten aus.

Wie gute Evaluation vor der Skalierung aussieht

Bevor Kapital für einen Multi-Site-Rollout gebunden wird, deckt eine belastbare Evaluation ab:

1. Multi-Site-Datenvalidierung. Test auf Daten, die das Modell nie gesehen hat, von mindestens einem weiteren physischen Standort.

2. Gesamtkosten der Skalierung, nicht nur Pilotkosten. Integration, Hardware pro Standort, Nachschulung und laufendes Monitoring.

3. Eine definierte Genauigkeitsuntergrenze mit Rollback-Plan. Bei welcher Genauigkeit wird pausiert? Wer entscheidet?

4. Plan zur Einbindung der Belegschaft. Wer wurde konsultiert, und welche Änderungen im täglichen Arbeitsablauf sind zu erwarten?

5. Benannter Owner nach dem Pilot. Eine Person oder ein Team, das für das System verantwortlich ist, nachdem das Pilotteam weiterzieht.

Hersteller, die diese Strenge anwenden, fahren tendenziell weniger, dafür größere Piloten mit crossfunktionalem Buy-in von Anfang an, statt vieler kleiner Piloten, die jedes Mal skeptischen Werksleitern neu verkauft werden müssen. Siemens, Bosch und Schneider Electric haben Fallmaterial veröffentlicht (über ihre eigene Investoren- und Innovationskommunikation), das Multi-Site-Validierung als Voraussetzung für die Skalierung von Vision- und Predictive-Maintenance-Systemen betont, ein Signal, dass diese Lektion anderswo teuer gelernt wurde.

🎬 [VIDEO: "Why AI Projects Fail in Manufacturing" - youtube.com - Suchen Sie nach aktuellen (2024-2025) Konferenzvorträgen zu KI in der Fertigung von MESA International oder Branchenanalysten zu Fehlermustern beim Übergang vom Pilot zur Skalierung, eine gute visuelle Ergänzung zur Fehlertaxonomie dieser Lektion.]

Eine Anmerkung zu realistischen Erwartungen

KI-Anbieter kalkulieren und pitchen oft auf Basis der Performance am Pilotstandort. Behandeln Sie jede Genauigkeitszahl aus der Anbieterbroschüre als Obergrenze, nicht als Garantie. Fragen Sie konkret: „Wie hoch war die Genauigkeit an Standorten, die Sie nicht für Training oder Tuning genutzt haben?" Wenn der Anbieter darauf keine Antwort hat, ist das für sich genommen schon aufschlussreich.

Die wichtigsten Erkenntnisse

  • Rund 70 bis 80 % der KI-Piloten in der Fertigung (Branchenschätzungen, 2023 bis 2025) kommen nie über den Pilotstandort hinaus; die Hauptursachen sind Data Drift zwischen Werken, unterschätzte Integrationskosten, Widerstand in der Belegschaft und unklare Verantwortung nach dem Pilot.
  • Bewerten Sie die Modellleistung immer pro Standort, nicht als gemittelten Durchschnitt. Eine starke Pilotzahl kann schwache Generalisierung verdecken.
  • Budgetieren Sie Skalierungskosten getrennt von Pilotkosten. Piloten machen üblicherweise 10 bis 20 % der Gesamtprogrammkosten aus; Integration und Multi-Site-Rollout den Rest.
  • Binden Sie Bediener und Prüfer an der Linie vor dem Rollout in das Systemdesign ein, nicht danach. Nicht eingebundene Mitarbeiter können KI-Tools, denen sie misstrauen, still aushebeln, und sie tun es.
  • Benennen Sie vor der Skalierung einen konkreten Owner, der für die Modellgenauigkeit nach dem Deployment verantwortlich ist, und legen Sie einen Rollback-Schwellenwert schriftlich fest.