KI-gestützte Ausschussanalyse und Fehlerursachenforschung

Das echte Ausmaß des Problems

Qualitätskosten — also alles, was durch Fehler entsteht: Ausschuss, Nacharbeit, Prüfaufwand, Reklamationen, Gewährleistung — fressen bei einem durchschnittlichen Industriebetrieb zwischen 15 und 20 Prozent des Umsatzes. Das schätzt die American Society for Quality (ASQ) auf Basis langjähriger Branchenbenchmarks. In Six-Sigma-reifen Unternehmen sinkt dieser Wert auf unter fünf Prozent — die Differenz ist der sogenannte Cost of Poor Quality (COPQ), und er ist in den meisten Betrieben unsichtbar, weil er nie auf einer Rechnung erscheint.

Noch trügerischer: Der Ausschuss, den man sieht und zählt, ist nur ein Teil des Problems. Was nicht sichtbar ist, sind die Maschinenstunden, die für Nacharbeit drauflaufen, die Überproduktion zur Sicherheitspuffer-Abdeckung, die Expeditkosten, wenn eine Lieferung wegen Qualitätsproblemen neu produziert werden muss.

Warum klassische Analyse an ihre Grenzen stößt:

Manuelle Root-Cause-Analyse (RCA) — ob per Ishikawa-Diagramm, 8D-Report oder 5-Why-Methode — basiert auf dem, was Schichtführer und Qualitätsingenieure erinnern und beobachten können. Das reicht für einfache, monokausal erklärbare Fehler. Es versagt, wenn:

• Der Fehler erst bei einer spezifischen Kombination von zwei oder drei Parametern auftritt, die einzeln nie die Toleranzgrenzen verletzen
• Der Ursache-Wirkungs-Abstand zeitlich entkoppelt ist — das Material hat sich vor 48 Stunden verändert, der Ausschuss zeigt sich erst am nächsten Tag
• Der Fehler schichtabhängig variiert, aber niemand systematisch Schicht, Maschinenparameter und Materialcharge gleichzeitig ausgewertet hat
• Prozessänderungen — neuer Lieferant, neue Werkzeugcharge, justierter Maschinenparameter — so viele kleine Variablen gleichzeitig verändern, dass ein menschliches Gehirn die Kombination nicht isolieren kann

Das Fraunhofer IPA hat in seinem ProBayes-Projekt (2021–2023) gezeigt, wie Bayes’sche Netze genau dieses Problem für Spritzgussprozesse lösen: Das Modell verbindet Prozessparameter und Qualitätsmerkmale transparent miteinander, sagt voraus, welche Teile qualitätsabweichend sein werden, und diagnostiziert automatisch die wahrscheinlichsten Ursachen — ohne die Black-Box-Problematik klassischer KI-Modelle.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Basierend auf Bosch-Implementierung über drei Automotive-Component-Werke (ML-gestützte Oberflächeninspektion Bremsscheiben): 25 % Ausschussreduktion, 1,2 Mio. USD Einsparung pro Jahr. Auxiliobits-Praxisbericht: Automotive-Tier-1-Zulieferer Stanzlinie, Ausschussrate von 4–7 % auf unter 2,5 % gesenkt durch ML-gestützte Ursachenanalyse (Mikrovariationen Materialhärte × kumulierte Wärmeausdehnung).

Erkennung vs. Diagnose — warum das nicht dasselbe ist

Das ist der Punkt, an dem die meisten Projekte falsch starten: Fehlererkennung ist nicht dasselbe wie Fehlerursachenanalyse.

Computer Vision-Systeme wie die von Cognex oder Keyence erkennen zuverlässig, dass ein Teil fehlerhaft ist — Oberflächenrisse, Maßabweichungen, Farbfehler, Kontaminationen. Das ist Detection. Es beantwortet: “Ist dieses Teil gut oder schlecht?” Das ist wertvoll, ersetzt aber keine RCA.

Fehlerursachenanalyse beantwortet eine andere Frage: “Warum entstehen diese Fehler, und welche Prozessparameter lösen sie aus?” Dafür braucht es keine Kamera, sondern Zeitreihen: Maschinentemperaturen, Druckverläufe, Werkzeugstandzeiten, Materialchargendaten, Schichtzugehörigkeit, Umgebungsklima.

Viele Unternehmen investieren in automatische Fehlererkennung und wundern sich dann, dass die Ausschussquote trotzdem nicht sinkt. Detection sagt dir, was du wegwerfen musst. RCA sagt dir, wie du aufhörst, es herzustellen.

Die sinnvolle Kombination: Detection-Systeme liefern die Fehlerdaten in hoher Frequenz und Konsistenz — eine weit bessere Datenbasis als manuelle Sichtkontrolle. Die RCA-KI nutzt diese Fehlerdaten als Ziel-Variable und korreliert sie mit den Prozessdaten. Detection und Diagnose sind ergänzende Schichten, nicht Alternativen.

KI versus klassische Methoden — Ishikawa, 8D und SPC

Es lohnt sich, ehrlich zu sein: Die klassischen Methoden sind nicht wertlos. Statistische Prozesskontrolle (SPC) erkennt zuverlässig, wann ein Prozess außer Kontrolle gerät — Kontrollkarten zeigen Trends, Regelkarten schlagen Alarm bei Grenzwertüberschreitungen. Ishikawa-Diagramme und 8D-Reports strukturieren das Erfahrungswissen des Teams und sind bewährt, wenn die Fehlerursache prinzipiell erkennbar ist.

Das Problem: SPC überwacht jeden Parameter einzeln. Wenn Temperatur und Luftfeuchtigkeit je für sich innerhalb der Toleranz liegen, aber ihre Kombination Fehler verursacht, zeigt kein SPC-Chart ein Signal. KI berechnet multivariate Wechselwirkungen über alle Parameter gleichzeitig.

Die praktisch beste Kombination: SPC als Echtzeit-Wächter, der Alarm schlägt — KI als Diagnoseschicht, die dann erklärt warum.

Ein zusätzliches Risiko bei klassischen ML-Ansätzen, das in der Praxis oft unterschätzt wird: Standard-Machine-Learning-Modelle, die mit Merkmalsbedeutungs-Algorithmen wie SHAP oder LIME interpretiert werden, können Symptome als Ursachen identifizieren. Wenn Maschinenauslastung und Werkzeugverschleiß gleichzeitig korrelieren, kann das Modell die Maschinenauslastung als “wichtigstes Merkmal” ausgeben — weil sie statistisch aussagekräftiger ist —, während der Werkzeugverschleiß die eigentliche Ursache ist. Ein Qualitätsingenieur, der diesen Unterschied nicht kennt, justiert den falschen Parameter. Kausale KI-Ansätze (wie Bayes’sche Netze oder Causal ML) lösen dieses Problem explizit, sind aber technisch anspruchsvoller.

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5) Das Hauptversprechen ist nicht Zeitersparnis im Sinne von “Stunden pro Tag weniger Arbeit”, sondern drastisch kürzere Analysezyklen: Eine Root-Cause-Analyse, die zwei Wochen dauert, dauert mit KI-Support zwei Tage. Das ist im Produktionsumfeld wertvoll, weil jeder Tag, in dem die Ursache unbekannt ist, weiterer Ausschuss entsteht. Bewertet unter den Produktions-Anwendungsfällen jedoch nur mittel, weil der Zeitgewinn auf den Qualitätsingenieur konzentriert ist, nicht auf die Belegschaft insgesamt.

Kosteneinsparung — stark (4/5) Ausschuss ist einer der direktesten Kostenhebel in der Produktion: jedes vermiedene Schlechtteil spart Rohstoff, Energie und Maschinenzeit in einem. Bosch dokumentierte 25 % Ausschussreduktion und 1,2 Mio. USD jährliche Einsparung über drei Werke. Für einen Mittelständler mit 2–5 % Ausschussquote und 10 Mio. EUR Produktionsumsatz bedeutet selbst eine 20-prozentige Reduktion 40.000–100.000 EUR jährliche Ersparnis. Damit liegt dieser Anwendungsfall klar im oberen Viertel der Produktions-Use-Cases.

Schnelle Umsetzung — niedrig (2/5) Das ist der ehrlichste Wert: Ohne funktionierendes MES, Historian oder zumindest strukturiert erfasste Prozessdaten gibt es nichts zu analysieren. Realistisch vergehen 8–16 Wochen vom Projektstart bis zu einem validierten Modell — Datenaufbereitung, MES-Integration, Defekt-Labeling, Modelltraining, Validierungsphase. In der Vergleichsgruppe der Produktions-Use-Cases ist das anspruchsvoll.

ROI-Sicherheit — stark (4/5) Ausschuss ist zählbar. Die Veränderung der Ausschussrate vor und nach der Einführung ist exakt messbar, der wirtschaftliche Wert je Schlechtteil bekannt. Das macht diesen Use Case zu einem der ROI-sichersten in der Produktionskategorie — im Gegensatz zu Use Cases, bei denen der Nutzen indirekt oder schwer zuzuordnen ist.

Skalierbarkeit — mittel (3/5) Das Modell für Anlage A skaliert nicht automatisch auf Anlage B: Verschiedene Maschinen, Produkte oder Produktionsprozesse brauchen jeweils eigene Datenhistorien und Modelle. Jede Prozessveränderung — neuer Lieferant, neue Werkzeugcharge, justierter Parameter — kann ein Retraining erfordern. Das schränkt die kostenlose Skalierbarkeit ein. Gleichzeitig kann eine erfolgreiche Vorlage gut auf weitere Anlagen übertragen werden, wenn die Datenstruktur vergleichbar ist.

Richtwerte — stark abhängig von vorhandener Dateninfrastruktur, Ausschussvolumen und Prozessreife.

Was das System konkret macht

Das Herzstück ist eine Korrelationsmaschine — aber eine, die mit Zeitreihen umgehen kann.

Jede Produktion hinterlässt Spuren: Maschinentemperaturen im Minutentakt, Druckwerte, Werkzeugstandzeiten, Material-Chargen-IDs, Schichtzugehörigkeit, Hallenklima. Parallel werden Qualitätsprüfergebnisse erfasst: gut, schlecht, Nacharbeit — oder spezifischere Fehlercodes wie “Lunker”, “Bindenähte”, “Maßhaltigkeit außerhalb Toleranz”. Das KI-System verbindet beide Datenstränge.

Schritt 1 — Datenaggregation: Die Produktions- und Qualitätsdaten werden in einer einheitlichen Zeitreihe zusammengeführt. Der knifflige Teil: Ursache und Wirkung sind oft zeitlich entkoppelt. Das Material wurde um 14:00 Uhr geändert, der Ausschuss zeigt sich erst um 22:00. Das System muss verschiedene Zeitfenster (Lags) systematisch testen.

Schritt 2 — Merkmalskonstruktion: Rohdaten werden zu aussagekräftigen Merkmalen transformiert. Nicht “Temperatur um 14:23 Uhr” ist relevant, sondern “Temperaturtrend über die letzte Stunde”, “Abweichung vom Schichtstartmittelwert” oder “Anzahl der Temperaturschwankungen über Schwellenwert in der Schicht”.

Schritt 3 — Modelltraining: Ein Entscheidungsbaum-Ensemble oder ein Gradient-Boosting-Modell lernt, welche Merkmale oder Merkmalskombinationen am stärksten mit erhöhtem Ausschuss korrelieren. Das Modell liefert explizite Regeln: “Wenn Werkzeugstandzeit > 8.000 Hübe UND Granulatfeuchtigkeit > 0,4 %, dann steigt Ausschusswahrscheinlichkeit auf 18 %.”

Schritt 4 — Echtzeit-Dashboard: Im Betrieb werden diese Regeln live gegen die laufenden Prozessparameter geprüft. Sobald sich eine kritische Konstellation abzeichnet, bekommt der Schichtführer einen Hinweis — nicht erst nach dem Ausschuss, sondern bevor er entsteht.

MES- und Historiker-Integration — wo die echte Arbeit liegt

An diesem Punkt trennt sich die Theorie von der Praxis: Das KI-Modell ist nicht das Aufwändigste an einem solchen Projekt. Die Dateninfrastruktur ist es.

Welche Datenquellen müssen verbunden werden:

• MES / Fertigungsleitsystem: Auftragsdaten, Stücklisten, Schichtzuordnung, Prüfergebnisse. Siemens Opcenter oder SAP PP liefern hier die Auftragsebene. Ohne MES fehlt die Verknüpfung zwischen Produktionsauftrag und Maschinendaten.
• Historian / Prozessdaten-Archiv: Maschinensensordaten im Minutentakt oder feiner. Seeq verbindet sich direkt mit AVEVA PI, InfluxDB und anderen Historikern und macht diese Daten für Korrelationsanalysen zugänglich — ohne eigenes Data-Engineering-Team.
• Qualitätsmanagementsystem (QMS): Fehlercodes, Messergebnisse aus der Qualitätsprüfung, NCR-Dokumente. Diese müssen strukturiert und maschinenlesbar vorliegen — ein PDF-Scanstapel ist keine Datenbasis.
• ERP für Materialchargen: Welches Granulat, von welchem Lieferanten, mit welcher Chargennummer wurde wann verarbeitet? Diese Information lebt im ERP (SAP MM/PP) und muss mit den Zeitstempeln der Produktion verknüpft werden.

Der häufigste Engpass: Betriebe haben die Daten, aber sie sind nicht miteinander verbunden. Die Maschinentemperatur sitzt im SPS-Log als CSV, der Ausschuss im QMS, die Materialcharge im ERP — drei Systeme, kein gemeinsamer Schlüssel. Bevor ein Modell trainiert werden kann, muss ein Datenpipeline-Projekt stattfinden. Das kann 2–4 Wochen extra kosten, die im Budget oft nicht eingeplant sind.

Der zweite Engpass: Defekt-Labels. Das Modell braucht konsequent kategorisierte Fehlerbilder: Nicht “Ausschuss”, sondern “Lunker Typ 1”, “Bindenahtriss”, “Gratbildung”. Wenn das QMS seit Jahren mit inkonsistenten Freitexteingaben arbeitet, ist die erste Aufgabe keine KI, sondern ein Defekt-Taxonomie-Workshop.

Was ISO 9001 und IATF 16949 von eurer Analyse verlangen

In regulierten Produktionsumgebungen — und in Automotive faktisch immer — ist die RCA kein optionaler Schritt, sondern Pflicht.

ISO 9001:2015 (Abschnitt 10.2) verlangt bei Nichtkonformitäten eine Ursachenanalyse und dokumentierte Korrekturmaßnahmen (Corrective Action / Preventive Action = CAPA). Die Analyse muss nachvollziehbar sein, die Maßnahmen müssen verfolgt werden.

IATF 16949 (Automotive) geht weiter: 8D-Reports sind de facto Pflicht bei Lieferantenreklamationen, die Ursachenanalyse muss auf Systemebene erfolgen (nicht nur Symptomkorrektur), und die Wirksamkeit der CAPA muss belegt werden.

Was das für euer KI-Projekt bedeutet:

1. Das System muss seine Ursachenhypothesen dokumentieren können — mit Zeitstempel, Konfidenzwert, zugrundeliegenden Daten. Ein Black-Box-Modell, das nur “Werkzeugverschleiß” sagt, ohne die Datenbasis offenzulegen, erfüllt diese Anforderung nicht.
2. Die Entscheidung für eine Korrekturmaßnahme bleibt beim Qualitätsingenieur — das KI-System liefert Input für den 8D-Report, ersetzt ihn nicht.
3. Modellausgaben müssen als Teil des QMS-Workflows integriert sein, nicht als separates Dashboard, das niemand zitiert.

Praktische Empfehlung: Kläre vor dem Kauf jedes Systems, ob es eine ISO-9001-konforme Audit-Trail-Funktion hat und ob die Outputs in bestehende QMS-Systeme (z.B. SAP QM, Opcenter Quality) exportiert werden können.

Konkrete Werkzeuge — was wann passt

Seeq — wenn ihr einen Historian habt Seeq ist die stärkste Wahl für Betriebe mit AVEVA PI, InfluxDB oder einem anderen Prozessdaten-Historiker. Qualitätsingenieure können ohne Programmierkenntnisse Korrelationen, Scatter-Plots und Trendanalysen über historische Prozessdaten laufen lassen. Mit dem Seeq Data Lab (Python) sind auch Gradient-Boosting-Modelle direkt auf den Zeitreihendaten trainierbar. Lizenz: ca. 1.000–1.200 USD/Nutzer/Jahr; kein US-Datenproblem (EU-Hosting verfügbar). Einschränkung: Sinnvoll erst, wenn ein Historian vorhanden ist.

Siemens Opcenter Quality — wenn ihr MES-integriert arbeiten wollt Siemens Opcenter Quality bietet SPC-Integration, Prüfplanverwaltung, NCR-Workflows und — über das Opcenter Intelligence-Modul — BI-gestützte Qualitätsanalysen. Für Betriebe, die bereits im Siemens-Ökosystem sind oder eine vollständige MOM-Suite einführen wollen, ist das die tiefste Integration. Kosten: Five- bis sechsstellige Jahreskosten je nach Modulpaket. Nicht für Betriebe unter 50 Mitarbeitern.

Dataiku — wenn ihr ein internes Data-Science-Team habt Dataiku ermöglicht es Mixed-Teams aus Qualitätsingenieuren und Data Scientists, Ausschuss-RCA-Modelle mit einem visuellen ML-Flow-Builder zu entwickeln. Besonders stark, wenn mehrere Datenquellen (MES, Historian, ERP) in einer gemeinsamen Pipeline verbunden werden müssen. Community Edition kostenlos für Einzelnutzer; Unternehmenslizenzen ab ca. 26.000 USD/Jahr.

Cognex / Keyence — als Defektdaten-Lieferant Automatische visuelle Inspektionssysteme liefern konsistente, hochfrequente Fehlerdaten — eine weit bessere RCA-Datenbasis als manuelle Sichtkontrolle mit Freitexteingaben. Wenn eure Defekterfassung noch auf Augenschein beruht, ist die Einführung eines Vision-Systems der erste Schritt, bevor ihr an KI-gestützte RCA denkt.

Grafana + InfluxDB — die Open-Source-Basis Wer mit minimaler Investition starten will: InfluxDB als Zeitreihendatenbank, Grafana für das Dashboard. Kein ML out of the box, aber exzellent für die erste Datenvisualisierung — Ausschussrate über Zeit, korreliert mit Maschinenparametern. Sobald ihr seht, welche Signale interessant sind, kann darauf aufgebaut werden. Beides Open Source, Hosting auf eigenem Server oder EU-Cloud.

Zusammenfassung — wann welcher Ansatz:

• Historian vorhanden, Qualitätsingenieur will selbst analysieren → Seeq
• Siemens-Ökosystem, MES-Integration gesucht → Siemens Opcenter Quality + Intelligence
• Eigenes Data-Science-Team, Multi-Source-Pipeline → Dataiku
• Defekterfassung noch manuell → Cognex oder Keyence zuerst
• Niedrigbudget-Einstieg, Pilotphase → Grafana + InfluxDB

Datenschutz und Datenhaltung

Ausschussanalyse-Systeme verarbeiten primär Maschinendaten, Prozessparameter und Qualitätskennzahlen — keine personenbezogenen Daten im klassischen Sinne. Trotzdem gibt es zwei Bereiche mit DSGVO-Relevanz:

Mitarbeiterbezogene Produktionsdaten: Wenn das System mit Schicht-IDs, Bediener-IDs oder Werker-Logins arbeitet — also wenn protokolliert wird, wer welches Teil produziert hat —, handelt es sich um personenbezogene Daten. Das ist häufig gewollt (Schichtvergleich als Ursachenvariable), erfordert aber eine Betriebsvereinbarung und die frühzeitige Einbindung des Betriebsrats.

Cloud-Hosting von Produktionsdaten: Für viele Betriebe ist das Datenhosting-Thema weniger juristisch als strategisch: Maschinendaten, Rezepturen und Prozessparameter können Betriebsgeheimnisse sein. On-Premises-Lösungen (Seeq selbst gehostet, Dataiku on-premise, Opcenter on-premise) vermeiden die Frage nach Cloud-Datensicherheit komplett.

• Seeq: EU-Hosting-Option verfügbar; AVV erhältlich
• Siemens Opcenter: On-Premises oder EU-Rechenzentrum; AVV abschließbar
• Dataiku: On-Premises und EU-Cloud-Deployment; AVV auf Anfrage
• Grafana + InfluxDB: Open Source, selbst gehostet → volle Datenkontrolle

Was es kostet — realistisch gerechnet

Einmalige Projektkosten

Laufende Kosten (monatlich)

• Seeq Lizenz: ca. 85–100 EUR/Nutzer/Monat (1–2 Qualitätsingenieure → 100–200 EUR/Monat)
• Dataiku Community: kostenlos für Einzelnutzer; Enterprise ab ca. 2.200 EUR/Monat
• Siemens Opcenter Intelligence: Modulkosten, ab ca. 2.500–8.000 EUR/Monat im Enterprise-Bereich
• Grafana + InfluxDB (selbst gehostet): Hosting-Kosten ca. 50–200 EUR/Monat

ROI-Szenario: Mittelständischer Zulieferer

• Umsatz: 15 Mio. EUR, Ausschussquote aktuell: 3,2 %, Materialwert je Schlechtteil: 45 EUR durchschnittlich
• Ausschusskosten p.a. (nur Material): ~480.000 EUR (nicht eingerechnet: Maschinenzeit, Energie, Nacharbeit, Prüfaufwand)
• 25 % Ausschussreduktion: ~120.000 EUR jährliche Einsparung
• Break-even bei Projektkosten von 40.000 EUR: unter 5 Monate

Wie du den ROI tatsächlich nachweist: Messinstrument ist die Ausschussrate je Anlage / Schicht / Produkt — die gleiche Kennzahl, die du vorher schon erfasst hast. Vergleich: 12 Wochen vor Einführung vs. 12 Wochen nach stabiler Systemnutzung. Ohne dieses Baseline-Dokument kein ROI-Nachweis — leg es am ersten Projekttag an.

Drei typische Einstiegsfehler

1. Detection und Diagnose verwechseln — ein neues Kamerasystem kaufen und hoffen, dass die Ausschussquote sinkt. Eine automatische Bildinspektion erkennt Fehler, eliminiert sie aber nicht. Wenn die Ursache — veraltetes Werkzeug, falscher Prozessparameter, schwankende Materialqualität — nicht adressiert wird, produziert ihr weiterhin fehlerhafte Teile, erkennt sie jetzt nur schneller. Der Nutzen von Detection liegt in konsistenter Datenbasis und frühzeitiger Aussortierung — nicht in weniger Ausschuss an der Quelle.

2. Mit sauberem Freitext-QMS in die KI-Anbindung starten. “Ausschuss wegen Maschine” ist kein Fehlerkode — es ist eine Notiz. Ein Machine-Learning-Modell kann nur klassifizieren, was es gelernt hat. Wer ohne strukturierte Defekt-Taxonomie (einheitliche Fehlerkodes, konsistent seit mindestens 6 Monaten erfasst) in ein RCA-Projekt geht, verbringt die ersten 4–6 Wochen mit Datenbeschriftung statt Analyse. Fehler: Das ist im Budget nicht geplant, es frisst die Hälfte der Projektlaufzeit.

3. Modell einmal trainieren und für immer laufen lassen. Das ist der gefährlichste Fehler — weil er still passiert.

Nach 6 Monaten kommt ein neuer Lieferant. Nach 9 Monaten werden Werkzeuge von einem anderen Hersteller eingesetzt. Nach 12 Monaten ändert sich der Maschinenpark um eine Anlage. Das Modell wurde auf alten Bedingungen trainiert — und gibt jetzt Ursachenhypothesen aus, die auf den aktuellen Prozess nicht mehr zutreffen. Der Schichtführer handelt nach veralteten Empfehlungen. Das System klingt zuverlässig und irrt sich.

Retraining-Trigger müssen von Anfang an definiert sein: Bei welchen Prozessänderungen wird das Modell neu bewertet? Wer ist verantwortlich? Wer darf entscheiden, dass eine Ursachenhypothese nicht mehr plausibel ist? Eine namentliche Zuständigkeit — nicht “die IT”, nicht “alle” — ist Pflicht.

Was mit der Einführung wirklich passiert — und was nicht

Die Technik ist nicht das Problem. Das Problem ist, dass ein KI-System eine Aussage trifft, die dem Erfahrungswissen widerspricht — und der Qualitätsingenieur, der 15 Jahre Intuition für diese Maschine hat, dem System nicht vertraut.

Das klassische Widerstandsmuster: Das Modell sagt “Materialcharge”, der erfahrene Schichtführer sagt “das war Werkzeugverschleiß, das hab ich immer schon gewusst.” Beide können recht haben — Ausschuss hat oft mehrere gleichzeitig aktive Ursachen. Aber wenn das erste Modell-Ergebnis gegen die Intuition des Teams läuft, und das Team die Maßnahme nicht umsetzt und das Modell danach “falsch liegt”, ist das Vertrauen weg.

Was konkret hilft:

• Die ersten Ursachenhypothesen des Modells sollten Fälle sein, die das Team schon kennt und versteht — bekannte Probleme, bei denen ihr wisst, was die Ursache ist. So kann das Team validieren, ob das Modell das “richtig” lernt, bevor es auf unbekannte Fälle vertraut.
• Ergebnis-Kommunikation als Hypothese formulieren, nicht als Anweisung: “Das Modell legt nahe, dass Werkzeugstandzeit > 9.000 Hübe mit Ausschuss korreliert — stimmt das mit eurer Beobachtung überein?” ist akzeptabler als “Werkzeug wechseln jetzt.”
• Den Qualitätsingenieur nicht ersetzen — ihn mit besseren Daten ausstatten. Das System nimmt ihm die Wochenarbeit für die Datenaggregation ab; die Qualitätsbeurteilung bleibt bei ihm.
• 90-Tage-Pilotbewertung kommunizieren: Noch keine Entscheidungen basierend auf dem Modell — erst Beobachtung, dann Vertrauen aufbauen.

Was nicht passiert: Das System findet nicht automatisch alle Ursachen. Es gibt Fehler, die durch externe Faktoren entstehen, die im System nicht erfasst sind — Lieferantenqualität, die nur im Lieferantenportal dokumentiert ist, Bearbeitungsfehler, die nicht protokolliert wurden. Das Modell ist so gut wie die Daten, die es sieht.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

“Wir haben zu wenig Daten.” Das ist manchmal wahr — und dann ein echtes Ausschlusskriterium. Weniger als 500–1.000 dokumentierte Ausschussereignisse mit bekannten Fehlercodes über mindestens 6 Monate reichen für kein belastbares Modell. Das ehrliche Gegenmittel: Zuerst die Datenerfassung verbessern (strukturierte Fehlercodes, konsistente Erfassung), dann in 12–18 Monaten KI-Projekte starten. Was hingegen nicht zutrifft: “Wir haben zu wenig Daten” als Reflexantwort, wenn in Wahrheit Maschinendaten im SPS-Log, Qualitätsdaten im QMS und Materialchargen im ERP vorliegen — nur nicht miteinander verbunden.

“Das hat unser Qualitätsingenieur auch so erkannt.” Wenn euer Qualitätsingenieur die Ursachen verlässlich und schnell findet: gut. Dann ist dieser Use Case tatsächlich nicht der dringendste. KI-gestützte RCA hat dann ihren Wert, wenn die Fehlerrate hoch ist, die Analyse viel Zeit bindet, oder wenn die erfahrenen Leute irgendwann das Unternehmen verlassen und das Wissen nicht dokumentiert ist. Letzteres wird in deutschen Mittelstandsbetrieben mit alternder Belegschaft zunehmend relavant.

“Wir sind nach ISO 9001 zertifiziert — KI-Ausgaben sind nicht auditierbar.” KI-Ausgaben sind auditierbar, wenn sie dokumentiert und mit menschlicher Überprüfung verknüpft sind. Der 8D-Report bleibt ein menschlich unterschriebenes Dokument — das System liefert die Datenbasis, nicht die finale Ursachenentscheidung. Kein Auditor verlangt von dir, dass du keine modernen Werkzeuge einsetzt. Er verlangt, dass du die Entscheidung nachvollziehbar dokumentierst.

Woran du merkst, dass das zu dir passt

• Deine Ausschussquote liegt konstant über 1,5–2 % und du weißt nicht sicher, warum — Theorien gibt es viele, aber keine nachgewiesene Ursachenkette
• RCA-Zyklen dauern bei euch länger als eine Woche und in dieser Zeit läuft die Produktion mit dem Fehler weiter
• Ihr produziert in hoher Stückzahl (mind. 200–500 Teile/Schicht): genug Datenpunkte für statistische Signifikanz
• Maschinendaten werden digital erfasst — SPS-Logs, Historian, oder zumindest strukturierte Schichtprotokolle liegen vor
• Ihr habt einen Qualitätsingenieur, der die Hypothesen des Systems bewerten und in CAPA-Workflows übersetzen kann
• Die Fehler sind reproduzierbar und nicht rein zufällig — wenn Ausschuss immer dann steigt wenn “irgendetwas schief läuft”, ohne erkennbares Muster, ist Prozessstabilisierung der erste Schritt

Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:

1. Unter 100 Ausschussteilen pro Schicht über mindestens 6 Monate dokumentiert. Zu wenig Signal für ein belastbares Modell. SPC + strukturierte manuelle Analyse liefern besseren ROI.

2. Kein MES, kein Historian, keine strukturierten Prozessdaten. Wenn Produktionsdaten in Notizbüchern, Excel-Tabellen oder SPS-Logs ohne Zeitstempel-Synchronisation vorliegen, ist der Dateninfrastruktur-Aufwand größer als der KI-Nutzen. Schritt eins ist dann ein Digitalisierungsprojekt, kein KI-Projekt.

3. Keine stabile Defekt-Taxonomie seit mindestens 6 Monaten. Ein Modell lernt Kategorien, keine Freitexte. Wer heute “Ausschuss wegen Maschine” schreibt und morgen “Materialfehler?” — mit Fragezeichen —, hat keine Trainingsdaten, hat eine Kommentarsammlung.

Das kannst du heute noch tun

Auch ohne Historian, MES-Integration oder Dateninfrastruktur kannst du heute testen, ob KI-gestützte RCA für deine Situation grundsätzlich Sinn ergibt.

Exportiere die letzten 3 Monate eurer Schichtdaten: Ausschussanzahl je Schicht, Fehlercodes, Maschinenparameter (auch wenn nur die Grenzwertüberschreitungen protokolliert sind). Kopiere diese Daten in eine Tabelle und leg sie einem LLM vor — mit dem Prompt unten.

Was du danach weißt: Welche Muster auf den ersten Blick auffällig sind, welche Daten fehlen, und ob das Datenvolumen für eine KI-Analyse grundsätzlich ausreicht. Das dauert 30 Minuten und kostet nichts.

Quellen & Methodik

• Fraunhofer IPA, ProBayes-Projekt (2021–2023): Einsatz Bayes’scher Netze zur Echtzeit-Qualitätsüberwachung und automatisierten Ursachendiagnose in Spritzgussprozessen; transparente Verknüpfung von Expertenwissen und Maschinendaten ohne Black-Box-Problematik. ipa.fraunhofer.de/de/referenzprojekte/ProBayes.html
• Bosch ML-Implementierung (Automotive): Drei Werke für Bremsscheiben-Oberflächeninspektion, 25 % Ausschussreduktion, 1,2 Mio. USD jährliche Einsparung; Defekterkennungsrate von 89 % (manuell) auf 97,6 % (KI-gestützt). Quelle: tech-stack.com AI Adoption in Manufacturing Insights Report (2024).
• ASQ Cost of Poor Quality (COPQ): American Society for Quality — COPQ 15–20 % des Umsatzes als Branchenbenchmark für durchschnittliche Industriebetriebe; Best-in-Class unter 5 %. qualitydigest.com / autodesk.com/blogs/design-and-manufacturing/copq
• Correlation vs. Causation in ML-RCA: Databricks Blog “Manufacturing Root Cause Analysis with Causal AI” (2023): Standard-ML-Modelle (SHAP/LIME) können Symptome als Ursachen identifizieren — kausale Methoden wie Bayes’sche Netze oder Causal ML adressieren dieses Problem explizit. databricks.com/blog/manufacturing-root-cause-analysis-causal-ai
• Frontiers in Manufacturing Technology (2022): Systematisches Review zu Machine-Learning-Methoden für RCA in Richtung Zero-Defect Manufacturing — Überblick Datengetriebene und hybride Ansätze. frontiersin.org/journals/manufacturing-technology/articles/10.3389/fmtec.2022.972712
• ISO 9001:2015 Abschnitt 10.2 (Nichtkonformität und Korrekturmaßnahmen): Normative Anforderungen an dokumentierte CAPA-Prozesse. DIN EN ISO 9001:2015, aktuelle Fassung.
• Preis- und Lizenzinformationen: Seeq (seeq.com Preisseite, Stand April 2026), Dataiku (PriceLevel.com Käuferdaten 2024, Stand April 2026), Siemens Opcenter (Siemens Vertriebsunterlagen, Stand April 2026).

Du willst wissen, welche eurer Datenquellen für eine KI-RCA grundsätzlich geeignet sind und welcher Einstiegspunkt den besten ROI verspricht? Meld dich — das klären wir in einem kurzen Gespräch.