Qualitätsprüfung kommt in der klassischen Fertigung am Ende. Das Teil ist produziert, wird geprüft – und dann zeigt sich, ob es passt oder nicht. Wenn nicht: Ausschuss, Nacharbeit, Reklamation. Die Reaktion auf ein Qualitätsproblem ist immer retrospektiv: Etwas ist schiefgelaufen, jetzt wird analysiert, warum.
Predictive Quality dreht diese Logik um. Statt nach der Produktion zu prüfen, ob ein Teil gut ist, wird während der Produktion prognostiziert, ob ein Teil gut werden wird – basierend auf Prozessparametern, Maschinendaten und historischen Mustern. Die Qualitätsprüfung verschiebt sich von der Endkontrolle in die Prozesssteuerung.
Das klingt nach Zukunftsmusik. Ist es aber nicht. Die zugrundeliegenden Technologien – maschinelles Lernen, Prozessdatenintegration, Echtzeit-Monitoring – sind ausgereift. Der limitierende Faktor ist nicht die Technologie, sondern die Datenbasis: Wer Predictive Quality einführen will, braucht keine KI-Spezialisten, sondern erst einmal vollständige, verknüpfte Prozessdaten.
Dieser Artikel erklärt, was Predictive Quality konkret bedeutet, welche Daten ihr braucht, wie typische ML-Workflows funktionieren und wo die Methode in der Praxis bereits messbare Ergebnisse liefert.
DAS WICHTIGSTE IN KÜRZEPredictive Quality prognostiziert die Qualität eines Teils während der Fertigung – nicht danach. Grundlage sind Prozessparameter, Maschinendaten und historische Qualitätsergebnisse, die durch ML-Modelle zu einer Fehlerwahrscheinlichkeit verdichtet werden. Der kritische Erfolgsfaktor ist nicht das ML-Modell, sondern die Datenbasis. Predictive Quality erfordert vollständige, zeitlich synchronisierte Daten: Prozessparameter je Seriennummer, Qualitätsmerkmal je Seriennummer, Zeitstempel maschinengesetzt. Ohne diese Verknüpfung fehlt die Trainingsgrundlage. Typische Use Cases sind Inline-Fehlerprognose, adaptive Prüfplanung und Frühwarnung bei Prozessdrift. Die größten Effekte entstehen bei hohen Prüfkosten (zerstörende Prüfung, Laboranalysen) oder hohen Ausschusskosten (teure Bauteile, späte Fehlerentdeckung). Der Einstieg ist einfacher als erwartet: Ein erster Proof of Concept mit einem Merkmal, 3–6 Monaten Historiedaten und einem Random-Forest-Modell liefert in 2–4 Wochen erste Ergebnisse – ohne Data-Science-Team. |
KURZ ZUSAMMENGEFASSTPredictive Quality ist keine Ersetzung der Qualitätsprüfung – es ist ihre Vorverlagerung. Das Ziel ist nicht, Prüfungen abzuschaffen, sondern Fehler zu erkennen, bevor sie entstehen. Die Kernfrage bei Predictive Quality lautet: Welche Prozessparameter-Konstellation führt mit welcher Wahrscheinlichkeit zu einem Qualitätsproblem? Die Antwort steckt in euren Daten – wenn sie verknüpft sind. ML-Modelle sind nur so gut wie ihre Trainingsdaten. Ein perfekter Algorithmus auf schlechten Daten liefert schlechte Vorhersagen. Datenqualität ist der Engpass, nicht Modellkomplexität. |
Was Predictive Quality konkret bedeutet – und was nicht
Predictive Quality ist ein datengetriebener Ansatz, der die wahrscheinliche Qualität eines Produkts vor oder während der Fertigung prognostiziert – basierend auf Prozessparametern, Maschinenzuständen und historischen Mustern.
| Traditionelle Qualitätsprüfung | Predictive Quality | |
|---|---|---|
| Zeitpunkt | Nach der Fertigung (Endprüfung) | Während der Fertigung (Inline-Prognose) |
| Fragestellung | Ist dieses Teil gut? | Wird dieses Teil gut? |
| Datenbasis | Prüfergebnis des einzelnen Teils | Prozessparameter + historische Muster |
| Reaktionszeit | Reaktiv: Fehler ist bereits entstanden | Proaktiv: Eingriff vor Fehlerentstehung |
| Prüfumfang | 100 % oder Stichprobe – unabhängig vom Risiko | Risikobasiert: mehr Prüfung bei hoher Fehlerwahrscheinlichkeit |
Die drei Kernelemente von Predictive Quality
1. Prozessparameter als Qualitätsindikatoren
Jedes Qualitätsmerkmal – Maßhaltigkeit, Festigkeit, Oberflächengüte – wird durch Prozessparameter beeinflusst: Temperatur, Druck, Drehzahl, Vorschub, Zykluszeit, Werkzeugzustand. Predictive Quality identifiziert, welche Parameterkombinationen historisch zu Qualitätsproblemen geführt haben.
2. Maschinelles Lernen zur Mustererkennung
ML-Modelle erkennen komplexe, nicht-lineare Zusammenhänge zwischen Prozessparametern und Qualitätsergebnissen – Zusammenhänge, die für Menschen nicht sichtbar sind. Ein Modell lernt aus historischen Daten: „Wenn Temperatur > X und Druck < Y und Werkzeugalter > Z, dann Fehlerwahrscheinlichkeit = 73 %."
3. Inline-Integration für Echtzeitprognose
Das trainierte Modell wird in die Produktionslinie integriert. Bei jedem Fertigungsschritt werden die aktuellen Prozessparameter erfasst, an das Modell übergeben und eine Fehlerwahrscheinlichkeit berechnet – in Echtzeit, während das Teil noch in der Linie ist.
Was Predictive Quality nicht ist
- Kein Ersatz für Qualitätsprüfung: Predictive Quality prognostiziert Wahrscheinlichkeiten, keine Gewissheiten. Prüfungen bleiben notwendig – aber sie können gezielter eingesetzt werden.
- Keine Black Box: Gute Predictive-Quality-Systeme zeigen, warum ein Teil als risikoreich eingestuft wird (Feature Importance). Das ist entscheidend für Prozessverbesserung.
- Keine Garantie für Fehlerfreiheit: Ein Modell mit 95 % Accuracy bedeutet: 5 % der Vorhersagen sind falsch. Predictive Quality reduziert Fehler, eliminiert sie aber nicht.
| 72 % | Reduktion unentdeckter Fehler durch Inline-Prognose |
| Ø 34 % | Reduktion Prüfaufwand durch risikobasierte Prüfplanung |
| 2,3× | ROI im ersten Jahr bei erfolgreicher Einführung |
| 68 % | Predictive-Quality-Projekte scheitern an Datenqualität, nicht an ML |
Abgrenzung: Predictive Quality vs. SPC vs. Inline-Prüfung
Predictive Quality ist nicht der einzige Ansatz zur Qualitätssicherung während der Fertigung. Die Abgrenzung zu anderen Methoden klärt, wann welcher Ansatz sinnvoll ist.
| SPC (Statistical Process Control) | Inline-Prüfung | Predictive Quality | |
|---|---|---|---|
| Grundprinzip | Statistische Überwachung von Prozessparametern auf Regelkarten | 100 %-Prüfung jedes Teils während der Fertigung | ML-basierte Prognose der Fehlerwahrscheinlichkeit |
| Datenbasis | Prozessparameter-Stichproben | Prüfergebnis jedes Teils | Prozessparameter + historische Qualitätsergebnisse |
| Erkennungslogik | Regelbasiert: Eingriffsgrenzen, Trendregeln | Messung: Ist-Wert vs. Toleranz | Musterbasiert: Parameterkonstellationen |
| Was wird erkannt? | Prozessdrift, Ausreißer | Fehlerhafte Teile (nach Entstehung) | Fehlerrisiko (vor Entstehung) |
| Typischer Einsatz | Prozessüberwachung, Frühwarnung | Qualitätssicherung, Ausschuss-Aussortierung | Adaptive Prüfplanung, Prozessregelung |
Wann welcher Ansatz?
SPC ist sinnvoll, wenn:
- Prozesse stabil gehalten werden sollen
- Reaktion auf Drift ausreicht
- Wenige, klar definierte Prozessparameter überwacht werden
Inline-Prüfung ist sinnvoll, wenn:
- 100 %-Qualitätsnachweis gefordert ist
- Prüfung schnell und kostengünstig möglich ist
- Fehler zuverlässig messbar sind
Predictive Quality ist sinnvoll, wenn:
- Viele Prozessparameter interagieren
- Prüfung teuer oder zerstörend ist
- Fehler erst spät sichtbar werden
- Daten bereits vorhanden, aber ungenutzt sind
Die Ansätze schließen sich nicht aus – sie ergänzen sich. Predictive Quality kann auf SPC-Daten aufbauen und Inline-Prüfung risikobasiert steuern.
Welche Daten Predictive Quality braucht
Der häufigste Grund für gescheiterte Predictive-Quality-Projekte ist nicht ein falsches ML-Modell, sondern fehlende oder unverknüpfte Daten. Bevor über Algorithmen gesprochen wird, muss die Datenbasis geprüft werden.
Die drei Datenkategorien für Predictive Quality
| Kategorie | Beispiele | Quelle | Kritische Anforderung |
|---|---|---|---|
| Prozessparameter | Temperatur, Druck, Drehzahl, Vorschub, Zykluszeit, Werkzeugalter | SPS, MES, Sensorik | Je Seriennummer oder Zyklus verfügbar |
| Qualitätsdaten | Prüfergebnis (i.O./n.i.O.), Messwert, Fehlercode, Cpk | QMS, Prüfstand, Labor | Je Seriennummer verknüpft |
| Kontextdaten | Schicht, Bediener, Charge, Werkzeug-ID, Umgebungsbedingungen | MES, ERP, manuell | Konsistent erfasst, referenzierbar |
Die kritische Verknüpfung: Seriennummer als Schlüssel
Predictive Quality lernt aus der Frage: „Bei welchen Prozessparametern ist welches Qualitätsergebnis entstanden?"
Diese Frage kann nur beantwortet werden, wenn Prozessparameter und Qualitätsergebnis derselben Einheit zugeordnet werden können. Das erfordert einen durchgehenden Schlüssel – typischerweise die Seriennummer oder eine Kombination aus Charge + Zyklusnummer.
Problem in der Praxis: In vielen Betrieben liegen Prozessparameter im MES, Prüfergebnisse im QMS und Chargeninformationen im ERP – ohne gemeinsamen Schlüssel. Die Daten existieren, aber sie sind nicht verknüpfbar.
Datenqualitäts-Checkliste für Predictive Quality
| Dimension | Mindestanforderung | Prüffrage |
|---|---|---|
| Verknüpfung | Prozessparameter + Qualitätsmerkmal je Einheit | Kann ich für jede Seriennummer sagen: diese Parameter → dieses Ergebnis? |
| Vollständigkeit | < 5 % fehlende Werte bei Schlüsselparametern | Wie viele Datenpunkte haben NULL-Werte bei Temperatur, Druck, etc.? |
| Zeitstempel | Maschinengesetzt, ISO 8601, synchronisiert | Sind Prozess-Zeitstempel und Prüf-Zeitstempel konsistent? |
| Stichprobengröße | Mind. 500–1.000 Einheiten, davon 50–100 Fehlerfälle | Haben wir genug Positivbeispiele UND genug Negativbeispiele? |
| Labeling | Eindeutige Qualitätsklassifikation (i.O./n.i.O. oder Messwert) | Ist das Qualitätsergebnis klar definiert – keine mehrdeutigen Kategorien? |
| Historietiefe | Mind. 3–6 Monate, besser 12 Monate | Deckt der Datensatz saisonale Schwankungen, Chargenwechsel, Werkzeugwechsel ab? |
Typische Datenquellen und ihre Eignung
| Datenquelle | Typische Inhalte | Eignung für Predictive Quality |
|---|---|---|
| SPS / Steuerung | Zyklusdaten, Soll-/Istwerte, Maschinenzustände | ✓ Hoch – Rohdaten mit hoher Auflösung |
| MES | Fertigungsauftrag, Prozessparameter, Zeitstempel, Seriennummer | ✓ Hoch – strukturiert und verknüpft |
| QMS | Prüfergebnisse, Fehlercodierung, Cpk-Werte | ✓ Hoch – Labels für Modelltraining |
| ERP | Charge, Lieferant, Material, Auftrag | ○ Mittel – Kontextdaten, selten Echtzeit |
| Excel / manuell | Diverse, oft unstrukturiert | ✗ Niedrig – Datenqualität meist unzureichend |
| Sensorik (IIoT) | Vibration, Temperatur, Strom, Akustik | ✓ Hoch – wenn in Datenbasis integriert |
Der ML-Workflow: Vom Rohdaten zum Vorhersagemodell
Maschinelles Lernen klingt komplex – der grundlegende Workflow ist aber strukturiert und nachvollziehbar. Die folgenden sechs Phasen beschreiben, wie aus Rohdaten ein funktionierendes Predictive-Quality-Modell entsteht.
PHASE 1 | DAUER: 1–2 Wochen
Problemdefinition und Zielgröße
Was genau soll das Modell vorhersagen?
Aktivitäten:
- Zielgröße definieren: Fehlerwahrscheinlichkeit, Qualitätsklasse, konkretes Merkmal (z. B. Maßhaltigkeit)?
- Binäre Klassifikation (i.O./n.i.O.) oder Regression (Messwert vorhersagen)?
- Business Case: Was ist der Wert einer korrekten Vorhersage? Was kostet ein False Negative (nicht erkannter Fehler)?
- Scope eingrenzen: Ein Produkt, eine Linie, ein Qualitätsmerkmal als Pilot
Output: Dokumentierte Problemstellung mit Zielgröße, Scope und Erfolgskriterien
PHASE 2 | DAUER: 2–4 Wochen
Datensammlung und -integration
Welche Daten brauchen wir – und wie bekommen wir sie zusammen?
Aktivitäten:
- Datenquellen identifizieren: MES, QMS, SPS, ERP, Sensorik
- Datenextraktion: SQL-Abfragen, API-Anbindung, CSV-Export
- Datenverknüpfung: Gemeinsamen Schlüssel (Seriennummer) etablieren
- Datensatz erstellen: Eine Zeile = eine Einheit, Spalten = Features + Zielvariable
Output: Integrierter Rohdatensatz mit Prozessparametern und Qualitätsergebnissen je Einheit
PHASE 3 | DAUER: 2–3 Wochen
Datenbereinigung und Feature Engineering
Wie machen wir die Daten modellierbar?
Aktivitäten:
- Fehlende Werte behandeln: Entfernen, imputieren oder als eigene Kategorie?
- Ausreißer identifizieren: Plausibilitätsprüfung, ±3σ-Filter
- Feature Engineering: Abgeleitete Merkmale erstellen (z. B. Temperatur-Gradient, Werkzeugalter-Kategorie)
- Normalisierung: Skalierung der Features für Modellstabilität
- Train/Test-Split: 70–80 % Training, 20–30 % Test – chronologisch, nicht zufällig
Output: Bereinigter, feature-engineerter Datensatz, aufgeteilt in Training und Test
PHASE 4 | DAUER: 1–2 Wochen
Modellauswahl und Training
Welches Modell passt – und wie gut ist es?
Aktivitäten:
- Modellkandidaten auswählen: Logistische Regression, Random Forest, Gradient Boosting, XGBoost
- Baseline-Modell trainieren: Einfaches Modell als Referenz
- Hyperparameter-Tuning: Grid Search oder Random Search für optimale Konfiguration
- Cross-Validation: K-Fold (k=5 oder 10) zur Robustheitsprüfung
Typische Modellwahl nach Datenlage:
| Datenlage | Empfohlenes Modell | Begründung |
|---|---|---|
| < 1.000 Datenpunkte, wenige Features | Logistische Regression | Robust bei wenig Daten |
| 1.000–10.000 Datenpunkte, mittlere Komplexität | Random Forest | Gute Balance Genauigkeit/Interpretierbarkeit |
| > 10.000 Datenpunkte, viele Features | XGBoost, LightGBM | Höchste Accuracy bei großen Datensätzen |
| Sequenzielle Daten (Zeitreihen) | LSTM, Transformer | Berücksichtigt zeitliche Abhängigkeiten |
Output: Trainiertes Modell mit dokumentierten Hyperparametern
PHASE 5 | DAUER: 1–2 Wochen
Modellevaluierung und Interpretation
Wie gut ist das Modell – und warum trifft es welche Entscheidungen?
Aktivitäten:
- Performance-Metriken auf Testdaten: Accuracy, Precision, Recall, F1-Score, AUC-ROC
- Confusion Matrix analysieren: Wie viele False Positives, wie viele False Negatives?
- Schwellenwert-Optimierung: Bei welcher Wahrscheinlichkeit wird ein Teil als „Risiko" klassifiziert?
- Feature Importance: Welche Prozessparameter haben den größten Einfluss?
- SHAP-Analyse: Warum wurde dieses Teil als risikoreich eingestuft?
Kritische Metriken für Predictive Quality:
| Metrik | Bedeutung | Zielwert (Orientierung) |
|---|---|---|
| Recall (Sensitivity) | Anteil der tatsächlichen Fehler, die erkannt wurden | > 85 % |
| Precision | Anteil der Risiko-Warnungen, die tatsächlich Fehler waren | > 70 % |
| F1-Score | Harmonisches Mittel aus Precision und Recall | > 0,75 |
| AUC-ROC | Modell-Trennschärfe insgesamt | > 0,85 |
Output: Evaluiertes Modell mit dokumentierter Performance und interpretierbaren Ergebnissen
PHASE 6 | DAUER: 2–4 Wochen
Deployment und Monitoring
Wie kommt das Modell in die Produktion – und bleibt es gut?
Aktivitäten:
- Modell-Deployment: Integration in MES, Edge-Device oder Cloud-Service
- Echtzeit-Inferenz: Vorhersage bei jedem Fertigungszyklus
- Monitoring: Modell-Performance kontinuierlich überwachen (Drift Detection)
- Feedback-Loop: Neue Prüfergebnisse → Modell-Retraining
- Schwellenwert-Anpassung: Basierend auf Praxis-Feedback
Output: Produktives Modell mit Monitoring und Retraining-Prozess
5 typische Use Cases in der Fertigung
Predictive Quality ist kein Selbstzweck – der Nutzen entsteht durch konkrete Anwendungsfälle. Die folgenden fünf Use Cases zeigen, wo Predictive Quality in der Praxis den größten Hebel hat.
USE CASE 01
Inline-Fehlerprognose mit Echtzeit-Warnung
„Dieses Teil hat eine 78 %-Wahrscheinlichkeit für Maßabweichung – sofort prüfen."
Situation: Spritzgusslinie, 12 Prozessparameter pro Zyklus. Maßabweichung wird erst in der Endprüfung erkannt – 40 Zyklen später.
Predictive-Quality-Ansatz:
- Modell trainiert auf historischen Daten: Prozessparameter → Maßabweichung ja/nein
- Echtzeit-Prognose bei jedem Zyklus
- Bei Fehlerwahrscheinlichkeit > 60 %: Warnung an Bediener + Teil für Sofortprüfung markiert
Ergebnis:
| Vorher | Nachher |
|---|---|
| 0,8 % Ausschuss | 0,2 % Ausschuss |
| Fehler erkannt nach Ø 18 Min. | Fehler erkannt nach Ø 12 Sek. |
USE CASE 02
Adaptive Prüfplanung (risikobasiert)
„Teile mit niedriger Fehlerwahrscheinlichkeit: Stichprobe. Teile mit hoher Wahrscheinlichkeit: 100 %."
Situation: Montagelinie, zerstörungsfreie Endprüfung möglich, aber zeitaufwendig (45 Sek./Teil). Aktuell: 100 %-Prüfung.
Predictive-Quality-Ansatz:
- Modell prognostiziert Fehlerwahrscheinlichkeit je Teil
- Prüfstrategie: < 20 % → Stichprobe (10 %). 20–60 % → Normalprüfung. > 60 % → erweiterte Prüfung
- Prüfkapazität wird auf Risiko-Teile fokussiert
Ergebnis:
| Vorher | Nachher |
|---|---|
| 100 % Prüfung | 38 % Prüfung |
| 0 Fehler durchgeschlüpft | 0 Fehler durchgeschlüpft |
| Prüfkosten 100 % | Prüfkosten 41 % |
USE CASE 03
Ersatz für zerstörende Prüfung
„Statt das Teil zu zerstören, prognostizieren wir die Festigkeit aus den Prozessparametern."
Situation: Schweißnaht-Festigkeitsprüfung, zerstörend. Aktuell: Stichprobe 1 von 50. Unsicherheit bei den anderen 49.
Predictive-Quality-Ansatz:
- Modell trainiert auf: Schweißparameter (Strom, Geschwindigkeit, Gas) → Reißfestigkeit (aus zerstörender Prüfung)
- Regressionsmodell prognostiziert Festigkeit für jedes Teil
- Zerstörende Prüfung nur noch zur Modell-Validierung und bei prognostiziertem Risiko
Ergebnis:
| Vorher | Nachher |
|---|---|
| 2 % zerstörend geprüft | 0,5 % zerstörend geprüft |
| 49 von 50 Teilen ohne Nachweis | Jedes Teil mit prognostizierter Festigkeit |
| Ø 3 Reklamationen/Monat | Ø 0,4 Reklamationen/Monat |
USE CASE 04
Frühwarnung bei Prozessdrift
„Der Prozess driftet – in 200 Zyklen wird Cpk unter 1,33 fallen."
Situation: Fräsprozess, Cpk-Wert sinkt langsam mit Werkzeugverschleiß. Aktuell: Reaktion erst bei Cpk < 1,33.
Predictive-Quality-Ansatz:
- Zeitreihen-Modell auf Cpk-Verlauf + Werkzeugalter + Prozessparameter
- Prognose: Wann wird Cpk < 1,33 erreicht?
- Frühwarnung 2–4 Stunden vor erwartetem Unterschreiten
Ergebnis:
| Vorher | Nachher |
|---|---|
| Reaktion bei Cpk < 1,33 | Warnung 3 Std. vor Cpk < 1,33 |
| Ø 120 Teile im Grenzbereich | Ø 8 Teile im Grenzbereich |
| Ungeplante Werkzeugwechsel | Geplante Werkzeugwechsel |
USE CASE 05
Root-Cause-Analyse durch Feature Importance
„Die drei wichtigsten Treiber für Ausschuss sind: Kühlmitteltemperatur, Werkzeugalter, Schichtwechsel-Pause."
Situation: Ausschussrate schwankt zwischen 0,3 % und 1,2 % – ohne erkennbares Muster. 14 Prozessparameter erfasst.
Predictive-Quality-Ansatz:
- Klassifikationsmodell auf alle Parameter → Ausschuss ja/nein
- Feature Importance und SHAP-Analyse: Welche Parameter treiben den Ausschuss?
- Identifikation der Top-3-Treiber für gezielte Maßnahmen
Ergebnis:
| Erkenntnis | Maßnahme |
|---|---|
| Kühlmitteltemperatur > 28°C korreliert mit 3× Ausschussrate | Kühlmittel-Temperatursensor + Warnung bei > 26°C |
| Werkzeugalter > 8.000 Zyklen: signifikanter Anstieg | Werkzeugwechsel-Intervall auf 7.500 gesenkt |
| Erste 30 Min. nach Schichtwechsel: erhöhter Ausschuss | Anlaufprozedur mit Referenzteil eingeführt |
Predictive Quality ist kein Technologie-Projekt – es ist ein Qualitätsverbesserungsprojekt, das Technologie nutzt. Der Wert entsteht nicht durch das Modell, sondern durch die Maßnahmen, die aus den Erkenntnissen folgen.
— Amadeus Lederle, CTE, CSP Intelligence GmbH
Voraussetzungen: Wann ist euer Betrieb bereit?
Predictive Quality erfordert keine perfekte Datenbasis – aber sie erfordert eine ausreichende. Die folgende Checkliste zeigt, ob euer Betrieb die Mindestvoraussetzungen erfüllt.
Readiness-Check für Predictive Quality
| Dimension | Mindestanforderung | ✓ Bereit | ✗ Noch nicht |
|---|---|---|---|
| Prozessparameter digital | Mind. 5 relevante Parameter je Einheit digital erfasst | Parameter werden automatisch je Zyklus gespeichert | Parameter nur auf Papier oder gar nicht erfasst |
| Qualitätsergebnisse digital | Prüfergebnisse (i.O./n.i.O. oder Messwerte) im System | QMS oder MES mit strukturierten Prüfprotokollen | Prüfergebnisse in Papierform oder Excel-Inseln |
| Verknüpfung | Gemeinsamer Schlüssel (Seriennummer) für Parameter + Qualität | Seriennummer durchgehend verwendet | Keine eindeutige Zuordnung möglich |
| Historietiefe | Mind. 3 Monate Daten, besser 6–12 Monate | Daten werden seit > 6 Monaten gespeichert | Daten regelmäßig gelöscht oder < 3 Monate verfügbar |
| Fehler-Anteil | Mind. 50 dokumentierte Fehlerfälle im Datensatz | Ausschuss/NIO wird systematisch erfasst und kategorisiert | Zu wenige Fehlerfälle oder nicht kategorisiert |
| Datenqualität | < 10 % fehlende Werte bei Schlüsselfeldern | Pflichtfelder technisch erzwungen, Zeitstempel maschinengesetzt | Hoher Anteil fehlender Werte, manuelle Eingabe ohne Validierung |
| Ressourcen | Mind. 1 Person mit Prozesswissen + Datenaffinität (20 % FTE für 3 Monate) | Qualitäts-/Prozessingenieur mit Excel-/SQL-Kenntnissen verfügbar | Keine dedizierte Ressource, nur „nebenbei" |
Wenn Voraussetzungen nicht erfüllt sind
Wenn eine oder mehrere Dimensionen „Noch nicht" zeigen, ist das kein Grund, Predictive Quality abzuschreiben – es zeigt, wo zuerst investiert werden muss.
| Gap | Erster Schritt |
|---|---|
| Prozessparameter nicht digital | SPS-Datenexport einrichten, MES-Anbindung prüfen |
| Keine Verknüpfung | Seriennummer als Pflichtfeld in MES und QMS einführen |
| Zu wenig Historiedaten | Heute starten mit systematischer Erfassung – in 3–6 Monaten ist die Basis da |
| Zu wenige Fehlerfälle | Gut so! Ggf. Scope erweitern (mehrere Linien, längerer Zeitraum) |
| Datenqualität unzureichend | Pflichtfelder definieren, Zeitstempel-Synchronisation prüfen |
Der 6-Schritt-Einführungspfad
Predictive Quality muss nicht als Großprojekt starten. Der folgende Einführungspfad ist für einen pragmatischen Proof of Concept ausgelegt – 8–12 Wochen, ein Qualitätsmerkmal, ein Produkt.
SCHRITT 1 | DAUER: 1 Woche
Pilot-Scope definieren
Aktivitäten:
- Ein Produkt, eine Linie, ein Qualitätsmerkmal auswählen
- Kriterien für Pilot: genug Daten, messbares Problem, engagierter Prozessowner
- Zielgröße festlegen: Fehlerklassifikation oder Messwert-Prognose?
- Erfolgskriterien definieren: Welche Modell-Performance rechtfertigt Weiterverfolgung?
Output: Dokumentierter Pilot-Scope mit Zielgröße und Erfolgskriterien
SCHRITT 2 | DAUER: 2 Wochen
Daten extrahieren und verknüpfen
Aktivitäten:
- Prozessparameter aus MES/SPS exportieren (6–12 Monate)
- Qualitätsergebnisse aus QMS exportieren
- Verknüpfung über Seriennummer herstellen
- Datensatz validieren: Vollständigkeit, Konsistenz, Plausibilität
Output: Verknüpfter Analysedatensatz
SCHRITT 3 | DAUER: 2 Wochen
Explorative Datenanalyse
Aktivitäten:
- Deskriptive Statistik: Mittelwerte, Verteilungen, Korrelationen
- Visualisierung: Zeitreihen, Box-Plots, Scatter-Plots
- Muster identifizieren: Gibt es erkennbare Zusammenhänge zwischen Parametern und Qualität?
- Feature-Kandidaten priorisieren
Output: Analysebericht mit identifizierten Mustern und Feature-Kandidaten
SCHRITT 4 | DAUER: 2 Wochen
Modell trainieren und evaluieren
Aktivitäten:
- Train/Test-Split (zeitlich, nicht zufällig)
- Baseline-Modell: Logistische Regression oder Random Forest
- Performance-Metriken: Recall, Precision, F1, AUC-ROC
- Feature Importance analysieren
Output: Trainiertes Modell mit dokumentierter Performance
SCHRITT 5 | DAUER: 2 Wochen
Validierung am Shopfloor
Aktivitäten:
- Modell auf neue Daten anwenden (nicht im Training verwendet)
- Vorhersagen mit tatsächlichen Ergebnissen vergleichen
- Prozessexperten einbinden: Sind die identifizierten Treiber plausibel?
- False Positives und False Negatives analysieren
Output: Validiertes Modell mit Shopfloor-Feedback
SCHRITT 6 | DAUER: 2 Wochen
Entscheidung und nächste Schritte
Aktivitäten:
- Ergebnisse gegen Erfolgskriterien bewerten
- Business Case berechnen: Welche Einsparungen sind bei Rollout realistisch?
- Go/No-Go für Produktivierung
- Roadmap für Rollout oder weiteren Pilot
Output: Entscheidung + Roadmap
| 8–12 Wochen | Typische Dauer Proof of Concept |
| 1 FTE × 30–40 % | Typischer Ressourcenbedarf (Prozessingenieur + Datenaffinität) |
| Ø 67 % | PoCs, die zu Produktivierung führen |
| < 10.000 € | Typische Kosten PoC (ohne Lizenzkosten) |
Grenzen und typische Fehler
Predictive Quality ist kein Allheilmittel. Die Methode hat klare Grenzen – und typische Fehler bei der Einführung sind vermeidbar, wenn man sie kennt.
Grenzen von Predictive Quality
| Grenze | Erklärung | Konsequenz |
|---|---|---|
| Nur bekannte Fehlermodi | ML-Modelle erkennen Muster, die in den Trainingsdaten vorkommen – neue, unbekannte Fehlermodi werden nicht prognostiziert | Predictive Quality ergänzt, ersetzt aber nicht systematische FMEA und Prozesskontrolle |
| Korrelation ≠ Kausalität | Ein Modell findet statistische Zusammenhänge, keine physikalischen Ursachen | Feature Importance zeigt Korrelation – Prozessverständnis ist nötig, um Kausalität zu bestätigen |
| Datenqualität als Engpass | Garbage in = garbage out. Unvollständige oder falsch verknüpfte Daten liefern falsche Modelle | Datenqualität ist Voraussetzung, nicht Nebenprodukt |
| Modell-Drift | Prozesse ändern sich (neues Material, Werkzeugwechsel, Saisoneffekte) – das Modell bleibt zurück | Kontinuierliches Monitoring und regelmäßiges Retraining sind Pflicht |
| False Positives/Negatives | Kein Modell ist perfekt – es gibt immer falsche Alarme und übersehene Fehler | Schwellenwerte müssen auf den Use Case abgestimmt sein (lieber mehr Alarme oder weniger?) |
Typische Fehler bei der Einführung
| Fehler | Warum er passiert | Wie er vermieden wird |
|---|---|---|
| Zu breiter Scope | „Wir wollen alle Fehler auf allen Linien vorhersagen" | Mit einem Merkmal, einer Linie, einem Produkt starten |
| Datenintegration unterschätzt | „Die Daten sind ja da" – aber nicht verknüpft | 50 % der PoC-Zeit für Datenintegration einplanen |
| Black-Box-Modell ohne Interpretation | Modell sagt „Fehler", aber niemand versteht warum | Feature Importance und SHAP-Analyse von Anfang an |
| Kein Shopfloor-Einbezug | Data Scientists bauen Modell, Prozessexperten werden nicht gefragt | Prozessingenieure ab Tag 1 einbinden |
| Einmaliges Training | Modell wird trainiert, dann nie wieder angefasst | Monitoring + Retraining-Zyklus definieren |
| Overengineering | „Wir brauchen Deep Learning und Echtzeit-Streaming" | Random Forest auf sauberen Daten schlägt LSTM auf schlechten Daten |
PRAXISTIPP
Die Datenbasis für Predictive Quality
Predictive Quality scheitert selten am Algorithmus – sondern an fehlender oder unverknüpfter Datenbasis. IPM löst genau dieses Problem: alle Prozessparameter, Prüfergebnisse und Traceability-Daten werden in einer integrierten Datenbasis gespeichert, mit der Seriennummer als durchgehendem Schlüssel.
Für Predictive Quality bedeutet das:
- Verknüpfung out-of-the-box: Prozessparameter + Qualitätsergebnis + Kontextdaten je Seriennummer – keine nachträgliche Integration nötig
- Zeitstempel maschinengesetzt: Synchronisiert, ISO 8601, keine manuellen Eingabefehler
- Pflichtfelder technisch erzwungen: Keine fehlenden Werte bei Schlüsselparametern
- Historietiefe unbegrenzt: Alle Daten werden gespeichert, nicht nach 90 Tagen gelöscht
- ML-Export-fähig: CSV, Parquet oder direkte Datenbankabfrage für Python/R
Das Ergebnis: Die Datenintegration – typisch 50 % des Aufwands eines Predictive-Quality-PoC – entfällt. Statt Wochen für Datensammlung: sofort starten mit Analyse.
Häufig gestellte Fragen
Brauchen wir ein Data-Science-Team für Predictive Quality?
Nicht für den Einstieg. Ein erster Proof of Concept kann von einem Prozessingenieur mit Python-Grundkenntnissen durchgeführt werden – oder mit Low-Code-ML-Plattformen (DataRobot, Azure AutoML, H2O). Die Kernkompetenz ist nicht ML, sondern Prozessverständnis: Welche Parameter sind relevant? Welche Daten sind verlässlich? Was bedeuten die Ergebnisse? Für Produktivierung und Skalierung kann externes Know-how sinnvoll sein – aber der PoC sollte intern getrieben werden.
Wie viele Datenpunkte brauche ich mindestens?
Als Faustregel: mindestens 500–1.000 Datenpunkte insgesamt, davon mindestens 50–100 Fehlerfälle (positive Klasse). Bei stark unbalancierten Daten (0,1 % Ausschuss) wird das schwierig – hier helfen Techniken wie Oversampling (SMOTE) oder angepasste Verlustfunktionen. Wichtiger als die absolute Zahl ist die Variabilität in den Daten: Decken die Daten verschiedene Chargen, Werkzeuge, Schichten, Jahreszeiten ab?
Was ist der Unterschied zwischen Klassifikation und Regression?
- Klassifikation: Modell prognostiziert eine Kategorie (z. B. i.O./n.i.O., Fehlertyp A/B/C)
- Regression: Modell prognostiziert einen kontinuierlichen Wert (z. B. Festigkeit in N/mm², Maßabweichung in mm)
Für Predictive Quality ist Klassifikation häufiger – aber Regression kann wertvoller sein, wenn der konkrete Messwert wichtig ist (z. B. Ersatz für zerstörende Prüfung).
Wie erklären wir die Modellentscheidung?
Moderne ML-Modelle sind nicht mehr Black Boxes. Zwei Ansätze:
- Feature Importance: Zeigt, welche Parameter insgesamt die stärksten Treiber sind (z. B. „Temperatur erklärt 34 % der Varianz")
- SHAP-Werte: Zeigen für jede einzelne Vorhersage, welche Parameter in welche Richtung gewirkt haben (z. B. „Bei diesem Teil: Temperatur war 3°C zu hoch → +18 % Fehlerwahrscheinlichkeit")
Die Interpretierbarkeit ist entscheidend für Akzeptanz am Shopfloor und für die Ableitung von Verbesserungsmaßnahmen.
Wie oft muss das Modell neu trainiert werden?
Das hängt von der Prozessstabilität ab. Typische Intervalle:
- Stabiler Prozess, wenig Änderungen: Alle 3–6 Monate
- Häufige Chargenwechsel, Werkzeugwechsel: Monatlich
- Kontinuierlicher Drift: Online-Learning oder wöchentliches Retraining
Wichtiger als ein fester Rhythmus ist Monitoring: Wenn die Modell-Performance auf neuen Daten signifikant abfällt, ist Retraining nötig – unabhängig vom Kalender.
Was kostet die Einführung von Predictive Quality?
Die Kosten variieren stark nach Scope und Datenlage. Orientierung:
| Phase | Typische Kosten |
|---|---|
| PoC (ein Merkmal, 8–12 Wochen) | 5.000–20.000 € (intern, ohne Tools) |
| Produktivierung (ein Use Case) | 20.000–80.000 € (inkl. Integration) |
| Skalierung (mehrere Linien/Produkte) | 50.000–200.000 €/Jahr (inkl. Plattform) |
Der ROI entsteht durch: reduzierter Ausschuss, geringerer Prüfaufwand, vermiedene Reklamationen, frühere Fehlerentdeckung. Typisch: 2–3× ROI im ersten Jahr bei erfolgreicher Einführung.
Können wir Predictive Quality auch für Predictive Maintenance nutzen?
Ja – die Grundlogik ist identisch. Der Unterschied:
- Predictive Quality: Prognostiziert Produktqualität (Ausschuss, Maßabweichung)
- Predictive Maintenance: Prognostiziert Maschinenzustand (Ausfall, Wartungsbedarf)
Beide nutzen Prozessparameter und historische Muster. Oft sind dieselben Daten relevant – und ein gemeinsames Datenmodell kann beide Use Cases bedienen.
