Ein Qualitätsbericht kann sehr genau aussehen und trotzdem die falschen Entscheidungen auslösen. Das passiert, wenn Fehlercodes Symptome, Vermutungen und Ursachen vermischen.
Bezeichnungen wie „optischer Fehler“, „Maschine“, „Bediener“ oder „Sonstiges“ sind für eine belastbare Ursachenanalyse meist zu grob. Sie beschreiben nicht eindeutig, was beobachtet wurde, wo der Fehler entdeckt wurde und ob die angenommene Ursache bestätigt ist.
Im Spritzguss kommen weitere Bezugsgrößen hinzu: Artikel, Werkzeug, Kavität, Materialcharge, Prozesszustand und Prüfpunkt können relevant sein. Werden alle Informationen in einen einzigen Code gepresst, wird der Datensatz unverständlich. Werden sie gar nicht erfasst, bleibt der Pareto oberflächlich.
Grundregel: Ein Fehlercode beschreibt zuerst die beobachtete Abweichung. Eine vermutete oder bestätigte Ursache gehört in ein separates Feld mit eigenem Status.
Anzeichen für geringe Datenqualität
- Der Code „Sonstiges“ gehört regelmäßig zu den häufigsten Kategorien.
- Schichten oder Prüfende verwenden dieselbe Bezeichnung für unterschiedliche Fehlerbilder.
- Ein Code enthält bereits eine unbestätigte Ursache, etwa „Materialfehler“.
- Die Fehlerstelle am Bauteil oder der Entdeckungspunkt fehlen.
- Korrekturmaßnahmen werden geschlossen, ohne die Wiederkehr des Fehlers zu prüfen.
Bevor ein neues Dashboard entsteht, müssen Definitionen, Erfassung und Auswertung zusammenpassen.
Fehlerbild, Kontext und Ursache trennen
Ein schlanker Datensatz benötigt nicht möglichst viele Felder. Er benötigt die wenigen Felder, die eine prüfbare Hypothese ermöglichen.
- Fehlerbild definieren: Die sicht- oder messbare Abweichung mit eindeutigen Beispielen und Abgrenzungen beschreiben.
- Fundort erfassen: Festhalten, an welchem Prüf- oder Prozesspunkt die Abweichung entdeckt wurde.
- Technischen Kontext zuordnen: Artikel, Werkzeug, Kavität, Charge oder Prozessphase nur soweit erfassen, wie sie für die Analyse relevant sind.
- Entscheidung dokumentieren: Ausschuss, Nacharbeit, Freigabe oder Sperrung nachvollziehbar trennen.
- Ursachenstatus führen: Vermutung, geprüft und bestätigt nicht miteinander vermischen.
- Wirksamkeit nachweisen: Nach einer Korrekturmaßnahme gezielt prüfen, ob die Abweichung unter vergleichbaren Bedingungen wieder auftritt.
Keine Personensuche. Schicht- oder Rolleninformationen dienen nur einer sachlichen Prozessanalyse. Sie dürfen nicht als Ersatz für technische Ursachenklärung oder als pauschale Schuldzuweisung verwendet werden.
Ein sinnvoll getrenntes Erfassungsmodell
| Datenart | Beispielhafte Frage | Nutzen |
|---|---|---|
| Beobachtung | Was ist am Teil konkret abweichend? | Vergleichbare Fehlerbilder |
| Kontext | Wo, wann und in welchem technischen Bezug trat es auf? | Muster und Eingrenzung |
| Entscheidung | Wie wurde mit dem Teil verfahren? | Transparente Qualitätskosten |
| Ursache | Welche Hypothese wurde wie bestätigt? | Belastbare Korrekturmaßnahme |
Fiktives Praxisbeispiel: Oberflächenfehler ohne klare Abgrenzung
Ein Spritzgussbetrieb fasst mehrere sichtbare Abweichungen unter „Oberflächenfehler“ zusammen. Im Monatsbericht steigt die Kategorie, doch die Ursachenanalyse kommt nicht voran. Bei einer gemeinsamen Sichtung zeigt sich, dass verschiedene Merkmale, Bauteilzonen und Werkzeuge betroffen sind.
Das Team erstellt bebilderte Fehlerdefinitionen, trennt Fundort und vermutete Ursache und lässt mehrere Personen dieselben Muster unabhängig klassifizieren. Abweichende Zuordnungen werden genutzt, um die Definitionen zu verbessern. Erst danach wird ein Pareto erstellt und eine Ursachenanalyse für das dominierende, klar definierte Fehlerbild gestartet.
Erkenntnis: Ein genaueres Diagramm verbessert nichts, wenn die Kategorien nicht reproduzierbar sind. Datenqualität beginnt an der Erfassungsstelle.
Geeignete Kennzahlen für den Start
- Anteil der Fehler mit Code „Sonstiges“ oder Freitext ohne Zuordnung
- Übereinstimmung bei der Klassifikation ausgewählter Referenzmuster
- Anteil der Datensätze mit vollständigem technischen Kontext
- Wiederauftreten eines Fehlerbildes nach abgeschlossener Korrekturmaßnahme
- Zeit vom Erkennen eines Musters bis zur priorisierten Ursachenanalyse
Ein pragmatischer Verbesserungszyklus
- Die zehn häufigsten Codes auf Eindeutigkeit und Überschneidung prüfen.
- Für kritische Fehlerbilder kurze Definitionen mit Positiv- und Negativbeispielen erstellen.
- Beobachtung und Ursache in der Erfassung trennen.
- Eine kleine Stichprobe mehrfach klassifizieren und Unstimmigkeiten auswerten.
- Pareto erst nach der Bereinigung interpretieren.
- Korrekturmaßnahmen nur mit dokumentierter Wirksamkeitsprüfung schließen.
Fazit: Gute Fehlerdaten sind Teil des Produktionsprozesses
Ausschusscodes sind keine Verwaltungsaufgabe am Rand. Sie bestimmen, welche Probleme sichtbar werden und welche Verbesserungsmaßnahmen Priorität erhalten.
Wenn Fehlerbild, Kontext, Entscheidung und Ursache getrennt erfasst werden, entsteht eine belastbare Kette von der Beobachtung bis zur Wirksamkeitsprüfung. Das reduziert nicht automatisch Ausschuss – aber es verhindert, dass Zeit in die falsche Ursache investiert wird.
Prüfimpuls: Öffnen Sie den aktuellen Fehler-Pareto. Können zwei erfahrene Personen für jede Top-Kategorie dasselbe Fehlerbild eindeutig erkennen und von anderen Kategorien abgrenzen?
Häufige Fragen
Wie viele Fehlercodes sind sinnvoll?
So wenige wie möglich, aber so viele wie nötig, um relevante Fehlerbilder eindeutig zu unterscheiden.
Soll die Ursache im Fehlercode stehen?
Nein. Beobachtung und Ursache sollten getrennt werden, weil eine Ursache zu Beginn häufig nur vermutet wird.
Wann ist eine Korrekturmaßnahme abgeschlossen?
Erst wenn sie umgesetzt und ihre Wirksamkeit anhand geeigneter Nachweise geprüft wurde.
Quellenbasis
- ISO/TC 176: The process approach in ISO 9001:2015. PDCA, Wechselwirkungen und risikobasiertes Denken.
- ISO/IAF Auditing Practices Group: Nonconformity — review and closing. Fachliche Orientierung, keine normative Anforderung.
- ISO 22400-1:2014: Key performance indicators for manufacturing operations management; 2025 bestätigt.
Abrufdatum aller Onlinequellen: 24. August 2026. Die Quellen dienen der methodischen Einordnung. Für konkrete Vorhaben gelten die jeweils anwendbaren vertraglichen, technischen, gesetzlichen, sicherheits- und branchenspezifischen Anforderungen.
Redaktioneller Hinweis: Der Beitrag beschreibt ein methodisches Vorgehen. Produktspezifische Prüfpläne, Kundenvorgaben, Sicherheits- und Freigabeanforderungen bleiben verbindlich.
