Nacharbeits-Ursachen-Clustering
ML gruppiert Nacharbeits-Protokolle nach Muster statt nach Fehlermeldung — und zeigt, ob Dimensionsabweichungen am Maschinensetup, am Rohmaterial oder am Bearbeitungsschritt liegen.
Es ist Freitagmittag, 13:47 Uhr. Thomas Berger, Qualitätsleiter bei einem mittelständischen Formenbauer in Süddeutschland, zieht sein monatliches Nacharbeitsfazit.
37 Stunden Nacharbeit im Oktober. 42 im September. 39 im August. Die Zahlen liegen im “normalen Bereich”, steht in der Auswertung. Im Feld “Ursache” steht bei 28 der 34 Einträge: “Dimensionsabweichung”. Bei vier weiteren: “Oberflächenfehler”. Bei zwei: “Passungsproblem”.
Thomas weiß, dass das keine Analyse ist. Das ist eine Liste. Er vermutet seit Monaten, dass ein Großteil der Dimensionsabweichungen nach dem HSC-Fräsen an Kavitäten aus gehärtetem 1.2344 auftritt — aber er hat das nie systematisch nachgewiesen. Er hat es gefühlt. Und “Gefühl” reicht nicht für eine Investition in neue Werkzeughalter oder eine Änderung des Fräsprogramms.
Das Muster ist da. Er sieht es nicht, weil die Daten nicht so aufbereitet sind, dass es sichtbar wird.
Das echte Ausmaß des Problems
Im Werkzeugbau ist Nacharbeit kein Ausnahmefall — sie ist Betriebsrealität. Branchenbeobachter der WBA Aachener Werkzeugbau Akademie (2024) schätzen, dass manuelle Feinbearbeitungsschritte in deutschen Werkzeugbaubetrieben bis zu 30 Prozent der gesamten Fertigungskosten ausmachen — ein erheblicher Teil davon entfällt auf korrektive Nacharbeit, die vermeidbar wäre.
Die eigentliche betriebswirtschaftliche Last liegt woanders: Nacharbeit ist teuer pro Stunde. Facharbeiterstunden im Werkzeugbau liegen typisch zwischen 80 und 130 Euro brutto (inklusive Gemeinkosten), Maschinenstunden für Koordinatenmessmaschinen oder Erodiermaschinen zwischen 70 und 150 Euro — je nach Ausstattung und Auslastung. Ein Nacharbeitsvorgang, der 3 bis 5 Stunden dauert, kostet schnell 300 bis 650 Euro. Pro Fall.
Branchenweit liegt der Anteil qualitätsbedingter Kosten (Cost of Poor Quality, COPQ) laut amerikanischer Qualitätsfachgesellschaft ASQ bei durchschnittlich 15 bis 20 Prozent des Jahresumsatzes — in nicht-zertifizierten, qualitätsdatenärmeren Betrieben noch höher. Auch wenn Werkzeugbaubetriebe nicht 1:1 mit diesem Durchschnitt verglichen werden können, zeigt die Größenordnung das Potenzial: Wer strukturell 10 Prozent der Nacharbeit vermeidet, verbessert seine Marge spürbar — in einem Branchendurchschnitt von rund 3 Prozent Betriebsmarge (WBA/RWTH, 2024) ist das ein erheblicher Hebel.
Das Grundproblem ist nicht die Menge der Nacharbeit. Es ist die Unsichtbarkeit der Ursachen.
Die meisten Betriebe dokumentieren Nacharbeit als Ereignis, nicht als Datenpunkt. “Dimensionsabweichung Kavität 3, 2,5 Stunden” ist eine Aufzeichnung. Es ist kein Datensatz. Ohne Angabe von Bearbeitungsschritt, Maschinennummer, Schichtzeitpunkt, Rohmaterialcharge und Werkzeugalter lässt sich kein Muster erkennen — selbst wenn hundert solcher Einträge vorliegen.
Was typischerweise fehlt:
- Zusammenhang zwischen Fehler und vorgelagerten Fertigungsparametern
- Unterscheidung nach Kavitätsgeometrie oder Werkzeugstahlsorte
- Zeitstempel, der eine Korrelation mit Schichtwechsel oder Wartungsintervall erlaubt
- Verknüpfung von Maschinenzustand und Messergebnis
Das Ergebnis: Jeder Nacharbeitseintrag bleibt ein Einzelfall. Die Häufung zum Muster passiert im Kopf erfahrener Facharbeiter — oder gar nicht.
Was ein Nacharbeits-Ticket wirklich aussagt — und was nicht
Bevor Clustering einen Mehrwert liefern kann, lohnt ein ehrlicher Blick auf das Rohmaterial: die Nacharbeits-Protokolle selbst.
Ein typisches Nacharbeitsticket enthält: Datum, Auftragsnummer, betroffenes Bauteil, Fehlerbeschreibung in Freitext (“leichte Maßabweichung an Schulter”, “Rauigkeit erhöht”), Korrekturdauer in Stunden, manchmal Mitarbeiterkürzel. Das ist die gute Seite. Die problematische Seite: Fehlerbeschreibungen sind inkonsistent. Dieselbe Abweichung heißt in verschiedenen Wochenschichten “Maßabweichung”, “Toleranzüberschreitung”, “nachschleifen” oder “Kalibrierung nötig”. Ursachen werden selten dokumentiert — sie werden behoben.
Was das für das Clustering bedeutet:
Clustering-Algorithmen wie k-Means oder DBSCAN arbeiten auf numerischen Merkmalen, nicht auf Freitext. Bevor das Modell läuft, muss die Datenaufbereitung folgende Fragen beantworten:
- Welche Felder sind strukturiert genug für das Modell? (Zeitstempel, Korrekturdauer, Maschinennummer, Materialkürzel — ja; Freitext — nur nach NLP-Vorverarbeitung)
- Welche Felder fehlen, wären aber entscheidend? (Bearbeitungsschritt, Werkzeugverschleiß, Rohmaterialcharge)
- Welche Einträge sind unbrauchbar? (Fehlende Pflichtfelder, Tippfehler in Maschinencodes, Doppelerfassungen)
Die Erfahrung aus industriellen Clustering-Projekten zeigt: Der erste Durchlauf mit unbereinigten Daten erzeugt oft Cluster, die nichts als Erfassungsartefakte widerspiegeln — Cluster nach Mitarbeiterkürzel, nach Schicht, nach Erfassungsgewohnheit. Das ist kein Versagen des Algorithmus. Es ist das Signal, dass die Datenqualität vor dem Clustering das eigentliche Projekt ist.
Faustregel: Plane mindestens 40 bis 60 Prozent der Projektzeit für Datenbereinigung und Feature-Engineering. Wer das unterschätzt, hat nach dem ersten Clustering-Lauf bunte Bilder — und keine Erkenntnisse.
Mit vs. ohne KI — ein ehrlicher Vergleich
| Kennzahl | Ohne Clustering | Mit Clustering auf historischen Daten |
|---|---|---|
| Ursachenanalyse je Nacharbeitsfall | Einzelfallbetrachtung, 30–60 Min. | Mustererkennung in Minuten über alle Fälle |
| Erkannte strukturelle Ursachen | Erfahrungswissen einzelner Personen | Datengestützte Cluster mit Konfidenz |
| Reaktionszeit bis zur Gegenmassnahme | Wochen bis Monate (wenn überhaupt) | Nach erstem Cluster-Durchlauf sofort sichtbar |
| Dokumentation für Verbesserungsmaßnahmen | Anekdotisch, schwer belegbar | Datenbasis für messbare KPI-Verbesserung |
| Abhängigkeit von Schlüsselpersonen | Hoch — Muster stecken in Köpfen | Gering — Muster im System, nicht in Köpfen |
Realistische Einsparung nach Einführung gezielter Gegenmassnahmen (auf Basis der Cluster-Erkenntnisse): Betriebe, die systematisch auf Clustering-Erkenntnisse reagiert haben, berichten von 20–40 Prozent Reduktion der Nacharbeitsquote in den adressierten Fehlerkategorien — nicht sofort, sondern nach 3 bis 6 Monaten implementierter Korrekturen. (Erfahrungswerte aus industriellen Qualitätsprojekten; keine repräsentative Studie.)
Einschätzung auf einen Blick
Zeitersparnis — mittel (3/5) Das Clustering selbst spart keine tägliche Arbeitszeit — es spart Nacharbeitszeit, die sich in Wochen und Monaten akkumuliert. Anders als bei einer Angebotskalkulationshilfe, die sofort je Anfrage Stunden einspart, ist der Zeiteffekt hier indirekt und verzögert. Wer konkrete Gegenmassnahmen umsetzt, spart mittelfristig erhebliche Facharbeiterstunden — aber der Effekt ist diffus, nicht täglich sichtbar.
Kosteneinsparung — stark (4/5) Bei Stundensätzen von 80–130 Euro und Nacharbeitsvorgängen, die 3 bis 8 Stunden dauern, ist das Kostenpotenzial je adressiertem Ursachenmuster real und substanziell. Ein einziges identifiziertes Muster, das 10 Prozent der Nacharbeit erklärt, kann pro Jahr fünfstellige Beträge einsparen. Die Kosteneinsparung ist stärker als der tägliche Zeiteffekt — deshalb die höhere Bewertung auf dieser Achse gegenüber Zeitersparnis.
Schnelle Umsetzung — hoch (4/5) Der entscheidende Vorteil gegenüber anderen KI-Projekten im Werkzeugbau: Du brauchst keine neue Sensorik, keine CAD-Integration, keine Maschinenanbindung. Wenn Nacharbeitsdaten in irgendeiner digitalen Form vorliegen — ERP-Protokolle, Excel-Sheets, CAQ-System-Export — kann der erste Clustering-Lauf in KNIME Analytics Platform oder Orange Data Mining innerhalb weniger Tage nach Datenexport starten. Bis zu ersten interpretierbaren Mustern vergehen realistisch 4 bis 6 Wochen, inklusive Datenbereinigung. Im Vergleich zu Projekten, die CAD-Integration oder Sensorinfrastruktur erfordern, ist das schnell.
ROI-Sicherheit — niedrig (2/5) Das ist die ehrliche Einschränkung: Clustering macht Muster sichtbar, löst aber nichts. Der ROI entsteht erst, wenn du auf die Erkenntnisse reagierst — mit geänderten Fräsparametern, anderen Werkzeughaltern, einem neuen Rohmateriallieferanten oder einer angepassten Prüfroutine. Diese Kausalität ist schwerer zu messen und nachzuweisen als eine direkte Prozessbeschleunigung. Außerdem gilt: Wenn die Clustering-Erkenntnisse an der Umsetzungsbereitschaft des Teams scheitern, ist der ROI null. Die Investition in die Analyse ist dann verloren.
Skalierbarkeit — mittel (3/5) Mit wachsender Datenbasis werden die Cluster besser und stabiler. Das System profitiert von mehr Daten — keine Zusatzkosten für mehr Protokollvolumen. Die Einschränkung: Das Clustering-Modell muss periodisch neu kalibriert werden, wenn sich Produktmix, Materialien oder Maschinen ändern. Ein Modell, das auf 2022–2023-Daten kalibriert wurde, gibt 2025 möglicherweise irreführende Cluster zurück, wenn zwischenzeitlich neue Stahlsorten oder Bearbeitungszentren eingeführt wurden. Skalierbarkeit ja — aber mit Pflegeaufwand.
Richtwerte — stark abhängig von Datenqualität, Dokumentationstiefe und Bereitschaft, Gegenmassnahmen umzusetzen.
Was das Clustering konkret macht
Der technische Ansatz heißt Machine Learning — genauer: unüberwachtes Clustering. “Unüberwacht” bedeutet: Du gibst dem Algorithmus keine Kategorien vor. Du sagst ihm nicht: “Suche nach Dimensionsabweichungen durch Fräsverschleiß.” Du sagst ihm nur: “Hier sind 400 Nacharbeits-Datensätze mit diesen Merkmalen. Finde Gruppen, die sich ähneln.”
Der Algorithmus — typisch k-Means oder DBSCAN — berechnet, welche Datenpunkte sich in einem mehrdimensionalen Merkmalsraum nahe beieinander liegen. Nah beieinander bedeutet: ähnliche Kombination aus Fehlertyp, Maschinencode, Materialsorte, Bearbeitungsschritt, Korrekturdauer, Zeitstempel. Was er zurückgibt, sind Gruppen von Einträgen, die sich mehr ähneln als dem Rest — ohne dass du definiert hättest, was “ähnlich” bedeutet.
Was das konkret bedeutet, am Beispiel:
Das System bekommt 18 Monate Nacharbeits-Protokolle — 340 Einträge. Es erkennt vier Cluster:
- Cluster A (87 Fälle): Dimensionsabweichungen, fast ausschließlich Kavitäten aus 1.2344 (gehärtet), nach HSC-Fräsen, Korrekturdauer 2–4 Stunden, stark gehäuft in Wochenmitte
- Cluster B (61 Fälle): Oberflächenfehler, verschiedene Materialien, nach Erodieren, geringe Korrekturdauer, verteilt über alle Wochentage
- Cluster C (124 Fälle): Passungsprobleme, Zusammensetzung diverse, nach Bohren und Reiben, lange Korrekturdauer 4–8 Stunden — weitgehend heterogen, kein klares Muster
- Cluster D (68 Fälle): Maßabweichungen nach Wärmebehandlung, korreliert mit spezifischem Lieferantenkürzel im Materialdatensatz
Cluster C liefert noch keinen Ansatzpunkt — zu heterogen. Aber Cluster A und D sind sofort handlungsfähig: Cluster A deutet auf ein systematisches Problem beim HSC-Fräsen von 1.2344 hin, Cluster D auf ein Rohmaterialproblem mit einem spezifischen Lieferanten. Beides ist testbar und behebbar.
Das ist der Wert des Clusterings: Es macht das Muster sichtbar, das in 340 Tabellenzeilen unsichtbar war.
Werkzeugbau-spezifische Fehlerklassen: Was sich wie clustert
Werkzeugbau-Nacharbeit ist nicht homogen. Die Fehlerklassen verhalten sich in der Clustering-Analyse unterschiedlich gut — das solltest du vor dem ersten Durchlauf wissen.
Dimensionsabweichungen sind die am häufigsten dokumentierte und am besten clusterbare Fehlerklasse. Sie entstehen durch definierbaren Ursachen: Werkzeugverschleiß, fehlerhafte Nullpunktsetzung, thermische Ausdehnung, Spannfehler. Weil die Einflussgrößen messbar und oft im Fertigungsprotokoll vorhanden sind (Maschinencode, Werkzeugindex, Bearbeitungsschritt), entsteht ein gutes Featureset für das Clustering.
Oberflächenfehler (Rauigkeit, Riefen, Brandspuren) sind schwieriger. Viele Ursachen — Kühlschmierstoffqualität, Schnittdaten, Werkzeugverschleiß, Materialinhomogenitäten — erzeugen ähnliche Symptome. Das Clustering findet Gruppen, aber die Gruppen sind oft nicht trennscharf genug für eine eindeutige Gegenmassnahme. Empfehlung: Erst nach Dimensionsabweichungen vorgehen, wo die Signal-Rausch-Ratio besser ist.
Passungsprobleme bei Führungssäulen, Kerne-Kavität-Passung oder Schiebern sind die anspruchsvollste Klasse. Sie sind oft das Ergebnis von Toleranzstapelungen über mehrere Bauteile — der “Fehler” entstand nicht beim letzten Bearbeitungsschritt, sondern durch das Zusammenspiel mehrerer vorheriger. Das Clustering kann Muster finden (z.B.: Passungsprobleme bei bestimmten Einbaupositionen häufen sich), aber die Ursachenkette ist komplex und erfordert Expertenwissen zur Interpretation.
Praktische Empfehlung für den Einstieg: Starte mit Dimensionsabweichungen. Diese Klasse ist groß genug für statistisch belastbare Cluster, die Ursachen sind meist maschinennaher und damit adressierbarer, und der Zusammenhang zwischen Cluster-Erkenntnis und Gegenmassnahme ist direkter als bei Oberflächenfehlern oder Passungsproblemen.
Konkrete Werkzeuge — was wann passt
Die Tool-Wahl hängt von drei Faktoren ab: technisches Know-how im Team, vorhandene Datenmengen und Budget.
Orange Data Mining — für den ersten Proof-of-Concept ohne Code Vollständig kostenlos, läuft lokal, keine Cloud-Abhängigkeit. Drag-and-Drop-Oberfläche mit visuellen Clustering-Workflows. Importiere einen CSV-Export aus deinem ERP, konfiguriere einen k-Means-Knoten, visualisiere die Cluster in 30 Minuten. Ideal für den ersten Durchlauf, der zeigt ob überhaupt Muster in den Daten stecken, bevor du mehr investierst. Einschränkung: kein Deutsch, kein Reporting, kein Team-Collaboration. Für den Proof-of-Concept ausreichend — für den Dauerbetrieb zu rudimentär.
KNIME Analytics Platform — für den produktiven, automatisierbaren Workflow Ebenfalls kostenlos in der Desktop-Version (Open Source, GPLv3). Tiefere Datenbankanbindung, bessere Anbindung an SQL-Quellen und ERP-Exporte, automatisierbare Ausführung. Cluster-Workflows können gespeichert und regelmäßig auf neue Datenexporte ausgeführt werden — das macht KNIME zur natürlichen Folgestufe nach Orange Data Mining. Technisches Niveau: niedrig bis mittel. Steile Lernkurve im Vergleich zu Orange, aber deutlich mächtiger für den produktiven Dauereinsatz. Kosten: Desktop-Version kostenlos, Business Hub für Teamkollaboration auf Anfrage.
Power BI — für die Visualisierung und Kommunikation der Ergebnisse Power BI ist kein Clustering-Tool, sondern ein Visualisierungs-Tool. Es kommt als zweiter Schritt ins Spiel: Wenn die Cluster in KNIME oder Orange Data Mining ermittelt sind, exportierst du die Cluster-Zuweisungen als CSV und visualisierst die Muster in Power BI für Qualitätsberichte und Entscheidungsvorlagen. Die Power BI Desktop-Version ist kostenlos und gut genug für diese Aufgabe. Sharing und Zusammenarbeit erfordern eine Pro-Lizenz (12,10 EUR/Nutzer/Monat).
Python mit scikit-learn — für Teams mit Entwickler-Ressourcen Wenn ein Datenanalyst oder Entwickler im Team oder als externer Dienstleister vorhanden ist, ist scikit-learn die flexibelste und mächtigste Option. DBSCAN (geeignet für unregelmäßig geformte Cluster und Ausreißer-Erkennung) und hierarchisches Clustering (für explorative Analyse der Cluster-Anzahl) sind in wenigen Zeilen Code implementiert. Der Vorteil: vollständige Kontrolle über Feature-Engineering und Hyperparameter, direkte Integration in bestehende Python-Datenpipelines. Kosten: nur Entwicklerzeit.
Dataiku — für Teams, die ML-Projekte wiederholt und kollaborativ betreiben Wenn Clustering kein einmaliger Pilot, sondern ein dauerhafter Analyseprozess für mehrere Qualitätsdimensionen werden soll, bietet Dataiku eine kollaborative ML-Plattform mit visuellen Flows, AutoML und eingebautem Reporting. Preis: Medianpreis ca. 26.000 USD/Jahr laut PriceLevel.com (2024), Community Edition kostenlos für Einzelnutzer. Sinnvoll ab dem Punkt, wo mehrere Personen regelmäßig an Clustering-Modellen arbeiten und Ergebnisse systematisch tracken sollen.
Zusammenfassung: Wann welcher Ansatz
- Erster Proof-of-Concept, kein Budget, kein Code → Orange Data Mining
- Produktiver Dauerbetrieb, automatisierbar, kein Code → KNIME Analytics Platform
- Visualisierung und Reporting der Cluster-Erkenntnisse → Power BI
- Team mit Python-Entwickler vorhanden → scikit-learn in Python
- Wiederholte ML-Projekte, mehrere Personen, kollaborativ → Dataiku
Datenschutz und Datenhaltung
Nacharbeits- und Fertigungsdaten sind in der Regel keine personenbezogenen Daten im Sinne der DSGVO — sofern kein Mitarbeiterkürzel als identifizierende Kennung verwendet wird, das auf einzelne Personen zurückführbar ist. Das vereinfacht die rechtliche Situation erheblich gegenüber Projekten mit HR- oder Kundendaten.
Dennoch gelten einige Grundregeln:
Lokale Tools sind die sichere Wahl für den Pilot. Orange Data Mining und die KNIME Analytics Platform Desktop-Version verarbeiten alle Daten vollständig lokal. Kein Datentransfer zu externen Servern, kein Cloud-Zugriff. Das ist die unproblematischste Option und für den Proof-of-Concept die richtige Wahl — besonders wenn Produktionsdaten Betriebs- oder Geschäftsgeheimnisse enthalten.
KNIME Business Hub On-Premise ermöglicht auch den Team-Betrieb ohne Cloud-Abhängigkeit. Die Instanz läuft auf der eigenen Infrastruktur.
Power BI verarbeitet Daten standardmäßig in Microsoft-Cloud-Rechenzentren. Für EU-Kunden mit M365 EU Data Boundary bleiben die Daten in europäischen Datacentern. Für reine Visualisierungsaufgaben auf nicht-personenbezogenen Fertigungsdaten ist das in der Regel unproblematisch — ein Datenschutzbeauftragter sollte trotzdem einbezogen werden, wenn der Betrieb in einer zertifizierten Umgebung läuft (IATF, ISO 13485).
Wenn ein Mitarbeiterkürzel in den Daten steckt: Anonymisiere vor dem Clustering. Das Kürzel ist für die Ursachenanalyse in den meisten Fällen irrelevant — Maschinencode, Schichtzeitpunkt und Bearbeitungsschritt sind aussagekräftiger. Das Entfernen des Kürzels verhindert gleichzeitig, dass Clustering-Ergebnisse als Mitarbeiterkontrolle interpretiert werden können (was zu Recht auf Widerstand stoßen würde).
AVV bei Cloud-Diensten: Wer Dataiku oder andere Cloud-basierte Plattformen für Fertigungsdaten nutzt, die auch nur mittelbar auf Personen schließen lassen, muss einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO abschließen. Die genannten Anbieter stellen AVV-Vorlagen bereit.
Was es kostet — realistisch gerechnet
Einstieg (Proof-of-Concept)
- Tools: 0 Euro — Orange Data Mining und KNIME Analytics Platform Desktop sind kostenlos
- Datenaufbereitung: 2–4 Arbeitstage intern (Export aus ERP, Bereinigung, Feature-Engineering) — der eigentliche Aufwand
- Externer Berater für den ersten Clustering-Durchlauf und Interpretation: 800–2.000 Euro, wenn kein Datenanalyse-Know-how im Haus vorhanden
- Gesamtkosten Pilot: 800–2.000 Euro extern + interner Aufwand von ca. 3–5 Wochen Teilzeit
Laufende Kosten (nach Pilotbetrieb)
- KNIME Desktop: weiterhin kostenlos
- KNIME Business Hub (Teamkollaboration, Scheduling): Preise auf Anfrage — für KMU typisch 5.000–15.000 Euro/Jahr je nach Nutzerzahl und Support-Level
- Power BI Pro (Sharing der Visualisierungen): 12,10 Euro/Nutzer/Monat
- Python/scikit-learn: nur Entwicklerzeit, keine Lizenzkosten
- Dataiku Community Edition: kostenlos für Einzelnutzer; Enterprise: ~26.000 USD/Jahr
Was du dagegenrechnen kannst Annahme: Betrieb mit 45 Stunden Nacharbeit pro Monat, durchschnittlicher Facharbeiterstundensatz (inkl. Gemeinkosten) 110 Euro. Das sind 4.950 Euro Nacharbeitskosten pro Monat, 59.400 Euro pro Jahr.
Wenn das Clustering zwei adressierbare Ursachenmuster aufdeckt, die gemeinsam 20 Prozent der Nacharbeit erklären, und du diese Muster mit gezielten Gegenmassnahmen in 3–6 Monaten behebst: Einsparung ca. 990 Euro/Monat, 11.900 Euro/Jahr.
Bei einem einmaligen Pilot-Investment von 1.500 Euro ist die Amortisationszeit rechnerisch unter 2 Monate — nach der Umsetzung der Gegenmassnahme. In der Praxis liegt der Effekt oft bei 30–50 Prozent dieser Theorie, weil nicht jede Gegenmassnahme sofort vollständig wirkt. Auch im konservativen Szenario: positive ROI innerhalb des ersten Jahres.
Wichtiger Hinweis: Der ROI entsteht nicht durch das Clustering allein. Er entsteht durch die Gegenmassnahme. Wer clustert und dann nichts ändert, hat nichts gewonnen.
Von Clustering zu Gegenmassnahme: Der entscheidende zweite Schritt
Das Clustering ist fertig. Du hast drei interpretierbare Cluster, einer davon mit einer klaren Signatur: Dimensionsabweichungen nach HSC-Fräsen bei 1.2344-Stahl, gehäuft an Werkzeugstunden 600–800 (kurz vor dem regulären Wechselintervall).
Jetzt beginnt die eigentliche Arbeit.
Was du mit dem Cluster-Ergebnis tun musst — konkret:
-
Hypothesen formulieren, keine Entscheidungen treffen. Das Cluster zeigt eine Korrelation, keine Kausalität. “Fälle häufen sich bei Werkzeugstunden 600–800” bedeutet nicht sicher, dass der Werkzeugverschleiß die Ursache ist — es könnte auch eine korrelierte Variable sein (z.B. ein bestimmter Materiallieferant, der zu dieser Zeit bestellt wird). Formuliere 2–3 konkurrierende Hypothesen.
-
Gezielte Validierung, keine große Umbaute. Ändere zunächst nur für eine Testcharge: Setze das Werkzeug bei 550 Stunden statt 700 Stunden. Dokumentiere die nächsten 20 Bearbeitungen dieses Typs explizit. Vergleiche die Nacharbeitsquote für diese Charge mit der historischen Baseline.
-
Ergebnis dokumentieren und rückführen. Das Validierungsergebnis gehört zurück ins Nacharbeits-System als Datenpunkt — nicht als Anekdote, sondern als gemessener Effekt. So wird aus dem Cluster-Ergebnis ein belegbarer Prozessverbesserungsnachweis.
-
Nicht alle Cluster auf einmal angehen. Der typische Fehler: Man findet fünf Cluster und startet gleichzeitig fünf Verbesserungsinitiativen. Das überfordert das Team und macht die Wirkung einzelner Maßnahmen unmessbar. Priorisiere: Welcher Cluster hat das größte Kostenvolumen? Welcher hat die klarste Hypothese? Welcher ist am einfachsten zu testen? Dieser kommt zuerst.
Wenn der Cluster keine plausible Hypothese liefert: Nicht jeder Cluster ist interpretierbar. Manchmal zeigt das Clustering, dass ein Datenfeld, das du für aussagekräftig gehalten hast, in Wirklichkeit ein Erfassungsartefakt ist. Das ist kein Misserfolg — es ist Information. Überarbeite das Feature-Engineering und lasse das Modell neu laufen.
Typische Einstiegsfehler
1. Mit einem zu kleinen Datensatz starten. Clustering-Algorithmen brauchen ausreichend Datenpunkte, um stabile Muster zu erkennen. Mit weniger als 80 bis 100 Nacharbeits-Einträgen je Fehlerklasse sind die Cluster statistisch nicht belastbar — sie spiegeln Zufallsvariation, nicht systematische Ursachen. Wer drei bis vier Nacharbeitsvorgänge pro Woche hat, sollte mindestens 12 bis 18 Monate Historik sammeln, bevor er mit dem Clustering startet.
2. Das Feature-Engineering überspringen. Der häufigste Fehler in der Praxis: Den ERP-Export direkt in das Clustering-Tool laden, ohne vorher zu entscheiden, welche Felder als Features genutzt werden und in welcher Form. Ein Datumsfeld ist für k-Means unbrauchbar — aber “Wochentag” oder “Stunden seit letzter Wartung” schon. Freitext-Fehlerbeschreibungen müssen kodiert werden. Ohne diesen Schritt findet das Clustering keine inhaltlichen Muster, sondern Erfassungsartefakte.
3. Clustering als einmaligen Analyseschritt behandeln. Das ist der Wartungsfehler, der still passiert: Das Clustering wird einmal durchgeführt, liefert Erkenntnisse, und dann wird das Modell nicht mehr aktualisiert. Nach 12 bis 18 Monaten hat der Betrieb neue Maschinen, neue Materialien, neue Produkttypen — und das alte Clustering-Modell bildet diese Realität nicht mehr ab. Wenn neue Daten auf das alte Modell angewendet werden, entstehen irreführende Cluster-Zuweisungen. Lösung: Stelle einen festen Rhythmus ein, in dem die Clustering-Analyse auf neue Daten angewendet wird (z.B. vierteljährlich) und das Modell bei signifikanten Änderungen des Produktmix oder Maschinenparks neu kalibriert wird. Wer das Modell betreibt, muss namentlich benannt sein — “die Qualitätsabteilung” reicht nicht.
4. Cluster als Beweis statt als Hypothese behandeln. Ein Cluster zeigt Korrelation — nicht Kausalität. “Fehler häufen sich bei Maschinencode 3” bedeutet nicht, dass Maschine 3 defekt ist. Es bedeutet: Maschine 3 ist ein guter Ausgangspunkt für die Ursachenanalyse. Wer sofort auf Basis des Clusters entscheidet (“Maschine 3 wird stillgelegt”), ohne zu validieren, ob das Muster kausal ist, riskiert falsche Gegenmassnahmen und verlorenes Vertrauen ins System.
Was mit der Einführung wirklich passiert — und was nicht
Clustering-Projekte im Werkzeugbau scheitern selten an der Technologie. Sie scheitern an der Organisation.
Widerstandsmuster, die typisch auftreten:
Die Erfahrungsträger fühlen sich übergangen. Im Werkzeugbau arbeiten Facharbeiter, die seit 15 oder 20 Jahren dieselben Maschinen bedienen und ein intuitives Gespür für Fehlerursachen entwickelt haben. Wenn ein Clustering-Modell plötzlich Aussagen macht (“Cluster A deutet auf Werkzeugverschleiß nach 600 Stunden hin”), die von dem abweichen, was die erfahrene Kollegin seit Jahren “weiß”, entsteht Skepsis — manchmal Ablehnung. Das Modell wird als Infragestellung ihrer Expertise erlebt, nicht als Unterstützung.
Was hilft: Bezieht die erfahrensten Facharbeiter in die Interpretation der Cluster ein. Sie sind die besten Validators — sie können sagen, ob ein gefundenes Muster plausibel ist oder ein Artefakt. Wer das Modell mitinterpretiert, verteidigt es statt es zu widerlegen.
Das Qualitätsmanagement hat andere Prioritäten. Clustering ist ein Analyse-Projekt, kein Notfallprogramm. Wenn gerade ein Lieferengpass, ein Kundenreklamationsfall oder eine Zertifizierungsaudit läuft, wird die Clustering-Analyse nach hinten verschoben — immer wieder, bis sie im Sand verläuft. Das ist kein Sabotage, sondern realistische Priorisierung.
Was hilft: Plane das Projekt mit einem festen Zeithorizont und einem definierten Ablieferungsdatum (“bis Ende Quartal haben wir den ersten Cluster-Bericht”). Ein offener Endpunkt führt zu einem nie endenden Projekt.
Die Ergebnisse werden nicht kommuniziert. Das Clustering ist fertig, die Cluster sind interpretiert — und dann liegt der Bericht im Postfach des Qualitätsleiters, ohne dass das Team davon erfährt. Keine Gegenmassnahme, keine Rückkopplung.
Was hilft: Plant eine kurze Team-Session (30 bis 60 Minuten), in der die Cluster-Ergebnisse gezeigt und besprochen werden — mit der konkreten Frage: “Welche dieser Cluster klingen euch plausibel, und was würdet ihr als erstes testen?” Das erzeugt Ownership für die Gegenmassnahmen, die danach kommen.
Realistischer Zeitplan mit Risikohinweisen
| Phase | Dauer | Was passiert | Typisches Risiko |
|---|---|---|---|
| Daten-Inventur | Woche 1–2 | ERP-Export, Vollständigkeitsprüfung, Felder dokumentieren | Fehlende Pflichtfelder (Maschinencode, Materialsorte) — Nacherfassung nötig |
| Datenbereinigung & Feature-Engineering | Woche 2–4 | Inkonsistente Einträge bereinigen, numerische Features ableiten, Freitext kodieren | Unterschätzte Komplexität — 40–60 % der Gesamtzeit, nicht 20 % |
| Erster Clustering-Pilot mit Orange Data Mining | Woche 3–5 | k-Means und DBSCAN auf bereinigten Daten, Cluster visuell explorieren | Erste Cluster zeigen nur Erfassungsartefakte — Feature-Engineering muss nachgebessert werden |
| Ergebnisinterpretation & Hypothesenformulierung | Woche 5–7 | Cluster mit Facharbeitern diskutieren, 2–3 testbare Hypothesen formulieren | Kein Facharbeiterkonsens über Plausibilität — Cluster bleibt ohne Interpretation |
| Übergabe in produktiven Workflow mit KNIME | Woche 6–10 | Clustering-Workflow automatisierbar machen, Rhythmus für Aktualisierung festlegen | Keine namentliche Verantwortung definiert — Modell wird nie aktualisiert |
| Validierung & erste Gegenmassnahme | Ab Monat 3–4 | Test einer Gegenmassnahme, Messung der Wirkung, Dokumentation | Gegenmassnahme wirkt nicht sofort — Geduld und Datengeduld nötig |
Häufige Einwände — und was dahintersteckt
“Wir haben die Daten nicht in der Form, die ihr braucht.” Fast alle Betriebe haben diese Sorge beim Einstieg — zu Recht, aber nicht als Ausschlusskriterium. ERP-Systeme exportieren typischerweise strukturierte Daten; CAQ-Systeme oft noch strukturierter. Der Aufwand liegt in der Bereinigung und Anreicherung, nicht im Datenzugang. Wer einen CSV-Export aus dem ERP erstellen kann, hat genug Ausgangsmaterial für einen Pilot. Die Frage ist nicht “Haben wir die perfekten Daten?” sondern “Haben wir ausreichend gute Daten für einen ersten Durchlauf?”
“KI macht Fehler — wir können uns keine falschen Gegenmassnahmen leisten.” Das ist der richtige Einwand — und der Grund, warum Clustering Hypothesen liefert, keine Befehle. Das Clustering-Ergebnis sagt nie “Ändere jetzt Werkzeughalter X”. Es sagt “Fehler häufen sich bei dieser Maschinenkonfiguration nach dieser Betriebsdauer — das könnte ein Hinweis sein.” Die Gegenmassnahme wird von Menschen entschieden und in einem kontrollierten Test validiert, bevor sie dauerhaft eingeführt wird. Der Algorithmus ersetzt kein Urteil, er informiert es.
“Das haben wir alles im Kopf — dafür brauchen wir kein System.” Das stimmt — bis die Person mit diesem Wissen in Rente geht oder das Unternehmen verlässt. Die WBA Aachener Werkzeugbau Akademie weist darauf hin, dass Demographics und Fachkräftemangel im Werkzeugbau eines der zentralen Probleme der nächsten Jahre sind. Wissen, das im Kopf steckt, ist flüchtig. Clustering macht dieses Wissen zu einem Datenpunkt im System.
Woran du merkst, dass das zu dir passt
- Du hast monatlich mehr als 15 bis 20 Nacharbeitsstunden in einem klar abgrenzbaren Bereich (z.B. Kavitätenfertigung) und das Volumen hat sich in den letzten zwei Jahren nicht wesentlich reduziert — trotz punktueller Maßnahmen
- Nacharbeit wird schon digital erfasst — irgendwo im ERP, CAQ-System oder mindestens strukturiert in Excel. Reine Papiererfassung ohne digitale Überführung macht das Clustering unmöglich
- Du vermutest ein Muster, kannst es aber nicht belegen — “ich glaube, das liegt an Maschine 3 nach Schichtwechsel” ist das perfekte Clustering-Ausgangssignal: Das Muster ist gefühlt, aber nicht beweisbar
- Dein Qualitätsleiter oder Fertigungsleiter hat Zeit für eine Pilotphase — mindestens eine halbe Person für 4 bis 6 Wochen, nicht nur als Auftraggeber, sondern als aktiver Interpret der Ergebnisse
Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:
-
Unter 80 bis 100 dokumentierten Nacharbeits-Einträgen pro Fehlerklasse in den letzten 12 bis 18 Monaten. Das ist die Datenanforderung — nicht aus Bequemlichkeit, sondern weil Clustering-Algorithmen bei zu kleinen Datensätzen statistische Zufallsmuster als “Cluster” ausgeben. Wer drei bis vier Nacharbeitsvorgänge pro Monat hat, sollte erst die Datenbasis aufbauen, bevor er clustert. Ein strukturiertes Erfassungsschema für die nächsten 12 Monate ist der sinnvollere erste Schritt.
-
Nacharbeit wird nur kategorial erfasst (“Dimensionsabweichung”), ohne begleitende Fertigungsparameter. Clustering auf reinen Fehlerkategorien erzeugt keine verwertbaren Cluster — es segmentiert nur, was vorher manuell kategorisiert wurde. Für das Clustering braucht der Datensatz mindestens zwei oder drei Parameter, die mit der Fehlerursache korrelieren könnten: Maschinencode, Materialsorte, Bearbeitungsschritt oder Zeitstempel. Wer diese Information nicht erfasst, muss zunächst die Erfassungstiefe verbessern, bevor das Clustering einen Mehrwert hat.
-
Keine Person im Betrieb, die das Clustering-Modell nach dem Piloten dauerhaft betreut. Ein Clustering-Modell, das auf 2023-Daten kalibriert und dann nicht aktualisiert wird, gibt 2025 irreführende Ergebnisse, wenn sich Produktmix oder Maschinenpark geändert haben. Ohne eine namentliche Verantwortung für die regelmäßige Aktualisierung — mindestens vierteljährlich, bei Produktmix-Änderungen sofort — ist der Pilot keine Investition, sondern ein Einmalprojekt.
Das kannst du heute noch tun
Exportiere aus deinem ERP oder CAQ-System alle Nacharbeits-Einträge der letzten 12 Monate als CSV. Öffne Orange Data Mining (kostenlos, Download in 5 Minuten) und lade den Export. Verbinde den Datei-Widget mit einem k-Means-Widget (k=3 oder 4) und dann mit einem Scatter-Plot-Widget.
Was du danach siehst, wird wahrscheinlich nicht sofort interpretierbar sein — die Daten sind roh, die Features noch nicht aufbereitet. Aber du siehst, ob überhaupt Struktur in den Daten steckt, und du bekommst ein konkretes Bild davon, was für die Datenbereinigung nötig ist.
Das dauert eine Stunde. Was du danach weißt: ob der nächste Schritt sich lohnt — bevor du auch nur einen Euro für externes Know-how ausgibst.
Für die Analyse selbst kannst du diesen Prompt als Einstieg nutzen:
Mitarbeiter:in
KI-Assistent
Quellen & Methodik
- Branchenstruktur und Marge im Werkzeugbau: WBA Aachener Werkzeugbau Akademie / RWTH Campus, Digitale Transformation im Werkzeugbau — Interview mit Dr.-Ing. David Welling (2024). Gewinnmargen ca. 3 %, 70,5 % der führenden Betriebe nutzen zentralisierte CAM-Programmierung, manuelle Feinbearbeitung bis zu 30 % der Fertigungskosten.
- Cost of Poor Quality (COPQ) 15–20 % des Jahresumsatzes: American Society for Quality (ASQ), Benchmarks zur Qualitätskostenanalyse; bestätigt durch manufacturingleadgeneration.com, „85+ Manufacturing Quality Statistics 2025–2026”. Hinweis: Branchenübergreifender Durchschnitt; für Werkzeugbau-KMU als Orientierungswert zu verstehen.
- Clustering-Validierung auf Fertigungsfehlerdaten: Grznar, P. et al., „Diagnostics of Product Defects by Clustering and Machine Learning Classification Algorithm”, American Journal of Industrial Engineering and Business Management (sciepub.com, 2021). DBSCAN-Clustering auf 1.000 Proben mit anschließender Klassifikation: Gradient Boosted Trees 95,8 % Prediction Accuracy, KNN 95,2 %.
- Systematische Review ML-Methoden für Ursachenanalyse: Frontiers in Manufacturing Technology, „A systematic review on machine learning methods for root cause analysis towards zero-defect manufacturing” (2022). Analyse von 30 peer-reviewed Artikeln 2017–2022; sechs Hauptherausforderungen identifiziert: Explainability, Trainingsdatenqualität, fehlende Standardisierung, Datenschutz, Integration.
- Negativ-Ergebnis Fehlererfassungs-Software: industry-science.com, Fehlermanagement in der Produktion — Befragung von 23 deutschen Fertigungsunternehmen. Spezialisierte Softwarelösungen für Fehlererfassung zeigten negativen Einfluss auf Effektivität; automatisierte Fehlererkennung an Produktionslinien war kontraproduktiv. Wichtiger Hinweis auf die Organisationsvoraussetzungen.
- Stundensätze Werkzeugbau: Eigene Erfahrungswerte aus Projekten und Brancheneinschätzungen; Spannweite 80–130 EUR/Stunde für Facharbeit (inkl. Gemeinkosten), 70–150 EUR für spezialisierte Maschinenkapazitäten. Maschinenstundensatz-Kalkulator Spanflug.de als Orientierungsquelle.
- Preisangaben Tools: KNIME AG (April 2026), Orange Data Mining / Bioinformatics Lab Ljubljana (April 2026), Microsoft Power BI (April 2026), Dataiku Median-Preis laut PriceLevel.com 2024.
Du willst wissen, ob eure Nacharbeits-Daten ausreichend strukturiert sind für einen Clustering-Pilot — und was der sinnvolle erste Schritt wäre? Meld dich — das schauen wir uns gemeinsam an.
Diesen Inhalt teilen:
Interesse an diesem Use Case?
Schreib uns, wenn du mehr erfahren oder diesen Use Case für dein Unternehmen umsetzen möchtest. Wir melden uns zeitnah bei dir.
Weitere Use Cases
Angebotskomplexitäts-Risikoerkennung
KI analysiert eingehende Anfragen auf versteckte Komplexitätstreiber und schätzt das Unterkalkulationsrisiko, bevor der Angebotspreis festgelegt wird.
Mehr erfahrenToleranzstapelungs-Risikoprognose
KI prüft Konstruktionszeichnungen auf Toleranzkombinationen, die statistisch zu Passungsproblemen führen — bevor das erste Werkzeug gefräst wird.
Mehr erfahrenFertigungszeitschätzungs-Drift-Erkennung
KI findet systematische Muster in der Abweichung zwischen kalkulierten und tatsächlichen Fertigungsstunden — und korrigiert die Schätzregeln, bevor der nächste Auftrag wieder zu günstig angeboten wird.
Mehr erfahren