Ausschuss-Ursachenanalyse: Mehrfaktor-Regression über Maschinenparameter

Das echte Ausmaß des Problems

Ausschussquoten von 3 bis 8 Prozent gelten in vielen Papierfabriken als unvermeidlich. In der Realität ist ein erheblicher Anteil davon systematisch vermeidbar — er wiederholt sich in ähnlichen Mustern, unter ähnlichen Prozessbedingungen, zu ähnlichen Zeiten.

Das Problem liegt nicht im fehlenden Bewusstsein, sondern in der Analysekomplexität. Eine moderne Papiermaschine erfasst kontinuierlich 200 bis 400 Prozessgrößen: Siebwasserparameter, Büttenkonsistenz, Mahlgrad, Siebspannung, Dampfdrücke in 30+ Trockenzylindern, Maschinengeschwindigkeit, Nipdrücke in der Pressenpartie, Streichmenge, Infrarottrockner-Temperaturen, Rollenhärte, Aufrolldruck. Jeder dieser Parameter kann einzeln oder in Wechselwirkung mit anderen Ausschuss verursachen.

Kein Operator kann 400 Zeitreihen gleichzeitig im Kopf behalten. Klassische Root-Cause-Analysen funktionieren deshalb überwiegend retrospektiv: Man schaut sich nach einem Ereignis die letzten 4 bis 8 Stunden an, sucht visuelle Anomalien, bildet Hypothesen. Das funktioniert bei offensichtlichen Einzelparameter-Ursachen — bei Wechselwirkungen zwischen fünf oder zehn Parametern über einen 12-Stunden-Verlauf versagt diese Methode regelmäßig.

Das Ergebnis: Eine Studie des Fraunhofer-Instituts für Intelligente Analyse- und Informationssysteme (IAIS) zeigt, dass in fertigungsintensiven Branchen 40 bis 60 Prozent aller Qualitätsabweichungen im ersten Analysezyklus falsch attribuiert werden — man behebt das Symptom, nicht die Ursache. Für die Papierindustrie bedeutet das: Viele Werke optimieren wochenlang an den falschen Stellschrauben.

Ein zusätzlicher Kostenblock: Jede ungelöste Ausschussursache belastet nicht nur die Produktionskosten direkt, sondern auch die Maschine. Re-pulped broke muss erneut aufbereitet werden, verbraucht Energie und belastet die Altpapierlinie. Bei Recyclingfasern entstehen außerdem Qualitätsschwankungen im Gutstoff, die nachfolgende Chargen betreffen.

Die Papierindustrie verfügt, anders als viele andere Branchen, in der Regel bereits über die nötigen Daten. Historian-Systeme wie AVEVA PI System laufen in den meisten Großbetrieben seit Jahren und speichern jeden Messpunkt sekundengenau. Das Problem ist nicht der Mangel an Daten — es ist der Mangel an Werkzeugen, die diese Daten systematisch auswerten.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Praxiswert aus Implementierungen in Prozessindustrie; stark abhängig von Datenlage, Parameteraussteuerbarkeit und konsequenter Nachverfolgung. McKinsey (2023) nennt Yield-Gewinne von bis zu 5 Prozentpunkten als erreichbaren Benchmark für die Papier- und Zellstoffindustrie mit datengetriebenen Methoden.

Die Zahlen klingen nach klaren Vorteilen — und die sind real. Aber es gibt eine wichtige Einschränkung: Das Modell findet Korrelationen. Es findet keine Ursachen. Der Unterschied ist nicht akademisch, er ist praktisch. Dazu mehr in einem eigenen Abschnitt weiter unten.

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5) Der größte konkrete Gewinn ist die verkürzte Root-Cause-Analyse. Was bisher 1 bis 3 Tage dauert — manuelles Durchsuchen der Historian-Daten, Hypothesenbildung, Schichtprotokoll-Abgleich — reduziert sich auf 2 bis 4 Stunden, weil das System den Report automatisch erstellt. Bei drei Ausschussereignissen pro Monat bedeutet das realistische 10 bis 15 Stunden Zeitersparnis pro Monat für Qualitätsleitung und erfahrene Operatoren. Nicht die höchste Zeitersparnis im Branchenvergleich (die Papierbandriss-Vorhersage spart direkte Stillstandsstunden), aber substanziell und täglich spürbar.

Kosteneinsparung — hoch (4/5) Bei einer Reduktion der Ausschussquote um 1 bis 3 Prozentpunkte und einer Maschine mit 200 Tonnen Tageskapazität zu 150 Euro je Tonne liegen die jährlichen Einsparungen aus dem Produktionswert-Gewinn zwischen 110.000 und 330.000 Euro — das ist direkt messbar. Hinzu kommen Energieeinsparungen durch weniger Re-Pulping und geringere Chemikalienkosten durch bessere Prozessstabilität. Warum keine 5? Weil die Einsparung nicht automatisch eintritt — sie setzt voraus, dass die identifizierten Ursachen auch tatsächlich behoben werden. Das Modell zeigt, wo die Ursachen liegen; die Maßnahmen müssen Operator und Technik umsetzen. Wenn nichts geändert wird, hilft auch das schönste SHAP-Diagramm nicht.

Schnelle Umsetzung — niedrig (2/5) Dieses Projekt ist technisch anspruchsvoll. Du brauchst: Historisierte Daten über mindestens 12 Monate, saubere Labeling-Prozesse (was gilt wann als Ausschuss?), eine Datenpipeline vom Historian in eine Analyseumgebung, einen Data Scientist oder externen Dienstleister für die Modellentwicklung, und eine Anbindung ans Operator-Dashboard. In der Praxis dauert ein erster valider Pilot 10 bis 14 Wochen — schnellere Zeitpläne sind möglich, aber sie sparen an den Schritten, die am meisten zählen: der Datenqualitätsprüfung und der Operator-Validierung.

ROI-Sicherheit — mittel (3/5) Die Ausschussreduktion ist prinzipiell messbar — Ausschussquote vorher vs. nachher ist eine klare Kennzahl. Die Schwierigkeit liegt in der Attribution: Welche Verbesserung ist auf das Modell zurückzuführen, welche auf normale Prozessoptimierungen, welche auf saisonal bessere Rohstoffqualität? Ohne sauberes Experimentdesign (kontrollierte Perioden mit und ohne Modelleinsatz) ist diese Frage schwer zu beantworten. Hinzu kommt: Das Modell findet zunächst Korrelationen, keine Ursachen — das Kausalitätsproblem (mehr dazu in einem eigenen Abschnitt) schränkt die ROI-Sicherheit ein.

Skalierbarkeit — mittel (3/5) Das Modell ist maschinenspezifisch. Wer die Analyse von PM 4 auf PM 5 ausweitet, kann die Methodik, die Infrastruktur und die Erfahrung übertragen — nicht aber das Modell selbst. Jede weitere Maschine braucht eigene Trainingsdaten, eigenes Labeling und eigene Validierung. Innerhalb einer Fabrik mit mehreren Maschinen ist das managebar, aber keine schnelle Skalierung. Zwischen verschiedenen Werken oder Maschinentypen sinkt die Übertragbarkeit weiter.

Richtwerte — stark abhängig von Datenhistorie, Maschinentyp, vorhandener IT-Infrastruktur und konsequentem Changemanagement nach Ergebnislieferung.

Was das System konkret macht

Der technische Ansatz kombiniert mehrere Schritte, die zusammen mehr leisten als jeder einzeln.

Schritt 1: Daten aus dem Historian zusammenführen. Das AVEVA PI System oder ein vergleichbarer Historian (Siemens SIMATIC IT, OSIsoft, SAP Manufacturing) speichert jeden Prozessparameter mit Zeitstempel. Für die Analyse werden alle Parameter der letzten 6 bis 24 Monate exportiert und mit dem Ausschuss-Label verknüpft — entweder aus dem Labeling-System der Qualitätssicherung oder aus dem MES.

Schritt 2: Feature Engineering. Rohe Zeitreihenwerte sind nicht direkt als Modell-Input geeignet. Stattdessen werden aus jedem Parameter mehrere abgeleitete Merkmale berechnet: gleitende Mittelwerte über verschiedene Zeitfenster (15 Minuten, 2 Stunden, 8 Stunden), Standardabweichungen als Maß für Instabilität, Trendrichtungen, Maximalwerte in definierten Fenstern vor einem Ausschussereignis. Das Ergebnis ist ein Feature-Datensatz mit typischerweise 500 bis 2.000 Spalten je nach Anzahl der Ausgangssignale.

Schritt 3: Machine Learning-Modell trainieren. Gradient-Boosting-Algorithmen (XGBoost, LightGBM) sind heute die Methode der Wahl für tabulare Prozessdaten in der Papierindustrie. Eine 2025 im Nordic Pulp & Paper Research Journal erschienene Studie zeigte, dass XGBoost, LightGBM und CatBoost für die Vorhersage von Papiereigenschaften (Zugfestigkeit, Berstindex, Reißlänge) auf industriellen Datensätzen R²-Werte über 0,9 erreichen. Das Modell lernt, welche Parameterkombinationen statistisch mit erhöhten Ausschussraten zusammenhängen.

Schritt 4: SHAP-Erklärbarkeit erzeugen. Predictive Analytics allein hilft nicht, wenn Operatoren nicht verstehen, warum das Modell zu einem Ergebnis kommt. SHAP (SHapley Additive exPlanations) weist jedem Parameter einen konkreten Beitrag zur Vorhersage zu. Das Ergebnis ist ein Diagramm, das zeigt: „Diese Ausschussspitze wird zu 38 Prozent durch die erhöhte Büttenkonsistenz in den 4 Stunden vor dem Ereignis erklärt, zu 22 Prozent durch die Druckvarianz in der Pressenpartie, zu 15 Prozent durch den Siebwasser-pH.” Das ist etwas, das Operatoren in ein konkretes Handlungsprogramm übersetzen können.

Schritt 5: Operator-Dashboard bereitstellen. Die SHAP-Reports werden in ein Dashboard überführt, das nach jedem Ausschussereignis automatisch befüllt wird. Der Operator öffnet das System, sieht die Top-5-Einflussgrößen, kann auf Zeitreihenplots klicken und die Parameterverläufe im Kontext sehen. Kein manueller Export, kein Excel.

Welche Maschinenparameter tatsächlich korrelieren — und welche nicht

Nicht alle Parameter sind gleich aufschlussreich. In der Praxis zeigen sich über verschiedene Papiermaschinen und -sorten hinweg wiederkehrende Muster.

Parameter mit typisch hoher Korrelationsstärke zur Ausschussquote:

• Büttenkonsistenz und deren Varianz (Stoffauflauf-Eingang): Schwankungen um mehr als ±0,15 Prozent Absolutgehalt korrelieren in fast allen Maschinendatensätzen stark mit Papierreißern und Bruchzonen. Besonders relevant ist die Varianz, nicht der Absolutwert — eine stabile, leicht zu hohe Konsistenz ist besser als eine durchschnittlich korrekte mit hoher Fluktuation.

• Nip-Druck in der ersten Pressnip und Homogenität über die Maschinenbreite: Ungleichmäßiger Nip-Druck verursacht Querprofilprobleme, die an der Aufrollung als Ausschuss gebucht werden, aber ihre Ursache 30 bis 60 Minuten früher haben.

• Trockenzylindertemperaturprofil (besonders in der ersten Trockengruppe): Temperaturabfälle von mehr als 5 Kelvin in einem Einzelzylinder korrelieren mit Feuchtelängsstreifen, die im Kalandrierbereich zu Brüchen führen.

• Siebwasser-Füllstoffgehalt und Retention: Bei Recyclingfasermischungen schwankt der Füllstoffgehalt im Siebwasser stark, was die Retention und die Blattformation beeinflusst — in der Auswertung oft überraschend hoch gewichtet.

Parameter, die oft verdächtigt werden, aber selten echte Hauptkorrelationen zeigen:

• Maschinengeschwindigkeit (wenn innerhalb normaler Betriebsgrenzen): Sie ist meist ein Proxy für andere Bedingungen, nicht die Ursache selbst. Ein Modell, das Maschinengeschwindigkeit als Top-Feature zeigt, weist oft auf ein Multikollinearitätsproblem hin.

• Wasserstoff-Ionenkonzentration des Prozesswassers (pH): In modernen, geschlossenen Kreislaufsystemen ist der pH-Wert gut geregelt und zeigt selten eigenständige Korrelationen — er korreliert stattdessen mit Chemikaliendosierungen und ist dann nur Mediatorgröße.

• Absolute Temperaturwerte der Trockenzylindergruppen (wenn gut geregelt): Auch hier ist die Varianz aussagekräftiger als der Absolutwert.

Falsche Freunde — Parameter, die nur wegen Sortenänderungen korrelieren:

Wenn die Maschine wöchentlich zwischen Druckpapier und Verpackungspapier wechselt, sehen viele Parameter, die mit dem Sortenwechsel zusammenhängen, wie Ausschusskorrelationen aus — obwohl sie schlicht Indikatoren für unterschiedliche Produktionsregimes sind. Feature-Engineering ohne Sortenkennzeichnung produziert regelmäßig solche Artefakte.

Eine gründliche Datenexploration vor der Modellentwicklung — aufgeteilt nach Sorten — ist deshalb keine Option, sondern Pflicht.

Das Labeling-Problem: Wann ist ein Ereignis wirklich Ausschuss?

Bevor das erste Modell trainiert wird, muss eine grundlegende Frage geklärt sein: Was genau ist das Ausschuss-Label?

In Papierfabriken gibt es typischerweise mehrere Kategorien von Ausschuss, die unterschiedliche Ursachen haben und deshalb in der Analyse getrennt behandelt werden müssen:

Anfahrausschuss fällt strukturell bei jedem Neustart der Maschine an — dieser Anteil hat keine sinnvolle Korrelation mit Prozessparametern im Betrieb und gehört aus dem Trainingsdatensatz heraus. Wer ihn mittrainiert, verzerrt das Modell in Richtung „Maschine war gerade gestartet” als stärkstem Predictor.

Sortenausschuss entsteht beim Übergang zwischen zwei Papiersorten, wenn die Maschineneinstellungen noch nicht stabilisiert sind. Auch dieser Anteil ist prozessuell unvermeidlich und sollte als eigene Klasse behandelt werden, nicht als „schlechter Betrieb.”

Qualitätsausschuss — das, worum es wirklich geht — entsteht im stabilen Betrieb, wenn Prozessparameter unzulässige Bereiche verlassen oder sich negativ überlagern. Dieser Anteil ist das eigentliche Lernziel des Modells.

Fehlerausschuss durch Maschinendefekte (gerissener Filz, defekter Messsensor, Fremdkörper) ist ebenfalls zu trennen — er korreliert mit Wartungsereignissen, nicht mit kontinuierlichen Prozessparametern.

Tatsächlich sind diese Kategorien in vielen Historian-Systemen nicht sauber getrennt. Ausschuss wird als Menge (Tonnen oder Prozent) geloggt, ohne Klassifikation. Das bedeutet: Vor der Modellentwicklung müssen Schichtprotokolle, Wartungsbucher und Qualitätsreports manuell oder halbautomatisch mit dem Historian-Datenstrom verknüpft werden.

Diese Labeling-Arbeit ist mühsam und wird regelmäßig unterschätzt. In Projekten mit schlechter Labelqualität ist das Modell am Ende technisch sauber trainiert — aber auf das falsche Problem. Garbage in, garbage out gilt hier buchstäblich.

Eine pragmatische Lösung: Beginne mit einem Workshop mit zwei bis drei erfahrenen Schichtführern und dem Qualitätsleiter. Definiert gemeinsam, was in eurer Dokumentation welche Kategorie entspricht, und wer die Klassifikationsregeln pflegt. Das ist eine halbe bis eine Arbeitswoche Aufwand — aber die Grundlage für alle folgenden Schritte.

Korrelation vs. Ursache: Was das Modell wirklich sagt

Das ist der Abschnitt, den viele überspringen — und dann sechs Monate später frustriert sind.

Ein Gradient-Boosting-Modell mit SHAP-Erklärbarkeit sagt dir: „Diese vier Parameter haben bei den letzten 47 Ausschussereignissen die stärksten statistischen Zusammenhänge gezeigt.” Das ist nützlich. Es ist kein Beweis für Kausalität.

Ein konkretes Beispiel: Das Modell zeigt, dass erhöhte Siebwasser-Trübung in den 2 Stunden vor einem Ausschussereignis einen SHAP-Wert von +0,38 hat. Das bedeutet: Im Trainings-Datensatz war hohe Trübung systematisch mit mehr Ausschuss assoziiert. Aber warum? Drei mögliche Erklärungen:

1. Die hohe Trübung verursacht direkt schlechtere Blattformation und damit Ausschuss.
2. Hohe Trübung und Ausschuss haben eine gemeinsame Ursache — zum Beispiel übermäßig variierender Mahlgrad, der beides gleichzeitig beeinflusst.
3. Hohe Trübung tritt systematisch bei Sorte X auf, die aus Rohstoffgründen ohnehin mehr Ausschuss hat.

In den ersten beiden Fällen würde eine gezielte Intervention an der Trübung etwas bringen. Im dritten Fall nicht. Das Modell kann diese drei Szenarien nicht von alleine unterscheiden — das braucht Domänenwissen und, wenn nötig, gezielte Experimente.

Die praxisnahe Lösung: Behandle die SHAP-Outputs als strukturierten Hypothesenkatalog, nicht als Aktionsplan. Jede Top-Korrelation wird von einem erfahrenen Operator und, wenn vorhanden, einem Prozessingenieur bewertet: „Passt das technisch? Haben wir das schon mal beobachtet? Können wir einen Test machen?” Erst nach dieser Prüfung wird eine Maßnahme definiert.

Geplante Validierungsexperimente sind hier der ehrlichste Weg: Eine gezielte Änderung des verdächtigen Parameters über eine definierte Periode, mit dokumentiertem Vergleich zur Kontrollperiode. Dieser Aufwand trennt echte Ursachen von Scheinkorrelationen — und gibt dir einen robusten Nachweis für Investitionen in technische Maßnahmen.

Konkrete Werkzeuge — was wann passt

Die Toolwahl hängt von eurem Datenzugang, der IT-Infrastruktur und dem vorhandenen Know-how ab. Es gibt sinnvolle Pfade auf verschiedenen Komplexitätsstufen.

Für explorative Erstanalyse ohne Programmieraufwand — Orange Data Mining: Orange ist kostenlos, läuft vollständig lokal und bietet einen visuellen Workflow-Editor. Du kannst CSV-Exporte aus dem Historian einladen, Korrelationen visualisieren, einfache Regressionen trainieren und erste SHAP-ähnliche Visualisierungen erstellen — ohne eine Zeile Code. Ideal für die Machbarkeitsphase: Habt ihr überhaupt auswertbare Daten? Zeigen sich erste plausible Muster? Diese Fragen klärst du damit in einer Woche. Grenzen: Skaliert nicht gut bei sehr großen Datensätzen, kein produktiver Betrieb im Schichtbetrieb ohne zusätzliche Infrastruktur.

Für strukturierte Modellentwicklung ohne eigene Data Scientists — KNIME Analytics Platform: KNIME ist ebenfalls kostenlos (Desktop-Version), bietet Drag-and-Drop-Modellentwicklung und hat konkrete Nodes für Zeitreihenauswertung, Gradient Boosting und Feature Importance. Besonders hilfreich: Workflows lassen sich dokumentieren und von anderen Personen reproduzieren — wichtig in einer Fabrik, wo das Wissen nicht an einer einzigen Person hängen soll. Für Teams mit ein bis zwei Personen mit technischem Hintergrund, die kein vollständiges Data-Science-Team haben. Grenzen: Für produktiven Echtzeitbetrieb oder sehr große Datenmengen ist der Upgrade auf den bezahlten Business Hub nötig.

Für professionelle Entwicklung mit vollständiger ML-Lifecycle-Kontrolle — Python mit scikit-learn/XGBoost/SHAP + MLflow: Der Gold-Standard für Projekte, bei denen ein Data Scientist involviert ist. Python mit XGBoost oder LightGBM für die Modellentwicklung, die SHAP-Bibliothek für Erklärbarkeit, MLflow für Experiment-Tracking und Modell-Versionierung. MLflow ist Open Source (Apache 2.0), läuft auf eigener Infrastruktur und hält alle Modellartefakte nachvollziehbar — wichtig, wenn das Modell monatlich nachtrainiert wird und ihr wissen wollt, ob die Version von März besser war als die von September. Grenzen: Erfordert DevOps-Kompetenz für das Hosting, keinen deutschsprachigen Support.

Für unternehmensweiten Einsatz mit integrierter Datenpipeline — Dataiku: Wenn mehrere Maschinen und Standorte ausgewertet werden sollen und ein Enterprise-Setting mit verschiedenen Teams, Zugriffsrechten und Compliance-Anforderungen besteht, ist Dataiku die stärkste kollaborative Plattform. Vorkonfigurierte industrielle Templates, EU-Hosting und visuelle Flows, die auch Business-Analysten ohne Python-Kenntnisse nachvollziehen können. Medianpreis laut PriceLevel.com 2024: ca. 26.000 USD/Jahr — nur sinnvoll ab einer klaren Enterprise-Ambition, nicht für erste Piloten.

Für Datenvisualisierung und Operator-Dashboard — Grafana über InfluxDB: Die SHAP-Reports und Prozessparameter-Verläufe müssen am Ende irgendwo sichtbar sein — und zwar für Operatoren im Leitstand, nicht nur für Data Scientists in PowerPoint-Präsentationen. Grafana verbindet sich nativ mit InfluxDB (für Zeitreihendaten) und kann SHAP-Scores als Panels neben den Prozessparametern zeigen. Grafana Core ist Open Source und kostenlos. Die Kombination InfluxDB + Grafana ist in vielen IIoT-Projekten der pragmatischste Weg für das Operator-Dashboard.

Für die Datenhaltung — AVEVA PI System oder Siemens Insights Hub: Wenn ein Historian bereits vorhanden ist, ist das die primäre Datenquelle. Beiden Systemen gemein: Der Datenzugang für externe Analysetools funktioniert über REST-API oder OPC-UA — das muss in der Projektplanung explizit mit der IT abgeklärt werden. Wenn kein Historian vorhanden ist, ist die Einrichtung eines eigenen Zeitreihen-Stacks mit InfluxDB eine kostengünstige Alternative.

Zusammenfassung: Wann welcher Weg

• Machbarkeitscheck, wenig Budget → Orange Data Mining, Export aus Historian, eine Woche
• Team mit IT-Hintergrund, kein Data Scientist → KNIME, 6–10 Wochen bis Pilotmodell
• Data Scientist oder externer Dienstleister → Python + XGBoost + SHAP + MLflow
• Enterprise, mehrere Maschinen und Standorte → Dataiku
• Operator-Dashboard für Leitstand → Grafana über InfluxDB

Datenschutz und Datenhaltung

Ausschuss-Ursachenanalyse verarbeitet Maschinendaten — Zeitreihen von Sensoren, Prozessparameter, Produktionsprotokolle. Personenbezogene Daten im DSGVO-Sinne entstehen nur, wenn Schichtprotokolle oder Bedienereingriffe mit der Analyse verknüpft werden, weil dann Rückschlüsse auf einzelne Personen möglich sind. Für diesen Fall gilt:

• DSGVO Art. 4 Abs. 1: Auch indirekt identifizierbare Daten (Schicht A, Bediener X hat Konsistenz um 14:37 Uhr verändert) sind personenbezogen, wenn die Person darüber identifizierbar ist.
• Betriebsrat-Relevanz: In vielen Fabriken ist die Einführung von Systemen, die Bedienereingriffe aufzeichnen und auswerten, mitbestimmungspflichtig nach BetrVG §87. Das klärst du besser vor der Pilotphase als nach der Einführung.

Für die reine Maschinendatenanalyse ohne Personenbezug:

• Alle genannten Tools können on-premise oder in EU-Rechenzentren betrieben werden — AVEVA PI System on-premises, KNIME lokal, Python auf eigenem Server, MLflow selbst gehostet.
• Siemens Insights Hub hostet in EU-Rechenzentren (DSGVO-konform). AVV auf Anfrage beim Hersteller.
• Dataiku bietet EU-Hosting-Option; für Produktionsdaten eines deutschen Unternehmens sollte das explizit angefordert werden.
• Die Verbindung aus dem OT-Netz (SCADA/DCS) in ein IT-Netz oder eine Cloud-Analyseumgebung erfordert eine OT/IT-Sicherheitsbewertung — unbedingt die IT-Security-Verantwortlichen einbinden, bevor Historian-Daten nach außen fließen.

Wer bei der Analyse auf historische Daten beschränkt bleibt und keine Live-Verbindung aufbaut, hat im Datenschutz eine wesentlich einfachere Situation. Das ist für eine erste Pilotphase fast immer der empfohlene Weg.

Was es kostet — realistisch gerechnet

Einmalige Projektkosten (Pilot, eine Maschine)

• Datenextraktion und -aufbereitung: 5–10 Personentage intern + externer Dienstleister 5.000–15.000 Euro
• Labeling-Workshop und Kategorisierung: 2–3 Personentage intern
• Modellentwicklung und Validierung: 15.000–40.000 Euro (externer Data Scientist oder Systemintegrator), oder 20–30 Personentage intern bei vorhandenem Skillset
• Dashboard-Entwicklung (Grafana + InfluxDB oder ähnlich): 3.000–8.000 Euro
• Gesamt Pilot: typisch 25.000–60.000 Euro extern, oder 15.000–30.000 Euro bei starker interner Ressource

Laufende Kosten (nach Pilotphase)

• Infrastruktur (selbst gehostet): 200–500 Euro/Monat für Server und Datenbank
• Modell-Retraining: 1–2 Personentage pro Quartal (oder nach jedem größeren Prozesswechsel)
• Tool-Lizenzen: 0 Euro bei Open-Source-Stack (KNIME, Python, MLflow, Grafana, InfluxDB), 0 Euro für Orange; ab ca. 2.000–4.000 Euro/Monat bei kommerziellen Plattformen (Dataiku)

Konservativer ROI-Rechenweg: 200 t/Tag × 150 €/t × 365 Tage = 10,95 Mio. Euro Produktionswert pro Jahr. Eine Ausschussquotenreduktion um 1 Prozentpunkt von z.B. 5% auf 4% entspricht einer Produktion, die bisher verloren ging, im Wert von ca. 110.000 Euro/Jahr. Realistisch: 1–3 Prozentpunkte Reduktion = 110.000–330.000 Euro/Jahr, nur aus dem Produktionswert. Dazu kommen Energieeinsparungen (Re-Pulping-Kosten, Dampf) und Rohstoffgewinne.

Selbst im sehr konservativen Szenario (1 Prozentpunkt Reduktion, nur 70 Prozent des Potenzials ausgeschöpft) amortisiert sich ein 40.000-Euro-Pilot innerhalb von 4 bis 6 Monaten.

Wie du den Nutzen tatsächlich misst: Leg zwei Messgrößen fest, bevor das Projekt startet: (1) Durchschnittliche Ausschussquote pro Woche im Vergleichszeitraum (6 Monate vor Projektstart), und (2) Zeit bis zum Abschluss einer Root-Cause-Analyse nach einem Ausschussereignis. Beide Größen lassen sich nachher direkt vergleichen. Ohne diese Baseline ist jedes ROI-Gespräch nach dem Projektstart rein anekdotisch.

Drei typische Einstiegsfehler

1. Das Modell trainieren, bevor die Labeling-Kategorien definiert sind. Das ist der häufigste Fehler — und er wird meist erst nach mehreren Wochen Modellentwicklung sichtbar, wenn das Modell Anfahrausschuss und Betriebsausschuss vermischt hat und sonderbar gewichtete Features produziert. Lösung: Vor der ersten Code-Zeile einen halben Tag mit Schichtführern und Qualitätsleitung verbringen und die Ausschuss-Taxonomie festlegen. Die Doku dazu sind maximal zwei DIN-A4-Seiten — aber sie sind die Grundlage für alles Weitere.

2. Das Modell auf alle Sorten gleichzeitig trainieren. Eine Papiermaschine, die mehrere Sorten produziert, hat sortenbezogen sehr unterschiedliche Prozessfenster. Ein Modell, das alle Sorten ohne Trennung verarbeitet, findet Sortenunterschiede als stärkstes Signal — und nicht die eigentlichen Ausschussursachen. Lösung: Entweder sortengetrennte Modelle trainieren, oder die Sorte als explizites Feature einbauen und alle SHAP-Analysen sortenspezifisch auswerten.

3. Das Modell läuft, aber niemand retrainiert es. Das ist der gefährlichste Fehler — weil er still passiert. Das Modell liefert weiter Reports, die Operatoren nutzen die Empfehlungen, aber die Prozessbedingungen haben sich geändert: neue Rohstofflieferanten, überarbeitete Rezepturen, veränderter Mahlgrad. Das Modell korreliert jetzt mit vergangenen Bedingungen, die nicht mehr existieren. Erfahrungsgemäß bemerkt man das erst, wenn mehrere Empfehlungen hintereinander nichts gebracht haben und die Stimmung gegenüber dem System kippt.

Lösung: Vor der Einführung eine klare Antwort auf drei Fragen: Wer ist verantwortlich für das Retraining? Welche Ereignisse lösen ein Retraining aus (Rohstoffwechsel, Rezepturänderung, Umbau)? Wie oft wird das Modell turnusmäßig überprüft? Monatlich ist ein guter Rhythmus für aktive Produktionsbedingungen.

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

Das größte Missverständnis bei der Einführung: Operatoren werden nicht sofort Empfehlungen umsetzen, nur weil das Modell sie liefert.

Es gibt ein fundamentales Vertrauensproblem. Erfahrene Leitstandfahrer wissen aus 15 Jahren Erfahrung, wie ihre Maschine sich verhält. Ein System, das nach 12 Monaten Datenlage eine Empfehlung ausspuckt, kann diese Erfahrung nicht einfach überschreiben. Das sollte es auch nicht — die Operatoren kennen die Maschine besser als das Modell. Das Modell kennt die Daten besser als die Operatoren.

Diese Spannung produktiv zu lösen, ist die eigentliche Einführungsarbeit.

Was hilft:

• Erst erklären, dann empfehlen. Stelle das System initial als Analysetool vor, nicht als Empfehlungssystem. „Hier siehst du, welche Parameter bei den letzten 20 Ausschussereignissen auffällig waren” — kein Imperativ, keine Anweisung. Lass Operatoren das System infrage stellen und diskutieren. Die Diskussionen selbst sind wertvolles Feedback.

• Die erste Empfehlung, die sich bestätigt, ist entscheidend. Wenn ein Operator eine SHAP-basierte Hypothese testet und die Ausschussquote daraufhin sinkt, ist das ein Durchbruch. Dieser Moment braucht Rahmenbedingungen: Wer darf in der Testphase einen Parameter gezielt verändern? Wie wird das protokolliert? Ohne Erlaubnisrahmen werden keine Tests stattfinden.

• Schichtübergaben nutzen. Die Zeit zwischen Schichtende und Schichtbeginn ist oft der einzige Moment, in dem sich zwei erfahrene Personen über Prozessereignisse austauschen. Wenn der SHAP-Report Teil dieser Übergabe wird — als eine Seite, nicht als Vortrag — ist er in wenigen Wochen normaler Bestandteil des Arbeitsrhythmus.

Was nicht hilft:

• Das System als „KI” präsentieren und erwarten, dass der Begriff allein Vertrauen erzeugt. Operatoren haben zu Recht eine gesunde Skepsis gegenüber Systemen, die sie nicht verstehen.
• Empfehlungen durchdrücken, wenn ein Operator begründete Einwände hat. Das System ist kein Vorgesetzter.
• Die Einführung in der Sommerpause oder über einen Standortwechsel hinweg planen — fehlende Kontinuität in den ersten Wochen zerstört die Akzeptanz.

Realistischer Zeitplan mit Risikohinweisen

Hinweis: Dieser Zeitplan gilt für einen erfahrenen externen Dienstleister oder ein internes Team mit Data-Science-Kompetenz. Ohne diese Ressourcen verlängern sich Phase 3 bis 5 erheblich. Ein „Quick Win” in vier Wochen ist in diesem Use Case nicht realistisch.

Häufige Einwände — und was dahintersteckt

„Wir haben das schon versucht — Excel-Auswertung hat nichts Verwertbares gezeigt.” Excel-Korrelationen zwischen zwei Zeitreihen — Parameter A vs. Ausschussquote, Schicht für Schicht — finden lineare Einfachkorrelationen. Gradient-Boosting-Modelle mit SHAP entdecken nicht-lineare Beziehungen, Wechselwirkungen zwischen fünf bis zehn Parametern gleichzeitig, und zeitliche Versätze (Parameter-Anomalie vor dem Ausschussereignis, nicht gleichzeitig). Das ist kein gradueller Unterschied — es sind qualitativ andere Analysewerkzeuge, die qualitativ andere Fragen beantworten können. Wer sagt, es wurde schon versucht, hat meist einfachere statistische Methoden ausprobiert, nicht ML-basierte Multivariatenanalyse.

„Unsere Daten sind nicht vollständig genug dafür.” Das höre ich in jedem Projekt am Anfang. Überprüfen lässt sich das in einer Woche: Historian-Daten für 12 Monate exportieren, Lücken und Qualitätsprobleme dokumentieren, Labeling-Möglichkeiten prüfen. Konkret ist die Datenlage in deutschen Papierwerken mit laufendem Historian deutlich besser, als die Betroffenen vermuten — nur nie explizit ausgewertet. Was wirklich fehlt, ist nicht selten ein klares Ausschuss-Label, nicht der Datenbestand selbst.

„Das ist doch nur eine Black Box, der Operator traut dem sowieso nicht.” Klassische Black-Box-KI liefert eine Empfehlung ohne Erklärung. SHAP-basierte Analysen gehen weiter: Das System sagt nicht nur „Ausschussrisiko hoch”, sondern zeigt konkret, welche Parameter mit welchem Gewicht zum Ergebnis beigetragen haben — visualisiert als Beeswarm-Diagramm oder Waterfall-Plot, den ein erfahrener Operator lesen und kommentieren kann. Das ist kein perfektes Verständnis, aber ein ausreichendes für produktive Diskussionen. Die Erfahrung zeigt: Operatoren, die aktiv in die Modell-Validierung eingebunden werden, werden zu den überzeugendsten Befürwortern — nicht zu den Kritikern.

„Was ist, wenn das Modell nach einem halben Jahr einfach nicht mehr stimmt?” Das passiert — und es ist eine valide Sorge. Concept Drift ist real: Nach größeren Rohstoffumstellungen, Maschinenrevisions oder Rezepturänderungen verliert ein ungewartetes Modell an Genauigkeit. Die Lösung ist kein technisches Feature, sondern ein organisatorisches: Vor dem Start klare Regeln definieren, wann ein Retraining stattfindet und wer es auslöst. Monatliche Modellprüfung und ein klar definierter Zuständiger — das ist die Sicherheitsanforderung für diesen Use Case.

Woran du merkst, dass das zu dir passt

• Ihr betreibt einen Historian (AVEVA PI, Siemens SIMATIC IT, OSIsoft oder vergleichbar) mit mindestens 12 Monaten Datenlage und 100+ kontinuierlich historisierten Tags
• Eure Ausschussquote hat wiederholende Muster — die gleichen Parameterbereiche oder Zeitfenster tauchen bei Ausschussereignissen immer wieder auf, ohne dass die Ursache klar ist
• Root-Cause-Analysen dauern bei euch mehrere Tage und enden oft in Hypothesen statt in validierten Erkenntnissen
• Ihr habt einen Qualitätsleiter oder Prozessingenieur, der bereit ist, 2–3 Stunden pro Woche in die Modell-Validierung zu investieren — das ist die Minimalvoraussetzung für einen produktiven Betrieb
• Die Top-Ausschussursachen sind nicht bereits bekannt und behebbar — wenn ihr wisst, dass ein bestimmtes Sieb in sechs Monaten ausgetauscht werden muss und das die Hauptursache ist, braucht ihr kein Modell, sondern einen Wartungsauftrag

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

1. Kein Historian mit ausreichender Datenlage. Ohne mindestens 12 Monate historisierte Prozessdaten (mit ausreichend Ausschussereignissen zum Trainieren — grob: mindestens 50 gut gelabelte Ereignisse) lässt sich kein verlässliches Modell trainieren. Wer heute einen Historian einführt, kann in 12 Monaten mit diesem Use Case starten — nicht früher.

2. Prozesseingriffe werden nicht digital dokumentiert. Wenn Operatoren Maschinenparameter ändern, ohne dass dies im System geloggt wird, fehlen kritische Informationen im Datensatz. Das Modell findet dann Muster in den Sensor-Zeitreihen, aber nicht in den Eingriffen, die den Verlauf verändert haben. Ergebnis: Systematisch verzerrte Korrelationsanalyse. Voraussetzung ist eine MES-Anbindung oder ein lückenloses elektronisches Schichtbuch.

3. Kein Zugang zu OPC-UA oder vergleichbarer standardisierter Datenschnittstelle. Wenn Historian-Daten nur über proprietäre Clients zugänglich sind oder der OT-Netz-Administrator keine Schnittstelle für Datenextraktion freigeben kann, ist das Projekt technisch blockiert, bevor es beginnt. Hier braucht es zuerst eine OT/IT-Integration — die ist ein eigenes Projekt.

Das kannst du heute noch tun

Exportiere aus deinem Historian die letzten vier Wochen Prozessdaten für deine problematischste Maschine — wähle 20 bis 30 Parameter, die ihr regelmäßig beobachtet. Lade sie in Orange Data Mining (kostenloser Download, 15 Minuten Setup) und erzeuge eine simple Korrelationsmatrix mit deiner Ausschuss-Zeitreihe. Das ist keine valide Modellentwicklung — aber es zeigt dir in einer Stunde, ob es überhaupt sichtbare Muster gibt. Wenn du dabei nichts Auffälliges findest: Möglicherweise liegt das Labeling-Problem vor, und du weißt jetzt, wo du zuerst ansetzen musst.

Für den nächsten Schritt — eine strukturierte Hypothesenanalyse nach einem Ausschussereignis — hier ein Prompt, den du direkt in einem KI-Assistenten nutzen kannst, sobald du die SHAP-Outputs oder Korrelationsdaten vor dir hast:

Quellen & Methodik

• ML für Root-Cause-Analyse in der Fertigung: Frontiers in Manufacturing Technology (2022), „A systematic review on machine learning methods for root cause analysis towards zero-defect manufacturing” (frontiersin.org/journals/manufacturing-technology). Systematische Übersicht über ML-Ansätze für Qualitätsabweichungen; zeigt, dass Random Forest / XGBoost kombiniert mit Feature-Importance-Methoden bei 20 von 27 analysierten Datensätzen zu signifikanten Verbesserungen führten.
• Paper-Properties-Vorhersage mit Gradient Boosting: De Gruyter, Nordic Pulp & Paper Research Journal (2024/2025), „Interpreting the relationship between properties of wood and pulping & paper via machine learning algorithms combined with SHAP analysis.” XGBoost, LightGBM und CatBoost erreichten R²-Werte > 0,9 für Zugfestigkeit, Berstindex und Reißlänge auf industriellen Papierdatensätzen.
• Industrielle Einsparungen in der Papierindustrie: ProcessMiner (processminer.com), „AI in Pulp and Paper Manufacturing” (2022+). Durchschnittliche Einsparung $500.000/Jahr je Produktionslinie; Board-Mill-Fallstudie: 15% Chemikalienreduktion, 38% Verbesserung der Zieleinhaltung.
• McKinsey-Benchmark: McKinsey & Company, zitiert in ProcessMiner-Veröffentlichungen: Throughput-Gewinne von 5–10%, Yield-Gewinne bis zu 5 Prozentpunkten für frühe Adopter in der Papier- und Zellstoffindustrie mit datengetriebenen Methoden.
• Concept Drift und Modellstabilität: Frontiers in AI (2024), „One or two things we know about concept drift — Part B: locating and explaining concept drift.” Zeigt, dass das Ausschließen von Merkmalen mit SHAP-Loss-Drift zu robusteren Produktionsmodellen führt.
• Ausschussquoten und Betriebskosten: TAPPI-Umfrage, zitiert in ProcessMiner (2022): Nur 4% der befragten Papierwerke berichten von produktiven Gewinnen über 10% durch Industry-4.0-Investitionen; 51% verzeichnen minimale Auswirkungen — eine ehrliche Gegenperspektive zu Hochglanzversprechungen.
• Preisangaben der Tools: Öffentliche Tarifseiten und PriceLevel.com (April 2026) für Dataiku (Medianpreis ~26.000 USD/Jahr). Alle Open-Source-Tools (KNIME Desktop, Python, MLflow, Orange, Grafana, InfluxDB): kostenlos, Stand April 2026.

Du willst wissen, ob eure Daten für diesen Ansatz gut genug sind — und welche Analyse-Tiefe sinnvoll ist? Meld dich für ein kurzes Gespräch.